Итак, вот и все, на устаревшем сайте, который мы размещали для клиента, была версия FCKEditor, которая позволяла кому-то загружать ужасный эксплойт c99madshell на наш веб-хост.
Я не большой любитель безопасности - честно говоря, я просто разработчик, в настоящее время отвечающий за S / A из-за потери персонала. Соответственно, я хотел бы получить любую помощь, которую вы могли бы оказать сбойному серверу в оценке ущерба от эксплойта.
Чтобы дать вам немного информации:
Файл был загружен в каталог в корневом веб-каталоге «/ _img / fck_uploads / File /». Пользователь и группа Apache ограничены таким образом, что они не могут войти в систему и не имеют разрешений за пределами каталога, из которого мы обслуживаем сайты.
У всех файлов было 770 разрешений (пользователь rwx, группа rwx, другие нет) - что-то, что я хотел исправить, но мне сказали, чтобы не было «высокого приоритета» (надеюсь, это изменит это). Похоже, хакеры легко могли выполнить сценарий.
Теперь мне не удалось найти сам c99madshell.php - только несколько других HTML-файлов, содержащих русский текст, и несколько файлов .xl и .html со встроенным PHP, которые были репродукциями взлома madshell. Однако после небольшого исследования, похоже, что взлом уничтожает себя после выполнения - отлично.
В любом случае, моя первоначальная оценка была бы такой:
Нет необходимости перестраивать весь хост, поскольку, учитывая изоляцию пользователя / группы apache, они не должны были иметь возможность получать пароли системного уровня.
Необходимо исправить эту уязвимость, запретив загрузкам не иметь разрешения на выполнение, обновив версию FCKEditor, чтобы исправить исходную цель эксплойта, и добавить конфигурацию на уровне сервера, которая запрещает выполнение сценария PHP в каталоге загрузок.
Я должен изменить пароли БД для приложения - учитывая, что файл конфигурации для подключения к базе данных находится внутри веб-корня, хакер, скорее всего, мог захватить его, а вместе с ним и пароль БД.
В любом случае, пожалуйста, поделитесь своим мнением о том, что я должен сказать боссу. Очевидно, было бы идеально избегать перестройки всего хоста, но если это то, что мы должны предпринять, чтобы гарантировать, что мы не запускаем взломанную машину, то это то, что нам нужно.
Я очень ценю вашу помощь, ребята. Также не стесняйтесь спрашивать дополнительную информацию (я буду рад запускать команды / работать с вами, ребята, чтобы оценить ущерб). Проклятые хакеры :(.
Очевидно, как говорили другие, официальным «безопасным» ответом было бы восстановление машины.
Реальность ситуации может этому помешать. Вы можете выполнить несколько действий, чтобы проверить наличие компромиссов:
Исправления, которые необходимо внести в конфигурацию вашей системы:
Я многое упускаю, но это были бы первые шаги, которые я сделал бы. В зависимости от того, что вы используете на сервере, и важности его безопасности (обрабатываете ли вы CC-транзакции?), Может потребоваться перестройка, но если это сервер с «низким уровнем безопасности», вы можете согласиться с проверкой вышеуказанного.
Короче - я бы сервер пересобирал.
Если у них есть доступ к локальному пользователю (теперь у них был доступ как пользователь apache), они могут запускать локальные эксплойты. Таким образом, вы должны учитывать, что весь сервер скомпрометирован. Вам также следует проверить наличие других серверов.
Какой у вас дистрибутив? Если он основан на rpm, вы можете проверить подписи файлов. Загрузите установочный компакт-диск и запустите rpm -V, чтобы проверить пакеты.
Вам нужно восстановить хост. Вы не знаете, какие атаки повышения привилегий они использовали против хоста, и вы не можете быть абсолютно уверены в том, что не установлены трояны, кейлоггеры или руткиты.
Если вас скомпрометировали, у вас не останется другого выхода, кроме восстановления с нуля.
Прежде всего. НИКОГДА НЕ ДОВЕРЯЙТЕ КОМПРОМИССНОМУ СЕРВЕРУ.
Даже если ты считать вы обезопасили машину, скриптовые детишки не глупы, есть вероятность, что где-то был установлен бэкдор. Пользователь / группа мало что меняет после того, как вы получили оболочку.
Сделайте резервную копию ваших файлов, осуществите смену ВСЕХ паролей.
Я знаю, что это не то, что вы предпочли бы услышать, но я действительно рекомендую сделать резервную копию данных, перестроить сервер и повторно импортировать все данные.
Также не забудьте заглянуть на другие сайты, чтобы убедиться, что взлом пострадал не только этот. Если все сценарии вашего сервера работают от имени одного пользователя Apache (nodoby/www_data/ what-ever-your-distro-uses) все, что может писать на один сайт, почти наверняка может писать и на остальных.
Помимо изменения всех паролей, убедитесь, что любые SSH-ключи на сервере недействительны на всех других серверах (т. Е. Отмените открытые ключи, где бы они ни были сохранены, а не просто удалите закрытый ключ) и что любые другие системы, которые могут быть у вас ввел пароль (или сохранил пароль для в файле) на / через этот сервер, изменил пароли.