Решил репоснуть мою статейку с моего блога про ИБ и пентест t.me/xml_infosec
Те, кто регулярно ищут уязвимости на различных Bug Bounty программах повидали всякое. Сегодня мы поговорим о таких случаях, когда лень приводит к необратимым последствиям.
Кому это будет полезно узнать? Если вы знакомы с веб-уязвимостями и пентестом, то вас заинтересуют конкретные случаи такой лени или некомпетентности разработчиков/админов, которые встречал лично я, некоторые из этих уязвимостей по сей день не исправлены. Если же вы новичок в пентесте и в самой сфере информационной безопасности, то эта статья вам поможет обращать внимание на такие ошибки, а также расскажет про основные уязвимости веб приложений.
Стандартные логины и пароли
Здесь всё серьёзно и без подробностей т.к. это Портал государственных услуг Украины. Есть страница со стандартным логином и паролем к админ-панели, этот аккаунт используется для тестирования разработчиками и эта страница не скрыта от посторонних глаз. Всё бы ничего, но там есть возможность загружать файлы, они не исполняются, а скачиваются, но возможно это можно обойти. Ещё там доступен http-метод DELETE и различные iDOR уязвимости. Любой может изменить пароль к этому аккаунту. Тут довольно много возможных векторов атаки.
Что такое iDOR? Говоря простыми словами, iDOR - это когда приватная информация пользователей, например их файлы, доступна по ссылке всем.
Например есть сайт, где вы зарегистрированы. Вы загрузили туда ваши паспортные данные, находящиеся в файле. Ссылка на этот файл имеет вид example.com/files/documents/123456.doc
Вы можете легко перебрать цифры в конце ссылки и получить доступ к паспортным данным всех пользователей на сайте. Как это не допустить? Просто нужно ограничить приватную информацию пользователя от посторонних и использовать правильную генерацию ссылки на файлы и другую информацию пользователя. Например не используйте только цифры для создания ссылки, чтобы защитить пользователей от iDOR уязвимости достаточно чтобы ссылка на загруженные данные была например такой: example.com/files/documents/3fk5vsl329dthpo5yrd36iute4s
Если вы пентестер, то всегда ищите уязвимости в самых неожиданных местах.
Если вы нашли старую страницу с документацией - посмотрите нет ли там каких-либо персональных данных. Обращайте внимание на скриншоты в документации, в них могут быть логины и пароли от админ-панели или другие данные, которые может использовать злоумышленник.
Данные от админ-панели в открытом доступе
Отдельная история была с форумом vip-cxema[.]org. Я сканировал диапазоны ip masscan'ом, обнаружил ftp без авторизации. На этом ftp я нашёл текстовый файл не только с паролем от админ-панели, но и вообще от всех аккаунтов владельца сайта.
Электронные кошельки, аккаунты от различных соц. сетей, пароли и логины от google и Яндекс аккаунтов - всё это было в открытом доступе. Я сообщил админу и этот ftp закрыли от посторонних глаз.
Все логины и пароли нужно хранить в менеджере паролей. Их существует много, но нас интересуют только решения с открытым исходным кодом, потому что таким образом мы можем убедиться что наши пароли действительно шифруются и никто кроме нас не имеет к ним доступа. Менеджер паролей
На этом примере мы можем убедиться что даже если приняты все меры безопасности, все сервисы обновлены до последней версии, порты закрыты и везде используются сложные для подбора пароли, то уязвимость может быть в человеческом факторе. Если вы владелец сайта или компании, то проводите инструктаж для каждого сотрудника. Неважно кто он: разработчик, системный администратор или уборщик.
Также в вашей инфраструктуре должно быть правильное разграничение прав для каждого. Это должно быть как в админ-панеле так и в корпоративной сети. Разработчики не должны иметь доступ к настройке конфигурации сервера, а тестировщики не должны иметь такие же права как и разработчики.
CSRF в регистрации
На сайтах с авторизацией по sms часто встречается CSRF, что может привести к sms-флуду и даже к account takeover. Нужно делать тайм-аут между запросами на отправку sms и не передавать текст сообщения в post-запросе на стороне клиента. Иногда бывает что тайм-аут есть, но он на стороне клиента. Так делать тоже нельзя по понятным причинам.
Если CSRF допущено в обычной регистрации через e-mail, то злоумышленник может написать скрипт, который будет постоянно регистрировать новых пользователей.
Фактически это будет DoS атака.
Как защититься от CSRF? Для каждого действия, совершаемого пользователем, нужно генерировать уникальный токен. Сервер должен создавать токен используя алгоритмы, которые не имеют уязвимостей. Важен и размер токена, чем он длиннее тем сложнее его подобрать. Токен должен иметь определенное время, после которого он перестает действовать.
Поддомен, который никто не найдёт
Начинающие разработчики думают что их поддомен для тестирования (test.example.com и т.п.) никто не найдет, но оказывается что он индексируется поисковиками или его можно найти простым перебором поддоменов.
И на таких поддоменах обычно есть файлы с чувствительной информацией, конфигурационные файлы и прочее. В моём случае тут даже можно скачивать любой файл, независимо от расширения.
Есть много утилит для поиска поддоменов, можете написать свою. Самая популярная - Sublist3r.
Чтобы такого не случилось нужно ограничить доступ к поддоменам, а лучше просто не тестировать новые функции на поддоменах.
Злоумышленники используют перебор поддоменов не только с целью найти уязвимые сервисы, конфигурационные файлы и другую важную информацию, но и для DoS атак. При неправильной настройке основной домен защищён от атак отказа в обслуживании например сервисом CloudFlare, а домен mail.example.com не находится под CloudFlare и выдаёт настоящий ip-адрес сервера.
Передача параметров в post запросе, которые не нужно передавать
В данном случае в post запросе можно изменить не только имя аккаунта но и баланс! Это очень серьёзная уязвимость, хоть и глупая.
На скриншоте ниже показано как можно подменить эти данные в сервисе для рассылки сообщений.
Как это можно использовать? Например для stored XSS. Если нет защиты от XSS и присутствует данная уязвимость, то реализовать stored XSS очень просто.
(на скрине xakep.ru потому что писал изначально статью для него, а потом забил и запостил к себе в канал)
Уязвимости в сервисах, банальная SQL инъекция
Нужно постоянно обновлять все сервисы и следить за уязвимостями в них, иначе какой-нибудь бот, который автоматически эксплуатирует уязвимости в веб приложениях, загрузит вредоносный код и на ваш сервер. В моём случае на сайте была sql инъекция и в итоге 3 тысячи аккаунтов ВКонтакте и другие персональные данные могли оказаться в руках злоумышленника. Уязвимость ещё не исправили, владельцу всё равно на персональные данные пользователей. Чаще всего sql уязвимости присутствуют в самописных CMS и необновленных популярных CMS.
Если вам без разницы какую CMS использовать, то пользуйтесь популярными решениями и постоянно обновляйте до последней версии. На скриншоте видно что к некоторым хэшам подобрались пароли. Чтобы такого не происходило - проверяйте пароль пользователя при регистрации, и если он находится в списке самых популярных паролей, не имеет цифр или слишком короткий, то отклоняйте регистрацию и предупреждайте пользователя о том, какой должен быть пароль чтобы его не подобрали. Для безопасного хранения паролей ваших пользователей в базе данных используйте хэш-функцию bcrypt.
Да, всё описанное в статье - банальные вещи, но нужно обращать внимание на такое в самую первую очередь, независимо от того пентестер ли вы или владелец сайта.
Я надеюсь что вы не будете делать подобных ошибок, будете всё логировать и вовремя реагировать на различные инциденты.
Те, кто регулярно ищут уязвимости на различных Bug Bounty программах повидали всякое. Сегодня мы поговорим о таких случаях, когда лень приводит к необратимым последствиям.
Кому это будет полезно узнать? Если вы знакомы с веб-уязвимостями и пентестом, то вас заинтересуют конкретные случаи такой лени или некомпетентности разработчиков/админов, которые встречал лично я, некоторые из этих уязвимостей по сей день не исправлены. Если же вы новичок в пентесте и в самой сфере информационной безопасности, то эта статья вам поможет обращать внимание на такие ошибки, а также расскажет про основные уязвимости веб приложений.
Стандартные логины и пароли
Здесь всё серьёзно и без подробностей т.к. это Портал государственных услуг Украины. Есть страница со стандартным логином и паролем к админ-панели, этот аккаунт используется для тестирования разработчиками и эта страница не скрыта от посторонних глаз. Всё бы ничего, но там есть возможность загружать файлы, они не исполняются, а скачиваются, но возможно это можно обойти. Ещё там доступен http-метод DELETE и различные iDOR уязвимости. Любой может изменить пароль к этому аккаунту. Тут довольно много возможных векторов атаки.
Что такое iDOR? Говоря простыми словами, iDOR - это когда приватная информация пользователей, например их файлы, доступна по ссылке всем.
Например есть сайт, где вы зарегистрированы. Вы загрузили туда ваши паспортные данные, находящиеся в файле. Ссылка на этот файл имеет вид example.com/files/documents/123456.doc
Вы можете легко перебрать цифры в конце ссылки и получить доступ к паспортным данным всех пользователей на сайте. Как это не допустить? Просто нужно ограничить приватную информацию пользователя от посторонних и использовать правильную генерацию ссылки на файлы и другую информацию пользователя. Например не используйте только цифры для создания ссылки, чтобы защитить пользователей от iDOR уязвимости достаточно чтобы ссылка на загруженные данные была например такой: example.com/files/documents/3fk5vsl329dthpo5yrd36iute4s
Если вы пентестер, то всегда ищите уязвимости в самых неожиданных местах.
Если вы нашли старую страницу с документацией - посмотрите нет ли там каких-либо персональных данных. Обращайте внимание на скриншоты в документации, в них могут быть логины и пароли от админ-панели или другие данные, которые может использовать злоумышленник.
Данные от админ-панели в открытом доступе
Отдельная история была с форумом vip-cxema[.]org. Я сканировал диапазоны ip masscan'ом, обнаружил ftp без авторизации. На этом ftp я нашёл текстовый файл не только с паролем от админ-панели, но и вообще от всех аккаунтов владельца сайта.
Электронные кошельки, аккаунты от различных соц. сетей, пароли и логины от google и Яндекс аккаунтов - всё это было в открытом доступе. Я сообщил админу и этот ftp закрыли от посторонних глаз.
Все логины и пароли нужно хранить в менеджере паролей. Их существует много, но нас интересуют только решения с открытым исходным кодом, потому что таким образом мы можем убедиться что наши пароли действительно шифруются и никто кроме нас не имеет к ним доступа. Менеджер паролей
Ссылка скрыта от гостей
отлично для этого подходит.На этом примере мы можем убедиться что даже если приняты все меры безопасности, все сервисы обновлены до последней версии, порты закрыты и везде используются сложные для подбора пароли, то уязвимость может быть в человеческом факторе. Если вы владелец сайта или компании, то проводите инструктаж для каждого сотрудника. Неважно кто он: разработчик, системный администратор или уборщик.
Также в вашей инфраструктуре должно быть правильное разграничение прав для каждого. Это должно быть как в админ-панеле так и в корпоративной сети. Разработчики не должны иметь доступ к настройке конфигурации сервера, а тестировщики не должны иметь такие же права как и разработчики.
CSRF в регистрации
На сайтах с авторизацией по sms часто встречается CSRF, что может привести к sms-флуду и даже к account takeover. Нужно делать тайм-аут между запросами на отправку sms и не передавать текст сообщения в post-запросе на стороне клиента. Иногда бывает что тайм-аут есть, но он на стороне клиента. Так делать тоже нельзя по понятным причинам.
Если CSRF допущено в обычной регистрации через e-mail, то злоумышленник может написать скрипт, который будет постоянно регистрировать новых пользователей.
Фактически это будет DoS атака.
Как защититься от CSRF? Для каждого действия, совершаемого пользователем, нужно генерировать уникальный токен. Сервер должен создавать токен используя алгоритмы, которые не имеют уязвимостей. Важен и размер токена, чем он длиннее тем сложнее его подобрать. Токен должен иметь определенное время, после которого он перестает действовать.
Поддомен, который никто не найдёт
Начинающие разработчики думают что их поддомен для тестирования (test.example.com и т.п.) никто не найдет, но оказывается что он индексируется поисковиками или его можно найти простым перебором поддоменов.
И на таких поддоменах обычно есть файлы с чувствительной информацией, конфигурационные файлы и прочее. В моём случае тут даже можно скачивать любой файл, независимо от расширения.
Есть много утилит для поиска поддоменов, можете написать свою. Самая популярная - Sublist3r.
Чтобы такого не случилось нужно ограничить доступ к поддоменам, а лучше просто не тестировать новые функции на поддоменах.
Злоумышленники используют перебор поддоменов не только с целью найти уязвимые сервисы, конфигурационные файлы и другую важную информацию, но и для DoS атак. При неправильной настройке основной домен защищён от атак отказа в обслуживании например сервисом CloudFlare, а домен mail.example.com не находится под CloudFlare и выдаёт настоящий ip-адрес сервера.
Передача параметров в post запросе, которые не нужно передавать
В данном случае в post запросе можно изменить не только имя аккаунта но и баланс! Это очень серьёзная уязвимость, хоть и глупая.
На скриншоте ниже показано как можно подменить эти данные в сервисе для рассылки сообщений.
Как это можно использовать? Например для stored XSS. Если нет защиты от XSS и присутствует данная уязвимость, то реализовать stored XSS очень просто.
(на скрине xakep.ru потому что писал изначально статью для него, а потом забил и запостил к себе в канал)
Уязвимости в сервисах, банальная SQL инъекция
Нужно постоянно обновлять все сервисы и следить за уязвимостями в них, иначе какой-нибудь бот, который автоматически эксплуатирует уязвимости в веб приложениях, загрузит вредоносный код и на ваш сервер. В моём случае на сайте была sql инъекция и в итоге 3 тысячи аккаунтов ВКонтакте и другие персональные данные могли оказаться в руках злоумышленника. Уязвимость ещё не исправили, владельцу всё равно на персональные данные пользователей. Чаще всего sql уязвимости присутствуют в самописных CMS и необновленных популярных CMS.
Если вам без разницы какую CMS использовать, то пользуйтесь популярными решениями и постоянно обновляйте до последней версии. На скриншоте видно что к некоторым хэшам подобрались пароли. Чтобы такого не происходило - проверяйте пароль пользователя при регистрации, и если он находится в списке самых популярных паролей, не имеет цифр или слишком короткий, то отклоняйте регистрацию и предупреждайте пользователя о том, какой должен быть пароль чтобы его не подобрали. Для безопасного хранения паролей ваших пользователей в базе данных используйте хэш-функцию bcrypt.
Да, всё описанное в статье - банальные вещи, но нужно обращать внимание на такое в самую первую очередь, независимо от того пентестер ли вы или владелец сайта.
Я надеюсь что вы не будете делать подобных ошибок, будете всё логировать и вовремя реагировать на различные инциденты.
Последнее редактирование:
