Веб-сайт Microsoft UK Events взломан
Страница регистрации партнерского мероприятия веб-сайта мероприятий Microsoft UK была повреждена хакером, которому удалось обнаружить и использовать уязвимость веб-приложения в одном из параметров, используемых формой на веб-сайте, доступ к которому ранее можно было получить по адресу:
http://www.microsoft.co.uk/events/net/eventdetail.aspx?eventid=8399 [снято в автономном режиме]
Хакеру, известному под именем «rEmOtEr», удалось испортить страницу Microsoft, воспользовавшись уязвимостью SQL Injection в одном из параметров, используемых формой, которая была встроена в URL-адрес страницы. Этот конкретный параметр не фильтровался, поэтому он позволял хакеру передавать любой тип созданного кода непосредственно в базу данных, используемую этой формой.
Кроме того, хакеру удалось обнаружить имена таблиц и столбцов (полей данных) внутри базы данных, которые извлекались и отображались на странице — это означает, что любой текст или даже код, который был вставлен в этот столбец, затем отображался на странице. страница.
Задачи, выполняемые хакером для просмотра паролей базы данных
Ниже приводится краткая реконструкция некоторых шагов, выполненных хакером для обнаружения и использования уязвимости SQL Injection в регистрационной форме, что позволяет ему просматривать сохраненные имена пользователей и пароли в системе:
- Параметры формы были заполнены необычными символами (такими как « » и «-»), чтобы увидеть реакцию сайта. Эти символы обычно отфильтровываются, потому что они используются в SQL как специальные команды для взаимодействия с базой данных. Среди проверенных параметров были:
- Видимые входные данные (текстовые поля, выпадающие списки и т. д.) в форме (метод POST)
- Скрытые входные данные из исходного HTML-кода страницы (метод POST)
- Параметры, используемые в URL (метод GET)
- URL-адрес веб-сайта в этом случае использует два интересных параметра eventID и v2:
http://www.microsoft.co.uk/events/net/PreRegister.aspx?eventID=p83968&v2=1
При попытке манипулировать параметром v2, например, добавив к нему апостроф, сайт дал следующий ответ:
http://www.microsoft.co.uk/events/net/PreRegister.aspx?eventID=p83968&v2=1'
фигура 1
Увидев эту ошибку, можно подтвердить две вещи:
- Сообщения об ошибках на стороне сервера ВКЛЮЧЕНЫ на веб-сервере. Обычно они включаются только во время разработки и тестирования, чтобы любые ошибки или, в данном случае, уязвимости обнаруживались до запуска. Когда веб-сайт запускается, сообщения об ошибках на стороне сервера обычно отключаются, чтобы конфиденциальная информация не предоставлялась в Интернете.
- Параметр v2 НЕ фильтруется на наличие вредоносных символов/кода. Это означает, что все, что содержит этот параметр, будет передано используемому SQL Server без какой-либо фильтрации.
Эта длинная ошибка SQL выявила много важной информации о базовой базе данных, которую хакер использовал для дальнейшего извлечения и изменения данных, хранящихся в этой базе данных.
- Хакер получил более ценную информацию непосредственно из базы данных, поэкспериментировав с командами SQL, переданными через этот параметр методом проб и ошибок. Ему также помогли сообщения об ошибках, отображаемые на странице.
Команда SQL 1, имеющая 1=1–, была отправлена с параметром v2, где она была добавлена к основному запросу SQL, отправленному в базу данных. Это добавило к SQL-запросу условие, которое всегда истинно (1=1), и в этом случае это сбило с толку SQL Server из-за того, что команда GROUP BY выдала следующую ошибку:
http://www.microsoft.co.uk/events/net/PreRegister.aspx?eventID=p83968&v2= 1 с 1=1–
Результат? Раскрыта дополнительная информация о базе данных!
Было раскрыто имя таблицы MultivenueLists и имена некоторых столбцов, таких как recordID и placeStatus, из которых хакер понял больше о структуре базы данных.
Примечание:
В языке структурированных запросов (SQL) столбцы обозначаются как TABLE(dot)COLUMN, поэтому столбцы отображаются как MultivenueLists.recordID ) - Как только хакер узнал имена таблиц и столбцов, он внедрил некоторый текст в определенный столбец, добавив оператор, такой как 1 update MultivenueLists set местонахождениеStartDate='hacked by rEmOtEr';– на вход параметра v2 в URL-адресе.:
…ster.aspx?eventID=p83968&v2= 1 обновление MultivenueLists установить местонахождениеStartDate='hacked by rEmOtEr';–
Рисунок 2: Полученная страница на этот раз не выдает ошибки, но на странице отображается только что вставленный в базу текст - Используя оператор UNION SELECT, хакеру удалось получить список имен пользователей и паролей из системы, угадав имена двух столбцов (имя пользователя и пароль) и одной таблицы (пользователи).
Это была команда SQL, используемая для параметра v2 для получения имен пользователей:
…ster.aspx?eventID=p83968&v2= -1 union select 1,2,3,4,username,6,7 from users–
Рисунок 3
Это была команда SQL, используемая для параметра v2 для получения паролей:
…ster.aspx?eventID=p83968&v2=- 1 объединение выбирает 1,2,3,4,пароль,6,7 от пользователей-
Рисунок 4 - Используя комбинацию запросов с идентификатором пользователя, хакер смог определить, какой пароль принадлежит какому имени пользователя.
Задачи, выполняемые хакером для порчи страницы
Ниже приводится краткая реконструкция некоторых шагов, выполненных хакером для обнаружения и использования SQL Injection в регистрационной форме:
- Как только хакер узнал достаточно о том, как внедрить свой собственный код в базу данных веб-сайта, он подготовил простую HTML-страницу на стороннем удаленном хосте, которая будет использоваться для атаки.
- Используя команды, аналогичные тем, которые использовались для отображения его собственного текста на странице, хакер вставил следующий URL-адрес HTML-сайта, размещенного на стороннем удаленном хосте:
<ссылка xhref=http://h.1asphost.com/remoter/css.css type=text/css rel=stylesheet> - Страница формы на сайте Microsoft создана таким образом, что загружает определенный текст из базы данных, когда пользователь просматривает страницу (типично для CMS-систем). Поскольку этот текст был заменен хакером на ссылку xhref выше, он перенял весь внешний вид страницы, загрузив содержимое с внешнего хоста.
- Вот как выглядела веб-страница в результате этого искажения:
Рисунок 5
Что привело к этой порче?
Этому искажению способствовало сочетание двух вещей, кроме хакера, который хотел взломать форму, размещенную на веб-сайте Microsoft:
- SQL-инъекция — один из параметров в URL-адресе отправлялся напрямую в базу данных без должной фильтрации перед этим. Это предоставило хакеру канал для прямого обращения к базе данных с теми же правами, что и при подключении с веб-сервера и сервера базы данных.
- Сообщения об ошибках. Из включенных сообщений об ошибках SQL на веб-сайте хакер может получить представление о структуре базы данных. Это помогло ему уточнить команду SQL, чтобы база данных обработала инструкции по вставке кода искажения в базу данных для искажения сайта.
Как это можно было предотвратить?
Лучший способ предотвратить взлом — регулярно проверять свой сайт на наличие уязвимостей, которыми могут воспользоваться хакеры. При этом уязвимость SQL-инъекций могла быть обнаружена и устранена до того, как страница была опубликована.
Как обеспечить безопасность вашего сайта
Чем больше веб-сайт, тем сложнее регулярно проверять наличие уязвимостей на каждой странице. Взломанная страница на сайте Microsoft была лишь небольшой частью гораздо более крупного веб-сайта, на которую не обращали внимания — обычный результат ручного аудита безопасности.
Эту сложность можно преодолеть с помощью автоматизированного сканера веб-приложений, такого как Acunetix Web Vulnerability Scanner. Используя такой мощный, но простой в использовании инструмент, вы можете полностью автоматически сканировать каждый параметр в каждой форме на вашем веб-сайте на наличие сотен уязвимостей. Это, конечно, сократит сложность и время, необходимое для проведения аудита безопасности на вашем веб-сайте.
Использование автоматизированного сканера веб-приложений также означает, что тому, кто выполняет аудит, не требуются какие-либо технические знания о веб-уязвимостях, вместо этого нужно только запустить приложение для сканирования веб-сайта и создания отчета об уязвимости.