Вчера я открыл одно из наших веб-приложений в Chrome, и оно выдало большой красный значок «ВНИМАНИЕ, что этот сайт содержит контент с плохого URL». Я дважды проверил введенный мной URL, сразу же просмотрел исходный код и выполнил поиск в файле. Конечно же, внизу был тег скрипта с закодированным URL-адресом, который при декодировании был оскорбительным URL-адресом, который обнаружил Chrome.
Мне любопытно, как это было сделано и как я могу избежать этого в будущем. Шаги, которые я предпринял, приведены ниже, но я не уверен, что они являются решением.
Я заглянул в IIS и увидел, что на сайте разрешен доступ на запись для пользователей IUSR_ComputerName и IIS_WPG во всем корневом веб-каталоге, что изначально было сделано для записи файлов загрузки и журналов. Я ограничил это конкретными областями, в которые нужно было писать, и только для IIS_WPG.
Заранее спасибо.
Это начало. IUSR_ComputerName - это то, что IIS использует по умолчанию для разрешений анонимных пользователей. Это означает, что они смогут выполнить анонимный HTTP PUT, перезаписав любой файл.
IIS_WPG - это группа, используемая для разрешений, под которыми работает ваш пул приложений. Насколько я понимаю, вам должно хватить повышения разрешений пользователя .NET для определенных каталогов. IUSR_ComputerName должны требовать только разрешения на чтение.
Какой пул приложений настроен на использование? Вместо предоставления разрешений группе IIS_WPG создание конкретной учетной записи пользователя обеспечит дополнительную безопасность, если вы запустите несколько сайтов.
Это действительно случилось со мной, и виновником был FTP.
Проверьте свои веб-журналы IIS в день последнего изменения одного из зараженных файлов. Если у вас включен FTP для вашего сайта, проверьте также журналы FTP в этот день. Это был единственный способ выяснить, что произошло.
В конце концов, мы обнаружили, что компьютер в сети был заражен вредоносным ПО, которое запускалось через определенный список FTP-клиентов, и загрузили файлы настроек FTP, содержащие незашифрованные пароли, на несколько FTP-сайтов.
Можете ли вы найти вредоносный код на любой из своих веб-страниц? Возможно, это инъекционная атака, при которой кто-то выполняет атаку «человек посередине» и внедряет код на лету ...
Об этом говорилось в статье о Блог Нила Карпентера:
Оглядываясь назад на трассировку сети, мы увидели большое количество бесплатных пакетов arp для IP-адреса шлюза по умолчанию. MAC-адрес, который возвращается как соответствующий шлюзу по умолчанию, предназначен для сетевой карты Compaq (); однако шлюзом по умолчанию является устройство Cisco с другим MAC-адресом. Основываясь на этом, мы определили, что на этом компьютере выполнялась атака с отравлением кэша ARP (*) для выполнения атаки «злоумышленник в середине» и вставки iframe в HTTP-сообщения, где ответом был HTML-документ.
Да, код действительно был в файле, поэтому мы знали, что это не SQL-инъекция или человек посередине.