Команда по тестированию безопасности проверяет вебсайты, приложения и другие программные продукты на наличие уязвимостей, ставящих под угрозу защищенность продукта, и составила
рейтинг 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 и с их помощью получили доступ к панели администрирования.
Причина: использование приложением и сервером уязвимых системных компонентов.
Возможное последствие: доступ к панели администрирования.
Естественно, что заказчики были предупреждены и получили подробное описание всех обнаруженных уязвимостей, а также рекомендации по их устранению. А наша команда получила заслуженные похвалы.
Продолжение читайте
здесь.
