Возможно ли заполнение Oracle Attack при ответе 200 OK?

Question

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

Можно ли в этом случае использовать любой аксд в качестве оракула? Возможно, исходя из различий в содержании ответа.

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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