Возможна ли атака с дополнением Oracle с ответом всегда 200 OK

#asp.net #security #cryptography #padding-oracle-attack

#asp.net #Безопасность #криптография #заполнение-oracle-attack

Вопрос:

В настоящее время я выполняю тестирование на проникновение ASP.NET приложение и попытка использовать атаку Оракула с заполнением. Этот AFAIK основан на анализе кода ответа, но как ScriptResource, так и WebResource axds тестируемой системы всегда отвечают «200 OK», даже если cipher был недействительным. В этом случае, однако, содержимое ответа представляет собой пустую строку.

Возможно ли использовать какой-либо axd в качестве oracle в этом случае? Возможно, на основе разницы в содержимом ответа.

Ответ №1:

Атака с добавлением Oracle работает, позволяя различать два случая:

  • Серверу не удалось расшифровать данные, потому что при расшифровке он не нашел правильно отформатированное заполнение.
  • Сервер нашел правильное заполнение, но расшифрованные данные оказались случайным мусором.

У злоумышленника может быть несколько способов получить такое различие. Использовать конкретный код ошибки с сервера проще всего; но достаточно любого обнаруживаемого различия. Атака была впервые опубликована в 2002 году (да, потребовалось 8 лет, чтобы люди заметили, что ее можно применить к ASP !) и она была продемонстрирована на SSL-соединении только с разницей во времени: сервер расшифровывал данные, а затем проверял MAC, только если расшифровка прошла нормально; дополнительных 2 мс, потраченных вычислением MAC, было достаточно, чтобы злоумышленник узнал, было ли заполнение допустимым, что позволило напрямую применить атаку Padding Oracle.

Ответ №2:

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

Чтобы ответить на ваш ответ Troy, большая длина зашифрованного текста не указывает на то, что они уязвимы. Обычно короткая длина зашифрованного текста указывает на то, что они уязвимы, но вам нужно декодировать значение net URL, а затем посмотреть, модуль 8 = 0, чтобы увидеть, уязвимо ли оно. Другими словами, длина будет кратна 8. Обычно я вижу, что один блок зашифрованного текста (16 байт) заканчивается примерно 25 байтами, как только он закодирован в точечный сетевой URL. Исправление включает в себя HMAC (я думаю), который увеличивает длину и должен сделать невозможным использование одного блока cipertexts. Я не могу сказать это с уверенностью, поскольку я не уверен, как долго длится HMAC и работает ли он после заполнения или нет.

Ответ №3:

Мне кажется, что, возможно, был установлен патч padding oracle, и в результате вы не получаете коды ошибок, которые ожидали. Посмотрите, Доверяете ли вы своему хостинг-провайдеру и действительно ли они установили исправление Oracle для добавления и посмотрите, сможете ли вы это установить.

Комментарии:

1. Исправление не было установлено до тех пор, пока длина шифрования указывает на его уязвимость.