Уязвимости бизнес-логики не новы, но они часто остаются непроверенными (и незамеченными), потому что злоумышленники могут найти недостатки в реализации (почти) любого веб-приложения.
Эти недостатки особенно опасны, потому что злоумышленники используют поведенческие модели, взаимодействуя с приложениями не так, как было задумано. При успешной эксплуатации они приводят к серьезным нарушениям, включая воздействие на бизнес-процессы и репутационный ущерб.
Почему же компании должны беспокоиться о недостатках бизнес-логики и как их обнаружить и сообщить о них?
Давайте познакомимся с этими уязвимостями безопасности поближе.
Почему уязвимости бизнес-логики имеют значение — реальная история
Давайте поговорим о том, как злоумышленники используют недостатки бизнес-логики для компрометации критически важных функций организации.
Но сначала позвольте мне рассказать вам короткую историю об ограблении банка, в которой главными героями являются хакеры. Я говорю о знаменитом ограблении Национального банка Бангладеш в 2016 году, когда группа хакеров проникла в сеть банка через фишинговое электронное письмо. Их целью было украсть миллиард долларов и скрыться. И им это почти удалось.
Они тщательно спланировали операцию: взломать сеть, получить доступ к терминалу SWIFT для осуществления перевода и бесследно исчезнуть. Если вы знакомы с историей ограбления, стоит упомянуть некоторые важные моменты в стратегии злоумышленников: время, принтер, терминал SWIFT и многое другое. Но сегодня мы сосредоточимся на принтере и терминале SWIFT.
Это были уязвимости бизнес-логики, что позволило противникам манипулировать ими и использовать в своих атаках.
Принтер (единственный и неповторимый) был безотказным механизмом для транзакций SWIFT. Когда транзакция была завершена, принтер быстро выводил ее на бумагу. Если бы что-то было не так, транзакция была бы отмечена как подозрительная и отклонена. Но злоумышленники знали об этом — после наблюдения за рабочим процессом банка — и взломали принтер. В результате их вмешательства принтер вышел из строя и распечатал пустые страницы записей о транзакциях.
Второй момент — это протокол SWIFT. Все знают, что этот протокол очень безопасен, поэтому транзакции SWIFT считаются безопасными. Так вот, злоумышленники воспользовались этим недостатком бизнес-логики. Они знали, что невозможно легко взломать протокол SWIFT, которому доверяют другие банки, поэтому они взломали компьютер, обрабатывающий эти транзакции SWIFT. Они взломали эту систему и легко перевели средства на свои счета.
Что мы узнали из этой истории?
После этого инцидента система обмена сообщениями SWIFT призвала банковские учреждения по всему миру сокращать площадь атаки.
Эта атака стала важным напоминанием о том, что киберпреступники настойчивы и изобретательны, особенно когда они стремятся получить доступ к дорогостоящим сетям и украсть большую сумму денег. Более того, эта атака также подчеркивает необходимость пентеста для организаций.
Главный вывод заключается в том, что большинство компаний склонны воспринимать безопасность своих устройств как должное. Защита аппаратного или программного обеспечения — это всегда работа других людей. В данном случае жертва может сказать, что это ответственность поставщика принтера. Но это также ответственность банка, который мог провести сканирование уязвимостей или тесты на проникновение, включив IP-адрес принтера в область действия.
Валидация только на стороне клиента
Часто злоумышленники используют клиентскую сторону как отправную точку в своем процессе, чтобы подделать данные в середине трафика. Они используют специализированные инструменты, такие как Burp, для перехвата данных, отправляемых с клиентской стороны на серверную. Другими словами, им удается обойти процесс проверки.
Это позволяет злоумышленнику отправить данные на сервер и потенциально повредить систему.
История захвата учетной записи из реальной жизни
Одному из клиентов одной компании необходимо было провести тест на проникновение в веб-приложение, которое управляло транспортными услугами.
Аутентификация казалась надежной, поскольку требовала 2FA-аутентификации в виде OTP (одноразового пароля), полученного по электронной почте.
Аналогичная процедура применялась и к функции сброса пароля. Пользователь просил сбросить пароль, ему сообщалось имя пользователя, после чего он должен был ввести действительный OTP.
Теперь вы можете подумать, что такие значения OTP иногда можно угадать (плохая реализация может помочь злоумышленнику провести атаку и найти действительный OTP), или что они могут быть предсказуемы, или даже не подтверждены.
На этот раз проблема оказалась еще более неожиданной. Как только пользователь запрашивал либо сброс пароля, либо аутентификацию входа с известной комбинацией имени пользователя и пароля, веб-приложение запрашивало OTP, но также предоставляло его в POST-ответе.
Эта серьезная ошибка в конфигурации позволила завладеть любой учетной записью, включая учетные записи с ролью администратора.
Шаги для захвата учетной записи пентестером
Вот 6 шагов, которые может выполнить злоумышленник при атаке на захват аккаунта:
- Имитировать поведение легитимного пользователя и попросить сбросить пароль для учетной записи жертвы
- Ввести недействительный OTP и проверить ответ сервера.
- Отправить действительный OTP и смените пароль жертвы. Еще одна проблема здесь заключается в том, что пользователь никак не оповещается о том, что его пароль был изменен (например, по электронной почте).
- Войти в систему с новыми учетными данными.
- Отправить недействительный OTP, чтобы получить обратно действительный OTP.
- Войти в систему с действительным OTP. Теперь злоумышленник вошел в систему как жертва.
Основной риск заключается в том, что любой человек может завладеть учетными записями с высокими привилегиями, принадлежащими клиентскому приложению.
Приведенный выше пример — это скрытый на виду недостаток бизнес-логики. Несмотря на то, что целью было обеспечить дополнительный уровень безопасности, эта функция фактически помогла злоумышленнику скомпрометировать учетную запись пользователя, если у него был список действительных имен, который хакер мог найти с помощью методов OSINT.
Три принципа поиска уязвимостей
Итак, вот 3 принципа, которых должны придерживаться пентестеры при поиске дефектов бизнес-логики:
- Понимайте назначение тестируемого веб-приложения, а также то, как пользователи взаимодействуют с ним и какие права нужны для выполнения определенных действий.
- Постоянно спрашивайте себя: имею ли я право выполнять это действие? А что, если…? Подвергайте все сомнению.
- В большинстве случаев сообщение об ошибке — это всего лишь самые явные уязвимости. Нужно проводить глубокие проверки.
Эти принципы могут помочь выявить менее очевидные уязвимости кибербезопасности, которые в руках злоумышленника могут нарушить всю работу системы.
5 способов предотвращения ошибок бизнес-логики в ваших веб-приложениях
- С самого начала разрабатывайте веб-приложения с учетом требований безопасности.
- Используйте лучшие практики безопасного кодирования при разработке веб-приложений.
- Следуйте методологии тестирования безопасности и контрольным спискам при проведении внутренних оценок (например, OWASP Top 10).
- Убедитесь, что ваше приложение имеет четко определенную, поддерживаемую и внедряемую матрицу со всеми ролями и разрешениями пользователей, и что все запросы проверяются в бэкенде на основе разрешений этих пользователей.
- Привлекайте специалистов по пентесту для проведения регулярных тестов на проникновение на ранних стадиях, еще до развертывания приложения в производство.
Итоги
Мы надеемся, что это руководство поможет вам включить тактику поиска уязвимостей бизнес-логики в ваши проекты.
В заключение напоминание для руководителей: хакеры не играют по вашим бизнес-правилам. Именно поэтому вам нужен пентест, в котором участвуют люди, делающие то же самое, но без злых намерений.
