Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Методы Защиты Асушников / лабы Васильева / Практикум Безопасность ДБО.docx
Скачиваний:
34
Добавлен:
15.06.2014
Размер:
934.83 Кб
Скачать
      1. Проблема № 7 – Изменение шаблона платежа

Изменение шаблона платежа. Использование шаблонов платежей позволяет сократить время на ввод однотипных данных — номера счета получателя и ФИО получателя. Если у злоумышленника есть возможность изменять данные шаблона, то он без труда сможет заменить счет получателя, указав свой. Пользователь, скорее всего, не заметит подмены и подтвердит выполнение транзакции.

      1. Проблема № 8 – Обход аутентификации

HelpDesk — обход аутентификации. Помимо системы ДБО специалистами Positive Technologies была реализована примитивная система для сотрудников банка — HelpDesk. Попав в систему «не для всех», можно получить достаточное количество информации, которая значительно упростит взлом целевой системы. На практике «злоумышленник» мог ознакомиться с парольной политикой, информацией о механизмах защиты и даже паролях пользователя.

Для эксплуатации уязвимости в тестовой системе HelpDesk хорошо подходила утилита Modify Headers

Утилита Modify Headers позволяет, не зная логин или пароль, обходить аутентификацию с помощью передачи в каждом HTTP-запросе специального заголовка

      1. Проблема № 9 –Race condition

HelpDesk — Race condition. Если отправлять много запросов, то возможна ситуация, когда запросы будут выполняться одновременно. Чтобы защититься от Race condition и исключить ситуацию появления денег из ниоткуда, nginx был настроен на блокирование слишком частых обращений, а именно — не более трех запросов в секунду к сценарию, осуществляющему транзакции. На виртуальных машинах nginx установлен не был, и один из участников обнаружил проблему Race condition.Если отправлять много запросов, то возможна ситуация, при которой запросы будут выполняться одновременно

      1. Как это было на phDays

За сутки до начала соревнования участникам был предоставлен исходный код систем, а также виртуальная машина с установленным клиентом PHDays I-Bank. Участники должны воспользоваться обнаруженными уязвимостями — на этот этап выделялось 20—30 минут. Важную роль в успехе играли автоматизация и многопоточность.

Стратегию прохождение конкурса можно было разделить на две основные задачи. Во-первых, необходимо было получить доступ к учетной записи, используя простые и словарные пароли, слабую энтропию ключа для восстановления пароля и слабую энтропию идентификатора сессии. Во-вторых, требовалось обойти OTP. Способы обхода OTP отличались для разных учетных записей – и участникам нужно было предусмотреть различные способы обхода.

Призовой фонд «Большого куша» составлял 20 000 руб. Деньги в системе PHDays I-Bank были распределены по следующему принципу: чем сложнее было получить доступ к определенному сегменту, тем большая сумма там находилась. Учетные записи, с которых осуществлялась демонстрация, имели слабые пароли: 1234567 и password. Участники также имели уязвимые учетные записи: идентификатор сессии обладал слабой энтропией.

Далее рассматриваются примеры практической эксплуатации уязвимостей PHDays I-Bank.

    1. Примеры практической эксплуатации уязвимостей

      1. Уязвимость через helpdesk

helpdesk/pswdcheck.php helpdesk/index.php

1

2

3

4

$user = $auth->checkSession();

if(!$user) {

/* ... */

}

class/HelpdeskAuth.php

1

2

3

4

5

6

7

8

public function checkSession() {

 

if(isset($_SERVER["HTTP_BANKOFFICEUSER"])) {

    $userId = base64_decode($_SERVER["HTTP_BANKOFFICEUSER"]);

    $userInfo = $this->user->getUserInfoById($userId);

    $this->user->setupUserInfo($userInfo);

    return $this->user;

}

При отправке HTTP-header BANKOFFICEUSER с любым значением можно обойти авторизацию и получить доступ к скрипту, который выводит пользователей со слабыми числовыми паролями. Для подбора 5-символьного пароля пользователя требуется 100 тысяч запросов. Присутствует captcha, но она нисколько не мешает, так как есть обход:

login.php

1

if($_POST["code"] != $captcha->decodeCaptchaCode($_POST["_code"])) {

class/Captcha.php

1

2

3

public function decodeCaptchaCode($code) {

    return @base64_decode(@strrev(@base64_decode($code)));

}

З

Здесь все просто: для обхода нужно отправлять в POST, например, такие параметры: code=”12345” и _code=”PVVETnpJVE0=”.

Получив доступ к аккаунту, для перевода денег на свой счет необходимо использовать еще одну уязвимость. На одних аккаунтах транзакции могут проводиться без защиты, а на других с помощью одноразовых паролей. Эти одноразовые пароли генерируются следующим алгоритмом:

1

2

3

4

5

6

7

8

9

10

11

12

13

protected function generateOTP() {

    $OTPs = array();

    $s = 44553 + $this->userInfo["id"];

    for($n = 10; $n < 24; $n++) {

        $OTP = "";

        $j = rand(20,39);

        $j = substr($j, 0, 1);

        $OTP = $n*$s*$j;

        $OTP = substr($OTP, 0, 5);

        $OTPs[] = $OTP;

    }

    return $OTPs;

}

Понятно, что осуществить подбор очень просто – всего 2 варианта. Существует еще один способ защиты транзакций,  при переходе на третий шаг авторизации OTP не проверялся.

Соседние файлы в папке лабы Васильева