Немецкий ID
Специалист по безопасности Вольфганг Эттлингер из SEC Consult Vulnerability Lab описал технику подделки данных (в том числе имени и адреса) при онлайновой проверке государственных немецких ID.
Немецкие ID-карты выпускаются с 1 ноября 2010 года. Каждая карта содержит чип RFID, в котором хранится информация о владельце, в том числе имя, дату рождения и биометрическая фотография. Если владелец захочет, то может записать скан отпечатков пальцев.
Новые карты являются машиночитаемыми и могут использоваться в качестве проездных документов в большинстве стран Европы, а также для аутентификации в онлайн-государственных службах (налоговые, почтовые) или для проверки возраста. Они используются для аутентификации пользователей в некоторых онлайн-сервисах, в том числе на портале подачи налоговых деклараций.
Аутентификация через RFID происходит с помощью карт-ридера и клиентского приложения eID (например, AusweisApp 2), которое взаимодействует с чипом RFID и сервером аутентификации (eID-Server или SAML-Processor) для проверки данных входа в систему.
Чтобы предотвратить подделку данных удостоверения личности, сервер проверки подлинности проверяет достоверность информации, а затем подписывает ответ, который отправляется веб-слубе от клиента, чтобы веб-служба могла доверять легитимности полученных данных.
Вольфганг Эттлингер нашёл способ обмануть веб-приложение, отправив ему изменённые данные. На скриншоте показано, как он успешно аутентифицировался в официальном приложении под именем Иоганна Вольфганга фон Гёте, известного немецкого писателя. В форме указан адрес, по которому писатель прожил 50 лет, где сегодня находится музей Гёте.
Уязвимость оказалась в Governikus Autent SDK, программном компоненте для интеграции функции аутентификации в веб-приложения. В том числе он реализует функцию проверки аутентификации от клиента eID. Суть в том, что проверка выполняется в два независимых этапа. На первом этапе проверяется валидность подписи сервера аутентификации, а на втором этапе — сами данные, в том числе о личности владельца. В результате появляется возможность отправить приложению два независимых SAML-ответа: первый с валидной подписью, а второй — с поддельными данными и без подписи.
Эксплоит использует тот факт, что Governikus Autent SDK проверяет подпись с помощью метода HttpRedirectUtils.checkQueryString, который не рассматривает возможность использования одинакового параметра несколько раз. Таким образом, после проверки параметра другие экземпляры анализируются так, как будто они уже прошли проверку.
Вот как применяется этот метод в реальном приложении:
// check the signature of the SAML response. There is no XML signature in this response but the
// parameter are signed.
if (!HttpRedirectUtils.checkQueryString(request.getQueryString(), SamlExampleHelper.SERVER_SIG_CERT))
{
storeError(request, response, "Signaturprüfung der SAML-Response fehlgeschlagen!");
return;
}Метод получает строку запроса, анализирует ее, создает каноническую версию строки запроса и проверяет подпись.
Затем парсится ответ SAML:
// get the parameter value
String samlResponseBasee64 = request.getParameter(HttpRedirectUtils.RESPONSE_PARAMNAME);
[...]
// parse the SAML Response.
ParsedResponse parsed = parser.parse(samlResponse);
Как уже было сказано, HttpRedirectUtils.checkQueryString не рассматривает возможность использования параметра несколько раз, всегда используя последнее значение параметра.
Для успешного использования уязвимости злоумышленнику требуется строка запроса, подписанная сервером проверки подлинности. Такие детали, как время подписания или лицо, для которого это было запрошено, не имеют значения. Даже если строка запроса действительна в течение короткого периода, проверка срока действия выполняется для данных на идентификационной карте. По мнению исследователя, получить валидный запрос не составит труда, если знать, где искать, так как они доступны с помощью поиска Google по логам клиентов eID.
Исследователи демонстрируют свои результаты на видео:
Уязвимы веб-приложения, работающие под управлением Governikus Autent SDK 3.8.1 и более ранних версий, обрабатывающие повторяющиеся параметры HTTP. Уязвимость можно использовать, например, для регистрации в онлайновых сервисах под вымышленным именем.
Зачем может понадобится такая подделка имени? Можно привести такой отвлечённый пример. Недавно МВД Германии запустило инициативу «Добровольное возвращение», в рамках которой финансирует любого иностранца, который пожелает добровольно уехать домой. Правительству оплата билета и проживания обходятся дешевле, чем принудительная депортация беженца (700 против 1500 евро), то есть финансирование имеет смысл.
Рекламная кампания в берлинском метро: беженцам, до 31 декабря уведомившим власти ФРГ о своем добровольном отъезде на родину, компенсируется годовая аренды жилья в родной стране
Теоретически, любой иностранец может приехать в Германию, подать заявление на статус беженца, получить отказ — и сразу финансироваться по этой программе. Единственная проблема для мошенника, что проделать такой фокус можно только единожды. Очевидно, затем службы будут проверять, что на его имя ещё не выдавалось пособие. Но если зарегистрироваться в программе под другим именем, то деньги можно получать многократно (теоретически).
Конечно, спуфинг государственных немецких eID никак не поможет мошеннику с иностранным паспортом прибыть в Германию под новым именем. Но этот пример показывает, что в каждой системе защиты обязательно есть уязвимости. Вопрос только в желании и ресурсах, чтобы их найти.
Автор: GlobalSign_admin
