Блог A1QA

О тестировании и качестве ПО

ТОП-10 уязвимостей безопасности ПО от A1QA. Часть 1

Команда по тестированию безопасности проверяет вебсайты, приложения и другие программные продукты на наличие уязвимостей, ставящих под угрозу защищенность продукта. Вадим Кулиш составил рейтинг 10 видов критических уязвимостей, которые были обнаружены его командой на реальных проектах.

Уязвимости упорядочены по сложности их обнаружения. В данной статье указаны 5 наиболее простых из них, а в следующей – уязвимости, обнаружение которых требует глубоких знаний в области информационной безопасности.

1. Google Dorks

Google Dorks и как они могут быть использованы злоумышленниками, мы уже рассказывали здесь. Коротко напомним, Google Dorks – это ключевые слова, с помощью которых можно повысить эффективность поиска:

  • site: — поиск на определенном сайте;
  • filetype: — поиск файлов определенного типа;
  • inurl: — поиск в URL страницы;
  • intitle: — поиск в заголовке страницы.

Эти же операторы поиска могут быть использованы хакерами для обнаружения ненадежно защищенной информации.

В нашем случае мы работали над анализом защищенности веб-сайта одного банка и, введя в Google запрос site:example.com filetype:pdf (example.com — сайт заказчика), обнаружили множество pdf-документов.  Данная уязвимость вряд ли бы заслужила нашего внимания, если бы эти документы не представляли собой планы помещений банка. С такими данными можно было уверенно идти «на дело».

Причина возникновения: неправильная конфигурация веб-сервера.

Возможное последствие: утечка конфиденциальных документов.

2. Утечка данных

При аудите безопасности мы всегда проверяем ряд ресурсов на наличие утечек. Среди них можно выделить 4 наиболее популярных пути поиска информации:

  • Github (ищем исходные коды, пароли, адреса);
  • Забытые файлы на сервере с конфиденциальной информацией (резервные копии, исходные коды, информация об установленном ПО);
  • Версии для разработчиков и тестировщиков (они, как правило, работают в режиме отладки и при ошибке показывают важную информацию о работе приложения);
  • Pastebin.com (на данном сайте разработчики делятся полезной информацией).

Перебирая данные ресурсы при тестировании сайта интернет-магазина, мы обнаружили на сервере dev-версию сайта. В данной версии содержалось множество параметров веб-приложения, и в том числе, данные для подключения к API PayPal. C их помощью можно было подключиться к аккаунту магазина. Очевидно, что если бы утечка была обнаружена хакерами, то магазин понес бы серьезные убытки.

Причина возникновения: неправильная конфигурация сервера.

Возможное последствие: утечка конфиденциальных данных для подключения к PayPal.

3. SSL DoS

DoS (Denial of Service) — хакерская атака на сервер с целью вывести его из работы. Данную тему мы ранее рассматривали в этой статье.

Немного технической информации. Протокол HTTPS представляет собой расширенный протокол HTTP, работающий через  механизмы шифрования. При создании защищенного соединения клиентская и серверная части «договариваются» о ключах шифрования. При неправильной настройке сервера клиент может запрашивать создание защищенного соединения несколько раз. Проблема в том, что в таком случае сервер затрачивает в 10 раз больше ресурсов, чем клиент. В среднем, сервер может обработать 250-300 запросов на создание защищенных соединений в секунду. В то время как обычный компьютер позволяет генерировать до 1000 запросов на создание защищенных соединений.

Выполняя анализ защищенности мобильного банкинга, мы проводили DoS-атаки. Одна из атак сработала. Прелесть данной уязвимости для злоумышленников была в том, что ее было сложно обнаружить: сайт «не падал» после атаки. Как только мы отключали свои программы, он возобновлял работу.

Причина: неправильная настройка https-сервера.

Возможное последствие: полная блокировка работы сервера.

4. Подбор одноразового пароля

Мы проводили тестирование безопасности мобильного приложения и неожиданно смогли получить доступ к аккаунту любого пользователя. Причина крылась в ошибке построения процесса аутентификации.

Нужно пояснить, как выглядел процесс аутентификации в приложении. В его основу был положен механизм использования одноразового пароля. Пользователь вводит номер телефона, ему приходит одноразовый код в SMS. Пользователь вводит код и авторизуется в приложении. При этом сервер отправляет SMS с одноразовым паролем, а затем проверяет пароль, присланный пользователем.

Что же мы обнаружили? Мы сразу обратили внимание на то, что код цифровой и должен был состоять из 4 цифр. А это всего лишь 10000 возможных комбинаций. И мы решили проверить возможность подбора пароля. В идеале, у пользователя должно быть не более трех попыток введения пароля. После третьей неудачной попытки сервер должен блокировать пользователя. Однако в нашем случае этого не происходило.

Тогда мы решили примерить на себе роль пользователя приложения. Отправили SMS с мобильного телефона и получили код. Но вводить его не стали, а начали подбирать. Код нам удалось подобрать за 15 минут. Однако этим мы не ограничились, а решили процесс подбора пароля автоматизировать. В итоге у нас получился небольшой скрипт, который позволял осуществлять вход в приложение, зная только номер телефона пользователя. Опасность заключалось ещё в том, что приложение являлось мессенджером, и аутентификация в приложении позволяла получить доступ к переписке пользователя. При этом ничего не подозревающий пользователь видел только входящее SMS с кодом.

Причина: недостаточное противодействие автоматизации, ошибка логики работы.

Возможное последствие: доступ к аккаунту любого пользователя мобильного приложения.

5. Обход аутентификации в панели администрирования

Самый быстрый взлом, который занял всего минуту!

Заказчик обратился к нам для тестирования интернет-магазина. В поисках «узких» мест мы нашли сервер панели администрирования. А через минуту мы уже смотрели на панель администрирования. Как нам это удалось?

Все благодаря уязвимости HeartBleed, которая появилась в библиотеке OpenSSL (используется для создания зашифрованных соединений) еще в 2014 году. Данная уязвимость позволяет читать память на сервере или клиенте. В нашем случае это был HTTPS веб-сервер, в памяти которого хранились все запросы от пользователя. Используя данную уязвимость, мы извлекли параметры cookie и с их помощью получили доступ к панели администрирования.

Причина: использование приложением и сервером уязвимых системных компонентов.

Возможное последствие: доступ к панели администрирования.

Естественно, что заказчики были предупреждены и получили подробное описание всех обнаруженных уязвимостей, а также рекомендации по их устранению. А наша команда получила заслуженные похвалы.

Продолжение читайте здесь.

А с какими интересными уязвимостями приходилось встречаться вам? Делитесь опытом в комментариях!

Поделиться статьей: