Привет, фантасты!
Я только что попросил взломать один из сайтов моих клиентов. Им удалось изменить файл так, чтобы страница оформления заказа на сайте записывала платежную информацию в текстовый файл.
К счастью или к сожалению, они запутались, но в коде была опечатка, которая сломала сайт, поэтому я сразу узнал об этом.
Я подозреваю, как им это удалось:
Мой веб-сайт CMS имеет область загрузки файлов, куда вы можете загружать изображения и файлы для использования на веб-сайте. Загрузки ограничены 2 папками. Я обнаружил два подозрительных файла в этих папках, и при изучении содержимого кажется, что эти файлы позволяют хакеру просматривать файловую систему сервера и загружать свои собственные файлы, изменять файлы и даже изменять ключи реестра ?!
Я удалил некоторые файлы и изменил пароли, и сейчас пытаюсь защитить CMS и ограничить загрузку файлов расширениями.
Что еще вы, ребята, можете предложить мне сделать, чтобы попытаться узнать более подробную информацию о том, как они попали сюда и что еще я могу сделать, чтобы предотвратить это в будущем?
Если ваш (клиентский) сайт уже был взломан, вам сначала следует отключить его. У вас нет возможности легко доказать, что хакер не устанавливал руткит. Вы должны предположить, что все данные на этой службе были скомпрометированы и потенциально потеряны. Ради вас, я надеюсь, вы не хранили данные кредитной карты или другие платежные данные в базе данных SQL в незашифрованном виде и не хранили их зашифрованными с помощью ключа где-нибудь в той же системе.
Затем вам необходимо восстановить его из заведомо исправного образа и восстановить из последней удачной резервной копии. Это единственный способ убедиться. Ядерная бомба с орбиты.
Что касается выяснения того, как они попали в вашу систему, посмотрите журналы событий, когда люди вошли в систему, и, возможно, журналы аудита тоже могут сказать вам, выполнили ли они какой-либо код из области загрузки. Это послужит для вас хорошим учебным опытом, особенно когда речь идет о разрешениях для исполняемых файлов в общедоступных областях веб-сайта, а также об аудите и ведении журнала.
Вашим первым приоритетом должно быть восстановление сайта на заведомо исправном сервере и более сильная защита, чем исходный сайт.
Вы можете найти это "Восстановление из взломанной системы"интересное чтение.
Известный ответ Роберта Муара на этот вопрос может вам тоже помочь.
Мой веб-сайт CMS имеет область загрузки файлов, куда вы можете загружать изображения и файлы для использования на веб-сайте. Загрузки ограничены 2 папками. Я обнаружил два подозрительных файла в этих папках, и при изучении содержимого похоже, что эти файлы позволяют хакеру просматривать файловую систему сервера и загружать свои собственные файлы, изменять файлы и даже изменять ключи реестра ?!
Именно по этой причине области загрузки файлов чрезвычайно опасны. Вы должны предпринять большие шаги, чтобы гарантировать, что загруженный контент не может быть повторно использован в рамках попытки взлома. Если вы заблокируете исполняемый контент, сценарий, уязвимый для XSS, где-то еще на сайте, может вызвать этот код и запустить его под свой собственный контекст, который является исполняемым.
Они вошли, загрузив то, что потом можно было запустить. Возможно, они вызвали это напрямую, и в этом случае вам нужно убедиться, что в эти каталоги можно загружать только неисполняемый контент. Возможно, они вызвали его из какого-то другого сценария, обнаружив, что для этого потребуется копаться в файлах журнала, чтобы увидеть, какой сценарий вызвал эти файлы, которые вы определили, а затем защитить сценарий.
После перестройки сервера внимательно посмотрите на эти дыры и повторно оцените потребность в каталогах загрузки.
Если вы используете asp.net и только тогда, когда вы отметили SO, вам нужно только добавить этот web.config в корневой каталог, в который ваши пользователи загружают файлы. С помощью этого файла web.config вы не разрешаете кому-либо запускать страницы aspx в этом дереве каталогов.
<configuration>
<system.web>
<authorization>
<deny users="*" />
</authorization>
</system.web>
</configuration>
Самая важная вещь - убедиться, что если у вас есть какие-либо области загрузки, в этих областях не будет никаких исполняемых файлов внутри них.
Если область доступна в Интернете, и загрузки могут быть любыми, все, что им нужно, это загрузить скрипт aspx / php / etc в это место и перейти к нему для активации.
Предотвратить это:
Если в данный момент у них есть доступ, особенно если у них есть какое-то время, с пользовательским программным обеспечением, которое вы не можете найти с помощью антивирусных программ, убедитесь, что у вас есть чистая копия вашего кода, к которой у них нет доступа в другом месте; затем перестройте сервер. Да, это, вероятно, совершенно не нужно, если у них был только ограниченный доступ, но если вы не знаете, не рискуйте.
О да, очевидно, изменить все пароли везде. Если на вашем веб-сайте есть учетные записи с читаемой базой паролей, эти два. Если на вашем веб-сайте хранятся личные данные пользователей, вам, вероятно, необходимо сообщить им и, возможно, властям, в зависимости от вашего национального законодательства.
Из журнала IIS вы сможете узнать, когда файлы были загружены и с какого IP-адреса они пришли.
Самая важная вещь - убедиться, что если у вас есть какие-либо области загрузки, в этих областях не будет никаких исполняемых файлов внутри них.
Если область доступна в Интернете, а загрузки могут быть любыми, все, что им нужно, это загрузить скрипт aspx / php / etc в это место и перейти к нему для активации.
Предотвратить это: