Почему биометрия слаба?

Мы не требуем от вас невозможного, мы прекрасно понимаем, что при современных методах допроса у вас нет никаких шансов сохранить тайну

Р. Хайнлайн, "Двойная звезда" 

Если читать книжки по безопасности, то оттуда можно узнать, что биометрия - наиболее стойкий фактор аутентификации из оставшихся двух ("что я знаю" и "что я имею"). С ментальной точки зрения - это правильно, ибо подтвердить что я - это я наилучшим образом может фактор "что я есть", поскольку остальные два связаны с наличием некоторой тайны/секрета, биометрия же, по своей изначальной сути, не может быть препарирована, даже с использованием современных методов допроса.

Но проблема, как всегда в том, что компьютер - не человек. Во-первых, компьютер вынужден преобразовывать то, что ему подсунул аутентифицируемый на анализ в свое представление, чтобы затем иметь возможность это обрабатывать. Конечно же эти преобразования "человеческого" в "машинное" и обратно можно успешно атаковать. Весьма красочно это проблему раскрыл Виктор Пелевин в "Зенитные кодексы Аль-Эфесби", конечно же мое описание теории вопроса с не сравнится. Такие уязвимости (раз, два, три, ...), скорее всего, будут всегда, пока человеку будет хватать фантазии догадаться что показать компьютеру, чтобы последний принял нужное человеку решение (то, что на протяжении всей истории Человечества есть и процветает искусство, доказывает, что человеческая фантазия не иссякнет никогда). Наверно, развитие этих преобразований биометрии в компьютерные представления можно сравнить с технологиями распознавания речи или препятствий при движении, что можно делать с помощью нейросетей, например, но тогда мы можем получить высокую сложность системы, что увеличивает вероятность ошибок реализации, багов, которые также можно эксплуатировать. 

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

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

Фактическое назначение сертификации

Много было написано об нереализации сертификацией своей основной задачи: защиты потребителя от некачественного товара, и вот очередное событие (дам несколько ссылок: раз, два, три ), причем продукт был сертифицирован. 

В очередной раз перечитал на что была сертификация... и только сейчас до меня дошло фактическое ее назначение! Сертификация мне подтверждает, что продукт, который я приобретаю может быть отнесен к определенному классу, беря во внимание наш пример, с чего начали, сертификация мне подтверждает, что покупаемый мною Juniper NetScreen-ISG может называться межсетевым экраном. Хорошо то, что сертификация по факту имеет смысл: если у вас есть сомнения в классификации того или иного продукта - сертификат вам подскажет, однако плохо то, что это знание мне, в общем-то, не нужно, поскольку я выбираю инструмент под свои цели и задачи, => мне важно что продукт умеет и насколько хорошо фактически он это делает, а не то, как он классифицируется или как называется.

 

О нарушении причинно-следственной связи

Очень странный вопрос мне на днях озвучили. Оказывается есть следующая проблема: компании покупают сложные решения безопасности (такие как SIEM, DLP, IDM и т.п.) и затем эти решения "не приживаются", вплоть до полного неиспользования... что с этим делать?

На мой взгляд здесь нарушена причинно-следственная связь. Используемые технические решения - это всего лишь инструменты и они не должны быть первичны. Правильная последовательность событий такая, что сначала у меня есть цели и задачи, есть боль которую я хочу утолить. Затем, чтобы бороться с этой болью эффективно, я должен ее понять как можно глубже. Понимание даст мне пути решения этой проблемы, они же - пути достижения целей и решения задач. Эти пути выражаются рядом мероприятий часть из которых может быть реализована организационными мерами, а часть - техническими. 

Ну, действительно, сначала у меня должна появиться бизнес-задача - вырыть траншею, а уже затем я должен придумать инструменты решения этой задачи: мотивированные землекопы, модель их совместной работы, лопата штыковая, лопата совковая, лом, бур для сверления отверстий в земле, насос Малыш  и т.п. Если я исхожу из инструмента, скажем у меня есть только совковая лопата, и я думаю, что мне надо бы вырыть траншею, то моя задача может быть и не решена вовсе, так как особенности грунта (анализ ситуации показал) таковы, что мне нужна не совковая лопата, а штыковая, а, кроме этого, еще нужен лом (допустим, зима) или насос Малыш (допустим, близко грунтовые воды и после полуметра глубины мне ее надо постоянно откачивать). Мы, как правило, осознаем эту простую причинно-следственную связь в бытовых ситуациях: сначала люди понимают, что им надо повесить полку на стену, затем идут покупают перфоратор со ударные сверлами нужного диаметра, - но почему-то делаем наоборот в задачах ИТ и ИБ, приобретая решения не понимая цели, про запас.

Несмотря на то, что все мое прошлое в подавляющем своем большинстве - техническая практика, опыт показывает, что при построении стройной системы эффективных (т.е. они дешевы и приводят к желаемому результату) контролей для достижения какой-либо бизнес-цели, доля технических контролей - невелика, а организационные меры, зачастую, более эффективны. Возможно, это связано с тем, что так или иначе корень многих проблем - человек/пользователь, а с людьми неэффективно работать техническими мерами. Отмеченные выше решения безопасности попадают в категорию как раз технических контролей. Помимо того, что они покрывают только часть проблемы, эффективность они могут показывать только тогда, когда появились как инструмент достижения какой-то бизенс-цели, а не просто так, потому что продажник-маркетолог убедил вас в необходимости наличия такого решения. 

Причина низкой эффективности решений, появившихся не в результате анализа бизнес-задач (как инструмент решения этих задач), еще и в том, что эти коробочные продукты исходят из какой-то "стандартной"/типовой среды применения, которая может сильно отличаться от вашей. Это связано с тем, что у каждого своя корпоративная культура, профессионализм, понятие об этике, да и вообще, люди везде разные. Поясню. Одну и ту же задачу я могу решить миллионом способов, каждый из которых будет иметь свои преимущества и недостатки, но в зависимости от способа мне будут нужны/не нужны разные инструменты. Допустим, проблему контроля утечки я могу решить с помощью технического решения DLP (оставим за рамками рассмотрения ее техническую эффективность в борьбе с мотивированным злоумышленником) и работой моего мониторинга, который глазами/скриптами будет находить в логах инсайдеров, что-то сливающих. В этом случае мне нужно техническое решение. С другой стороны, я ту же проблему могу решить продвинутым повышением осведомленности и развить в трудовом коллективе не только высочайшую лояльность к компании, но и мотивировать их быть бдительными и сообщать мне о всех подозрительных фактах, сливать всех инсайдеров, что-то типа ДНД. В этому случае я работаю уже агентурными методами, и DLP - не краеугольный камень моего контроля утечек, может, вообще не нужна. Конечно, наибольшую эффективность покажет комбинация различных методов, а поэтому, исходя из анализа бизнес-цели и бизнес-задач, я могу получить разные требования к техническому решению и технические решения мне могут потребоваться разные, не те, что предлагаются на рынке.

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

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

Не торопитесь покупать и ставить все подряд, сначала поймите свои цели.

Американское руководство по саботажу

Любая палка имеет, как минимум, два конца

Владимир Солдатов

Обычно истина - совокупность противоположных предположений (= Правда где-то посередине)

Из личного опыта

Если вы сложно решаете простое, то сложное вы не решите вовсе

Из личного опыта

Я много троллил глупости и абсурдности, но все еще сомневался в системности бессмыслия, в том, что, в конечном счете, идиотизм имеет цель, хотя и депутат Федоров открытым текстом говорил о бюрократии как об инструменте снижения эффективности, следовательно, - развале, и вот моим сомнениям положил конец документ (дам несколько ссылок: раз, два, три ) - далее по тексту буду называть его "методичка"....

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

Теперь я понял, что вся работа по сбору и анализу "техник" была напрасна - в методичке все они изложены в лучшем виде, систематизированы, даны рекомендации по их применению. То, с чем я наиболее часто сталкивался, и что попало в качестве "техник" в мои записки, изложено в разделе (11) General Interference with Organizations and Productions, поэтому, казалось бы, достаточно ознакомиться до способности уметь узнавать "техники" - это и позволит определять "засланца" на основании методички.

Но не все так просто. Методичка разработана в 1944 году и с тех пор выросло, возможно, не одно поколение, не считающее излишнюю зарегулированность, бюрократию, перфекционизм,  казуистику и т.п. - злом. Во-первых, если молодой человек сразу после института попадает в среду, где работа людей заключается только в обеспечении чрезвычайно сложных процедур (понятно, чем сложнее процедуры, тем больше нужно людей для их обеспечения и тем более профессиональны в этих процедурах они должны быть), то через несколько лет взбивания воды в ступе он начинает считать это нормальным. Придя на работу в другое место, тем более руководителем, он построит такие же колеса, в которых недавно сам был белкой. Вряд ли ему придет на ум мысль о том, что все, что он делал на протяжении всей своей карьеры - неправильно.
Во-вторых, все эти техники размазывания ответственности, отправки на бесконечную доработку и усложнения простых задач могут иметь и конкретную персональную выгоду - это позволяет не брать на себя ответственность, по крайней мере, бесконечно откладывать.
В-третьих, даже если вы не с институтской скамьи попали в шестерни бюрократии, но не являетесь профессионалом в предметной области, самая разумная стратегия - сохранить стратегию предшественника. Непрофессионализм, к моему глубочайшему сожалению сплошь и рядом (причины несложно найти в речи того же Федорова, найти в Сети, а у кого дети учатся в школе/институте или он преподавал сам - знают это из личного опыта), поэтому заложенные когда-то злодеями, на основании методички, принципы повсеместной неэффективности живы и по сей день, причем не только на практике, но и в головах функционеров.

В заключении хочу специально остановиться на том, что я ни в коем случае никого не осуждаю, хотя, наверно, может показаться иначе. Разве можно осуждать человека в незнании чего-то, тогда как от него требуется работать именно там, где он непрофессионален? А желание не брать на себя ответственность - следствие непрофессионализма, к тому же, еще до него была создана вся эта система и существует целый пласт людей у которых работа - обеспечивать работу этой системы - слишком самоуверенно и нескромно думать, что все они занимаются ерундой и, тем более, - вредят. Да и вообще, нужно быть достаточно неординарным человеком, чтобы найти в себе силы и уметь критиковать себя, оспаривать все прошлые истины, сомневаться в правильности прошлых поступков, признавать свои ошибки, ... Однако, только эти самоанализ и самокритика позволяют нам развиваться и идти вперед, поэтому давайте бороться с необоснованными трудностями, распутывать излишне запутанное, упрощать специально усложненное и передавать наш опыт поколениям грядущим! Пора восставать из пепла!

Исследование vs. Пентест

"И все-таки ресеч от пентеста отличается", - подумал я в момент дописывания фаззера при подготовке к конференции,  хотя прежде писал и говорил по-другому. Вот если бы я пентестил, то меня устроил бы первый найденный юникодный символ по-разному понимаемый Hibernate-ом и MSSQL-ем, но у меня ресеч, - поэтому я не вставил в код фаззера Perl-овый last и нашел не один, а все юникодные символы, обладающие нужным мне свойством.

Применив к этой частности индукцию несложно понять разницу в общем смысле.

Функциональная оценка высокотехнологичных продуктов

In theory, theory and practice are the same. In practice, they are not.

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

Наверно самым ужасным последствием функционального тендера является получение предложений, которые объективно невозможно сравнить. Объяснение очевидно: у меня есть практика использования ряда продуктов (если я радел за стандартизацию, то, очевидно, - одного-двух), о них я имею мнение, подтвержденное практическим опытом. Однако, в результате функционального тендера я получаю предложения из всех продуктов, представленных на рынке. Почувствуйте разницу между перечнем продуктов, которые я отшортлистил у себя для использования в компании, очевидно, из соображений стандартизации, и перечнем вообще всех продуктов, представленных на рынке в данном классе. Оставим за кадром устойчивое желание производителя убеждать меня в том, что его продукция соответствует запрашиваемому мною классу продуктов, допустим я покупаю не что-то волшебное, типа DLP или SIEM, где функционал может варьироваться настолько, что вместо первого мне могут продать антиспам или Remote Desktop, а вместо второго - сервер syslog, а выбираю что-то более понятное - СХД, или систему резервного копирования, или, просто, сервер, монтируемый в стойку. И даже в этом случае, выбор на основании заверений производителей, подкрепленный только маркетинговыми буклетами, - чреват супер-негативными последствиями для моего ИТ-комплекса. Ни для кого не секрет, что в приличном ряде случаев, заявленные в спецификациях показатели либо вовсе не выполняются никогда, либо достигаются только в тепличных лабораторных условиях, далеких от боевых, поэтому полагаться на них слепо, с моей точки зрения, - преступная халатность!

Но закончим бла-бла-бла! Риски, порожденные желанием развивать ИТ на базе функциональных тендеров надо компенсировать, придумывать контрмеры. И вот что сразу приходит на ум.
1. Без сомнения нельзя включать в боевые системы решения, не прошедшие тестирование в компании. А раз так, имеет смысл говорить о внутренней сертификации (== тестирование в максимально приближенных к боевым условиях).
2. Порядок проведения внутренней функциональной сертификации - предмет отдельного поста, может, и не одного, но, как минимум должны проверяться:
- все предъявляемые функциональные требования (собственно, все требования, заявленные в функциональной спецификации),
- требования по надежности и доступности,
- требования по интеграции и совместимости,
- работа вендорских линий поддержки,
- стоимость владения: периодическое обслуживание, ЗИП и т.п.
В общем, все это тянет на эксплуатацию в течение не менее 3-х месяцев, причем, очевидно, чем дольше, тем лучше.
3. Результаты тестирования - использовать как при подготовке условий функционального выбора - среди каких вендоров (очевидно, если фирма "Наши маршрутизаторы" делает ненадежное сетевое оборудование, его не надо рассматривать в функциональном тендере на выбор маршрутизаторов), так и при оценке соответствия функциональным требованиям (т.е. полагаться не голословные заверения вендора, а на результаты собственной сертификации).

Понятно, что все эти упражнения с сертификацией потребуют дополнительных немалых инвестиций: в оборудование, которое нивелирует риски нестабильной работы испытываемого железа и софта (или вовсе придется поднимать специализированную тестовую лабораторию), в персонал, который будет осуществлять интеграцию тестируемого оборудования в среду, затем - санитизацию, скорее всего, потребуются какие-либо дополнительные тестовые испытания, имитирующие пиковые нагрузки или нестандартное поведение окружения и пользователей.... в общем, стандартно, новый процесс - новые инвестиции, Закон сохранения работает всегда!

Если взять во внимание все о чем я сейчас и ранее написал, то первоначальная идея получения экономии, породившая функциональные тендеры, по крайней мере в области ИТ и\или ИБ, мне кажется ошибочной. А вам?

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

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

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

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

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

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

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 - все равно что ломать их в СУБД.