Wednesday, June 6, 2012

История неба

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

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

Сначала была большая Компания, в ней было свое подразделение ИТ, числящееся в штате Компании (упустим те времена, когда Компания была, а ИТ еще не было). Они работали прекрасно, но ....

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

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

Долго или коротко ли они так работали, когда ИТ не обладало своими средствами производства и происходили интересные диалоги, когда Бизнес говорил ИТ, что мне нужно такое-то бухгалтерское ПО, а ИТ заявляло, что для того, чтобы оно заработало нужно построить кучу инфраструктуры: купить и отремонтировать серверные и кроссовые, купить сетевое оборудование, все его настроить, купить кучу серверов, внедрить какой-то каталог (пусть будет MS Active Directory), ...., потом все это поддерживать.... Бизнесу нужно все эти средства амортизировать, учитывать,... какой-то Change Management, Configuration Management, .... какой кошмар! Зачем мне все это железо? Мне нужна только ERP и то, мне не важно на каком железе оно там живет и как сложно это все поддерживать, нужно только чтобы сотрудники могли там работать.... + выполнялись требования по доступности, конфиденциальности, целостности, аутентичности и т.п. И Бизнес решил вслед за людьми продать и все железо. Какая красота: не нужны эти дорогущие ЦОДы, не нужно все это железо вечно закупать, складировать, учитывать, утилизировать. Просто сказка!

Так появились Облака.


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

Sunday, June 3, 2012

COA и KPA на пальцах

Памятью от PHD осталась книжка Шнаера. Купил я ее давно, прочитал тоже, а вот подписать у автора получилось только сейчас.

Ну, конечно, Брюс не упустил возможность вкрутить что-то "криптографическое".

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

Были испробованы:
- сложения букв с разными константами (циклический сдвиг),
- сложения букв со своим порядковым номером (снова сдвиг, но по-другому),
- сложения букв со словами типа "PHD", "Schneier", "2012" (тоже сдвиг)


.... для чего были сооружены нехитрые программки на C.

Собственно, что я делал - атака COA. Шифртекст - все что у меня есть.

К своему стыду, я так и не догадался почитать текст в различных направлениях!

Как и предполагалось Гугль дал ссылку. Из нее стал известен открытый текст: "Enjoy the book". Теперь я перешел в режим KPA.

Дальнейший "взлом" занял меньше секунды.

Читаем из правого верхнего угла сверху вниз по столбцам :-)

Мораль: прежде чем кидаться в сложности, посмотри внимательно задачу (сначала думаем, потом трясем!)

Saturday, June 2, 2012

Mimikatz/WCE1.3 vs. MS Digest/WDigest

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

Из первоначальной RFC26117 следует, что "by design" использование аутентификации Digest требует "знание" сервером оригинала пароля. Это просто понять, если посмотреть на формулы в Википедии. Ну и Бог бы с ним, все-таки 1999 год, да и цель свою - не передавать пароль в открытом виде по сети, в отличие от Basic (хотя, при использовании SSL/TLS получается даже безопаснее, поскольку для Basic серверу достаточно знание хеша пароля) - протокол реализует.

Как отключить все эти пережитки прошлого (допустим, что я готов к последствиям), я так и не нашел. Однако, в technet-е , указано, что фичу хранения пароля в открытом виде можно отключить. Цитата:
"Digest authentication is successful only if the domain controller has a reversibly encrypted (plaintext) copy of the requesting user's password stored in Active Directory. To allow passwords to be stored in plaintext, you need to activate the Store password using the reversible encryption setting on the Account tab of the user in Active Directory. Alternatively, you can set group policy to enable this capability. After making this setting, you need to set a new password in order to activate this feature because the old password cannot be determined. "

Как этот параметр ставить и где он есть написано здесь.

Я игрался с WCE. На моей, полностью запатченной и забезопашеной Win7 wce1.3beta работала на раз: пароли доменных учеток дампились в открытом виде. Причем ее x64-версия даже не палилась антивирусом.  Единственная проблема - если в пароле есть русские буквы, пароль не показывается, пишется "<contains-non-printable-chars>" => ищу (может не так целенаправленно) исходники, готов поправить.

Важно отметить, что параметр "Store password using the reversible encryption", по-русски это выглядит так (кое-что пришлось замулевать):

 Отключен. Если я правильно понимаю что написано:

то не должен пароль дампиться, а все работает.....

Какие у кого есть предложения? Как можно обезопаситься?