В колонках играет - Vomitory - Redeemed In Flames
Настроение сейчас - nice ;)

Давно уже задумывался как же разрешить дилемму устойчивости пароля и емкости серого вещества для его запоминания. Ведь держать в голове даже один (например такой: kW72{w2@/b5$v) пароль - это очень сложно. Известно давно, что при наличии хорошей базы словарей пароли ломаются достаточно быстро. И самое обидное состоит как раз в том, что наш с вами мозг лучше всего генерирует и запоминает словарные (а стало быть неустойчивые) пароли. Закономерный вопрос что же нам органическим делать?

Введем систему обозначений:

login - слово-логин
passwd - слово-пароль
hash - хэш со слова-пароля
hash_et - эталонный хэш слова-пароля
f - функция снятия хэша со слова-пароля
g - дополнительная хэш-функция

Попробуем разобраться. Любая супер-пупер навороченная система аутентификации сводится к банальному IF... ELSE... А весь хитроумный алгоритм можно свести к следующей последовательности действий:

1. Прием входных данных пользователя login, passwd
2. Вычисление хэш-образа hash = f(passwd), где f(passwd) - функция хэширования
3. Сравнение полученного хэш-образа с эталонным. Т.е. if(hash != hash_et) InvalidPassword(true);

Или же:

+--------------------------+ +-----------------------------------------------------------------+
| Пользовательская | | Система |
| сторона | | аутентификации |
+--------------------------+ +-----------------------------------------------------------------+
| passwd | -----> | hash = f(passwd); |
| | | if(hash != hash_et) IncorrectPasswd(true); |
+--------------------------+ +-----------------------------------------------------------------+

Такая система обладает следующим набором уязвимостей:

1. Входным словом является вполне словарное слово (т.к. человеку тяжело запоминать что-то вроде a5XG8#n90\!@#94SA);
2. При известном алгоритме снятия хэш-функции f(passwd) может вскрыться уязвимость алгоритма, что сильно упрощает процесс взлома.
3. Пользователь не может повлиять на выбор функции снятия хэш-образа f(passwd) при обнаружении алгоритма f(passwd).

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

Условия выбора функции первичного хэширования:
1. Необратимость. Для невозможности восстановления слова-пароля по хэшу.
2. Получение хэша в виде совокупности всех возможных печатаемых и непечатаемых (в случае автоматизации ввода со стороны пользователя) символов.
3. Нестандартность. Чем дольше алгоритм будет оставаться тайной, тем выше устойчивость.
4. Если нестандартность тяжело дается, то хотя бы нетождественность хэш-функции в системе аутентификации. Т.е. если у вас в системе аутентификации используется DES64, то нужно взять хотя бы MD5.

Т.е. в данном случае наша схема приема данных будет выглядеть следующим образом:
+----------------------------+ +---------------------------------------------------------------+
| Пользовательская | | Система |
| сторона | | аутентификации |
+----------------------------+ +---------------------------------------------------------------+
| hash1 = g(passwd); | ------> | hash2 = f(hash1); |
| | | if(hash2 != hash_et) IncorrectPasswd(true); |
+----------------------------+ +---------------------------------------------------------------+

Такая схема при соблюдении условий выбора функции первичного хэширования обладает рядом преимуществ перед классической:

1. Пользователь также как и раньше пользуется простым для запоминания (словарным) паролем.
2. Возможность смены алгоритма первичного хэширования на стороне пользователя, что обеспечивает вариативность устойчивости
пароля к атакам. Более того, смена алгоритма первичного хэширования позволит использовать один и тот же пароль с разными системами аутентификации. Лично по моим наблюдениям за коллегами большинство использует один и тот же пароль со всеми системами аутентификации.
3. Невозможность атаки по словарю непосредственно системы аутентификации, т.к. неизвестен промежуточный хэш и алгоритм первичного хэширования.
4. Невозможность подбора слова-пароля при наличии одной только функции первичного хэширования, т.к. промежуточный хэш нигде не хранится, а сама функция обладает свойством необратимости.
5. Невозможность использования слова-пароля в системе аутентификации напрямую. Люди разные бывают и некоторым очень тяжело держать язык за зубами.
6. Увеличение времени взлома для одного прохода (возможно, что незначительно).

P.S. Математики опять в цене. 8)

В колонках играет - DJ Zen - I Believe
Настроение сейчас - Задумчивость

Я вернулся. Но не надолго. Хотел было рассказать о ключевых событиях в своей жизни за этот период и даже практически это сделал, но при отправке инет заглючил, а восстанавливать текст мне как-то лень. Поэтому я расскажу о том, на что я набрел во время своих астральных путешествий при очередной попытке достичь DZена. Штука эта называется полиморфизм. Вообще говоря вещь эта на мой взгляд имеет очень малый спектр применения: VX-сцена и защита кода. Вот о втором я и хотел рассказать. Для начала правда необходимо упомянуть, что никто кроме знаменитых Z0mbie и Vecna (и LordASD'а, работы которого к сожалению я не смог разыскать) из не менее знаменитой группы 29А, не смог развить и предложить новый подход этого замечательного механизма. Более того, лично я не претендую на то, что я мега-кул-хацкер. Это далеко не так (к сожалению), поэтому все высказанные здесь мною мысли (свои и чужие) будут на уровне болтологии без конкретного кода.
Если сильно примитизировать, то полиморфизм можно разделить на 6 условных уровней:
Уровень 1. Код, имеющий некоторый набор шифровальщиков с постоянным кодом. Сами представители VX-сцены и их заклятые друзья-враги AV-еры не считают это полноценным полиморфизмом, т.к. при заражении программы таким кодом, встраивается один из шифровальщиков. Часто такой код называют "олигоморфиком" или "полу-полиморфиком"
Уровень 2. Расшифровщик содержит одну или несколько постоянных инструкций. Вся остальная часть кода постоянно изменяется
Уровень 3. Расшифровщик содержит неиспользуемые инструкции, так называемый "мусор" - NOP; MOV AX,AX; XCHG BX,BX и т.д., и т.п. Также это может быть связка нескольких инструкций. Например PUSH DX \ POP DX ;NASM-style code
Уровень 4. Расшифровщик содержит взаимозаменяемые инструкции и их перемешивание. При этом алгоритм расшифровки постоянен
Уровень 5. Этот уровень подразумевает под собой комбинацию техник всех уровней с 1-го по 4-й, плюс алгоритм шифрования непостоянен, возможно повторное шифрование кода и даже частичное шифрование самого кода расшифровщика
Уровень 6. Это знаменитые permutate-вирусы. Отцом-основателем данной техники является Z0mbie.29A. Прочитайте его статьи о пермутационных движках и вы не пожалеете. Даже если ничего не будет понятно, достаточно даже просто восхититься его гению. Этот человек мыслит абсолютно не так как это делает большинство. Его мышление не сковано рамками аналитических абстракций, навязываемых HLL. Хотя возможно это и есть то, что называют низкоуровневым мышлением. Однако про саму технику. Смысл ее заключается в изменении кода через его декомпозицию на конечные автоматы, которые потом пермешиваются произвольным образом в тексте кода, но функциональные связи сохраняются. Чисто теоретически, если код удастся разбить на достаточно большое число маленьких по объему конечных автоматов, то такой код не будет нуждаться в шифровании.

Ну-с а теперь собственно идея, которая меня посетила и долгое время не отпускала мой неокрепший в удивительном мире DZена разум. Идея проста - взлом программ происходит по принципу дизассемблирования кода, изучения принципа его работы аналитически и во время отладки. Безусловно любая защита может быть взломана при должном наличии упорства и времени. Однако наша задача увеличить необходимое для взлома время на как можно более длительный срок. А это значит, что нам в идеале надо как-то предотвратить все три возможных действия. Очевидно, что дизассемблирование полностью предотвратить невозможно, но в наших силах показать только шифровщик, либо его часть. Это значит, что нам необходим алгоритм шифрования кода. В то время как шифрование может остановить полных профанов или новичков, это не остановит рядовых хакеров. А это значит, что применяя отладчик можно заставить дизассемблер распознать битовые поля как код (например та же IDA Pro это легко делает). Для этого необходимо применить антиотладочные средства. Давно известно, что инструкции меняющие EIP очищают кэш, а следовательно программу, состоящую сплошь и рядом из JMP'ов и/или Jcc будет чрезвычайно понять, т.к. отладчик не будет срабатывать. Однако, если хакер отличается упорством, то он пройдет и этот этап. Вот тут-то и наступает фаза изучения кода. На данном этапе единственное, что мы можем сделать это рассчитывать на человеческий фактор и пытаться сломить хакера морально. Безусловно есть такие стойкие оловянные солдатики, которые смогут пройти даже это, но большинство должно отсеяться в виду практической безысходности ситуации (особенно после попытки анализа кода без нормальной отладки). На мой взгляд достичь этого можно, если использовать захламление кода "мусорными" инструкциями. Причем желательно использовать не только мусор в одну мнемонику, но и в 2-3 мнемоники.
А теперь после вышеизложенного опять внимательно присмотримся к уровням полиморфизма. Очевидно, что всем выдвинутым требованиям наиболее подходит пермутационный движок с шифрованием дешифровщика и генератором мусора. Для доставления особого полового удовольствия можно изменять алгоритм шифрования. Причем не после каждого запуска программы, а с некоторой вероятностью.
P.S. Уверен, что моя идея далеко не новая и уже была придумана кем-то из умных людей до меня. Благо таких людей много. Я просто до этого дошел сам и мне захотелось поделиться этой мыслью с остальными.