Блог

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

ТОП-10 уязвимостей безопасности ПО от компании «Технологии качества». Часть 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 и с их помощью получили доступ к панели администрирования.

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

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

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

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

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

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