Категория: Разработка Теги: Уязвимости Опубликовано: 9 мая 2023

Что за атака GET /data/admin/ allowurl.txt HTTP/1.0

Начнем с того, что я нашел в логе nginx такую запись (сайт не этот):

20.219.112.92 - - [28/Apr/2023:05:42:24 +0300] "GET /data/admin/allowurl.txt HTTP/1.0" 404 18977 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0"

Что пытался сделать злоумышленник?

Безусловно, этот запрос направлен не вручную, а из специальной программы или подготовленного скрипта / бота, но управляет этим человек, поэтому для упрощения я буду говорить именно про этого злоумышленника.

Разберём HTTP-запрос

Строка 404 говорит о том, что запрашиваемый файл не существует и соответственно ему вернулся статус 404 Not found. На самом деле, сам по себе статус 404 не означает, что вектор атаки не сработал - тут нужно повторить запрос и посмотреть, не добавилось ли что-то лишнее в запрос, а в случае со слепыми XSS (Blind XSS) вектор атаки может сработать не в том месте, где ввели команду.

IP-адрес злоумышленника 20.219.112.92 и он принадлежит корпорации MICROSOFT-CORP-MSN-AS-BLOCK (Возможно, сервера Azure), который находится в United India - Tamil Nadu.

Сам запрос "GET /data/admin/allowurl.txt HTTP/1.0" говорит о том, что злоумышленник хотел посмотреть содержимое allowurl.txt.

Зачем он его хотел посмотреть? Тут всего два варианта:

он просто хотел определить CMS сайта, так как именно этот путь однозначно идентифицирует DedeCMS;
он хотел посмотреть список URL-адресов, которые разрешены для добавления в содержимое сайта в системе управления контентом dedeCMS.

В базе AbuseIPDB указано, что данного уже было более 306 атак на другие сайты.

Технические детали

В файле data/admin/allowurl.txt может располагаться приблизительно следующее содержимое:

"
www.dedecms.com
www.desdev.cn
bbs.dedecms.com
"

Список разрешенных доменов также используется в dede/article_allowurl_edit.php:

if(empty($allurls)) $allsource = '';
else $allurls = stripslashes($allurls);
$m_file = DEDEDATA."/admin/allowurl.txt";
//保存

и в dede/inc/inc_archives_functions.php:

if($dopost=='save')
        // 读取允许的超链接设置
        if(file_exists(DEDEDATA."/admin/allowurl.txt"))
        {
            $allow_urls = array_merge($allow_urls, file(DEDEDATA."/admin/allowurl.txt"));
        }
        $body = Replace_Links($body, $allow_urls);
    }

Файл allowurl.txt содержит список URL-адресов, которые разрешены для добавления в содержимое сайта в системе управления контентом dedeCMS. Эти URL-адреса не будут помечены как "вредоносные" или "недопустимые" при попытке добавления их в контент.

Файл allowurl.txt используется в двух файлах скриптов-обновлений: dede/article_allowurl_edit.php и dede/inc/inc_archives_functions.php. В первом файле он используется для сохранения списка разрешенных URL-адресов в переменную для дальнейшего использования в других частях системы. Во втором файле он используется для чтения списка разрешенных URL-адресов и применения их к содержимому сайта с помощью функции Replace_Links(). Это позволяет сайту добавлять ссылки на разрешенные внешние ресурсы без риска добавления ссылок на вредоносные сайты.

Если злоумышленник сможет прочитать содержимое файла allowurl.txt, то он может использовать его для понимания того, какие URL-адреса разрешены для добавления на сайт. Например, он может использовать эти URL-адреса для создания ложных веб-страниц, которые будут имитировать разрешенные внешние ресурсы. Однако, это будут атаки на посетителей сайта, а-ля XSS.

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

В любом случае, оба варианта нацелены только на dedeCMS.

Как защитить веб-сервер?

Немного информации

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

Любой админ скажет, что реагировать на такие записи в журнале не нужно, но любой опытный пентестер скажет, что реагировать на такие записи в журнале нужно!

Автоматические сканирования на наличие уязвимостей веб-серверов ботами со всего мира - это не просто неприятное явление, но и серьезная угроза для безопасности веб-сервера. Согласно отчету, опубликованному в 2019 году, боты составляют около 37,2% всего трафика Интернета, и это число продолжает расти. Боты, сканирующие веб-серверы, могут искать уязвимости, которые можно использовать для получения несанкционированного доступа к серверу или к данным, которые он содержит.

Теперь скажите честно, последней ли версии у вас всё ПО и библиотеки как на веб-сервере, так и в самом сайте? Уверен, что у большинства будут далеко не последние версии, так как при обновлении много придется настраивать заново. Пора задуматься и понять, что риск не равен нулю.

С чего начинается атака хакера или пентестера на веб-сервер?

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

Далее через кучу прокси-серверов сканирует сервер на наличие уязвимостей. При таком сканировании на сервер отправляет множество запросов, но фишка в том, что он использует целый пул прокси-серверов, поэтому каждый 1-2 запроса выполняются с разных IP-адресов. Однако, при частых сканированиях они все будут присутствовать в спам базах.

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