Секрет названия

Есть у меня проблема: когда некоторые шутят я не смеюсь, а когда шучу сам - также не смеются, проблема...

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

Слово "православный" дословно означает "правильный", однако, вместе с тем, имеет очевидный религиозный оттенок: православная вера неразрывно связана с Россией, со всем русским, каждый из нас, русских, с детства, может, даже, не задумываясь, понимает словосочетание Святая Русь. С учетом этого, слово "православный" допустимо понимать как "правильный русский" или "правильный российский" (отличие "русского" от "российского" - не предмет этого поста). Применительно к криптографии "правильными российскими" являются наши криптографические ГОСТ-ы, о чем и говорили в презентации.

Исследование было именно "некриптографическим", поскольку в докладе совсем не было математики, да и вообще, исследовались носители, о чем, в общем-то, в названии явно указано.

Презентация была умышленно сделана на русском языке, так как она не адресована тем, кто русский не может понимать :)

ZN2015: HQLi

Вчера с Мишей делали доклад на конференции. Выкладываю презентацию:

ORM2Pwn: Exploiting injections in Hibernate ORM from Mikhail Egorov, OSCP, CISSP, SPSE

демонстрационное видео, и скрипты, традиционно, доступны.

Судя по общению после доклада есть необходимость прояснить некоторые моменты.
1. Причина работы всех показанных эксплуатаций - ошибка программиста приложения:
 
Т.е. уязвимость, которую мы здесь эксплуатировали связана не с ошибками в Hibernate. Защита от таких уязвимостей стандартна, как и в SQLi, - использование параметризованных запросов. Вариант с атакой на параметризованные запросы мы не рассматривали, так как в этом случае не будет работать и SQLi, а доклад, главным образом, о том, как HQLi сводится, в частности, к bSQLi. Дополнительный аргумент "ЗА" исключение из рассмотрения варианта атак на параметризованные HQL-запросы в том, что для "эскейпинга" параметров HQL, очевидно, используется функция драйвера СУБД, поэтому если в этой функции есть ошибки, то их можно эксплуатировать не только в HQL, проблема в этом случае будет намного более глобальная*. Тем не менее, у меня в планах есть пофаззить юникодом то же приложение, но переписанное через параметризованный запрос, - в этом случае, если что-то получится, уже будет проблема даже не в самом Hibernate, а в СУБД, и ее можно будет зарепортить :)

2. Что здесь нового? Нового здесь то, что продемонстрировано как свести HQLi к bSQLi, т.е,. фактически,  забайпассить Hibernate. Здесь показано, что несмотря на то, что HQL имеет очень ограниченный синтаксис, что не позволяет нам формировать сложные HQL-запросы, как это можно в SQL, есть техники, позволяющие "обмануть" Hibernate, пробросить запрос непосредственно в СУБД и выполнить там инъекцию.

В докладе мы показали эти техники и рассказали для каких СУБД какие работают. В целом, техники не новы, однако, ново их применение для байпасса Hibernate.

 3. После доклада подбежали ребята от которых я узнал, что задачка байпасса Hibernate через эскейпинг ковычки была на каком-то хак-квесте, ребята просили пояснить как это работает. Поскольку ковырялся в основном с MSSQL и юникодом,  я затупил и не смог это пояснить (хотя уже позже сообразил, что на слайде 8 все предельно понятно :) ), однако, Миша все рассказал, ребята ушли довольные. В целом, коллеги хак-квест-разработчики, можете брать все приведенные в презентации трюки на вооружение и включать их в новые хак-квесты.



Традиционно хочу поблагодарить моего напарника Мишу за обнаружение этой, на мой взгляд, интересной темы, а также, конечно же, супругу, которая в очередной раз мне обещала, что эта конференция для меня последняя, но по глазам было понятно, что продолжение, обязательно, последует...

* HQL-запрос: SELECT p FROM hqli.persistent.Post p where p.name =:name
запрос SQL, к которому его приводит Hibernate: select post0_.id as id1_0_, post0_.name as name2_0_ from post post0_ where post0_.name=?
Hibernate не фильтрует параметры и не строит запрос, это все делает СУБД => ломать параметризованные запросы в Hibernate - все равно что ломать их в СУБД.