Сертифицированное на несертифицированном, продолжение

В продолжение темы, был оставлен еще один эксперимент (та же версия Деловой почты).
1. Запускаем Деловую почту.
2. Успешно там аутентифицируемся, работаем там.
3. Закрываем деловую почту.
4. Час работаем как обычно.

В результате пп 1-3 процесса WMail.exe в Task Managere нет.

Берем другую утилитку - Windows Memeory Reader и дампим всю память, компьютера.
Опыт показывает, что оба варианта дают результат:
wmr.exe mdump.wmr
или
wmr.exe -p mdump-dd.wmr

Результат традиционно прогоняем через знакомый strings:
strings -n 9 mdump.wmr >mdump.strings
или
strings -n 9 mdump-dd.wmr >mdump-dd.strings

В результирующих файлах *.strings (в обоих) - находим свой пароль!

В целом, очевидно, что С-ная free\delete не очищает память, и претензий не было бы, если бы решение не было сертифицированным! В требованиях явно указано:

"должна осуществляться очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ "

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

В целом, к предыдущим выводам можно добавить:
3. Сама сертификация не подтверждает требования, по которым выполнена сертификация.

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

Сертифицированное на несертифицированном

Есть такая компания - Infotecs, у нее есть продукт - VIPNet [Клиент] [Деловая почта]. Суть продукта в том, что он сертифицированным образом защищает конфиденциальную переписку: сообщения шифруются на ГОСТовой криптографии, да и сам продукт имеет сертификат ФСТЭК.

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

Обычно делают так: где-то хранится хеш пароля. Пользователь, аутентифицируясь вводит пароль в какую-то форму, форма его подхватывает, вычисляет хеш, сравнивает с хранимым: совпал - пускает, не совпал - не пускает. Пароль в открытом виде нигде не хранится - это много где требуется, в частности в NIST SP 800-53 (любая ревизия).

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

Проверяем:
1. Запускаем Деловую почту, успешно туда аутентифицируется. В эксперименте используется вот такая версия:

2. Смотрим PID у приложения WMail.exe.
3. Берем утилитку  pmdump.exe и дампим память процесса в файл:
pmdump.exe 5196 WMail.exe-2.pmdump
где 5196 - PID процесса WMail.exe в моем случае.
4. В дампе с ужасом находим свой пароль в открытом виде:

В целом этого достаточно, чтобы понять, что сделать mimikatz для Деловой почты - дело техники.
Если дамп большой, можно облегчить себе работу используя strings:
strings -n 9 WMail.exe-2.pmdump >WMail.exe-2.strings
Результат strings-а можно еще немного обработать, что сократит количество того, что может быть похоже на пароль (известно, что его длина ровно 9 символов, там нет цифр, пробелов, он состоит из начал русских слов, записанных в английской раскладке, используется только нижний регистр):
type WMail.exe-2.strings | proc.pl 1>stdout.txt 2>stderr.txt

Где proc.pl:

my $c=0;
my %r = ();

while(<STDIN>){
    s/^\s+//;s/\s+$//;
    
    if(/^\S+$/ && /^\D+$/ && (length($_)==9) 
        && /^[f,dult`;pbqrkvyjghcnea\[wxio\]sm'.z]+$/ #Russian word
        && $_ == lc($_) #No register
        ){
        print "$_\n";
        $r{$_}++;
        $c++;
    }
}

print STDERR "found $c lines\n";
foreach ( sort {$r{$b} <=> $r{$a}} keys %r){
    print STDERR "$_\t\t".$r{$_}."\n";
}

Из ситуации два очевидных (но важных!) следствия:
1. Сертифицированное ФСТЭК решение не значит безопасное. В конкретном случае - грубая архитектурная уязвимость. 
2. Если уж по-настоящему играть в сертифицированность, то сертифицированное приложение должно стоять на сертифицированной ОС, которая должна быть установлена на сертифицированном железе. Очевидно, что на практике этого нет, поэтому и получается, что легко доверенное приложение компрометировать через недоверенную ОС (что, собственно, здесь и сделали), а последнее - через недоверенное железо. Причем, железные закладки, последнее время, - модная тема, вот, например, хорошая презентация от Джонатана Броссарда. 

Заплатки безопасности

Почему-то чем "старше" становлюсь, тем меньше верю в эффективность построения стройной системы управления информационной безопасностью (СУИБ) (подчеркнутое непонятное словосочетание следует понимать как то, что я, придя в поле, решил построить стройную, правильную в соответствии со всеми умными книжками СУИБ и, выполнив все как написано, в результате получил то, что действительно работает хорошо). Хотя, наверно, должно быть наоборот, - посещая какой-нибудь очередной курс про ISO, где обремененный знаниями формулировок слово-в-слово дядька увлеченно рассказывал про великий успех делания всего по стандарту, - я непременно должен  все сильнее и глубже поверить в то, что все дороги уже пройдены и все грабли наступлены, и нам осталось только брать этот набор "лучших практик" и реализовывать, а все беды человечества - от неправильной\неполной реализации требований стандартов. Да простят мне ISOведы и CobIT-о-ITIL-внедрятели.

Почему? Потому что я рассматриваю выходные данные своего operations-а как входные данные для своей СУИБ, в том числе. Поясню: я что-то намониторил, нарасследовал, навыявлял - в результате я получил какой-то "Lessons learned" который, в идеальном случае (а я этого и хочу), должен привести к тому, что вероятный ущерб от подобных инцидентов будет радикально ниже, как и ниже будут мои трудозатраты на возню с такими инцидентами. В целом, я могу не просто что-то ковырнуть в логоанализировалке или как-то поднастроить в фаерволе, я могу и радикально поменять подход к обеспечению безопасности: я могу изменить стратегию - уйти от перевнтивных мер в детективные, а нарушителей увольнять, или наоборот - все запретить и парализовать бизнес, могу вообще ничего не делать, а раз в год нанимать аудит и генерить предписания (при этом всем доказать, что качество моей работы характеризуется количеством выявленных недочетов и размером предписаний).... Я тут распинаюсь только чтобы объяснить одно: результат моего operations может полностью менять мою "СУИБ", ну или генерить массу заплаток на мою СУИБ, бесконечно ее изменяя во времени. Фактически моя СУИБ будет представлять собой набор заплаток, каждая из которых появилась как продукт Lessons learned из разбора какого-либо инцидента\проблемы или совокупности.

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

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

Что такое хороший operations? Мониторинг и аудит. Постройте мониторинг всего, что можно. Начните с периметра. Если с периметром закончили - смотрите все внутри. События коррелируйте и анализируйте, - расследуйте и разбирайтесь с любым что раньше не наблюдалось или что кажется странным - не должно быть в вашей сети, в ваших системах вещей, которые вы (ну конечно же вместе с админами) не можете объяснить. 

Аудит. Если вы уже наделали заплаток (называйте это вашей СУИБ!) - проверяйте что ваши заплатки работают как вы предполагали, что все настроено, как вы хотели, а люди делают правильные вещи правильно. 

Есть ли конец этой инциденто-расследовательно-заплаточной эпопее? Нет, так как безопасность - это процесс - мы вечно будем делать свою СУИБ (PDCA, Деминг и все такое), если хотим, чтобы она была эффективной (effective и efficient).

Аудиты соответствия и тесты на проникновение снова

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

1. что мое окружение (мои информационные системы, мои админы, мои пользователи) делает все в соответствии с тем, что я считаю безопасно,
2. то, что я считаю безопасно действительно безопасно с учетом современности.

Первое проверяется аудитом соответствия, второе - пентестом.
Первым прогарантирую, что мои контроли работают эффективно(effectively & efficiently), вторым - что мои контроли адекватны реальности.
Первое надо делать почаще (думаю, где-нибудь раз в квартал), второе - можно пореже (раз в 2-3 года - нормально).

Безопасность "на коленках"

Сегодня выступали на конференции.

 Выкладываю презентацию.

How to catch your “hacker” or makeshift security from Sergey Soldatov

Хочется буквально пару слов сказать о мотивации. Изначально мы чувствовали себя как-то некомфортно среди реальных хакеров, которые разобрали по байтам сложнейшие системы, исследовали сложнейшие сетевые протоколы, обходили навороченные защиты и т.п. Тогда как мы планируем рассказывать о вещах, которые доступны для проверки и настройке любому, кто умеет пользоваться компьютером, а мотив подготовки к выступлению исключительно чтобы бесплатно туда попасть не представлялся этически правильным. 
Но все решил первый день. Во-первых я понял, что далеко не все на конференции крутые хакеры, есть достаточно много студентов, много только начинающих вставать на путь ИБ, а следовательно, наряду с тяжелыми докладами должны быть и легкие, иначе, это будет несправедливо по отношению к ребятам. Далее, все что написано в презентации достаточно просто проделать самому, поэтому это может служить неким практикумом что ли. В-третьих, в презентации приведено решение, которое, несмотря на свою бесплатность и "наколеночность" эффективно работает в боевых условиях не хуже дорогущих SIEM-ов, причем, за всю историю использования SEC-а я не смог придумать корреляционного правила, для описания которого мне не хватило бы его синтаксиса (стоит признаться, что SEC позволяет вставлять в обработчики полноценные куски кода на Perl которому доступны параметры события, что делает возможности по корреляции безграничными). Последнее (если ничего не забыл) - в конце первого дня была дискуссионная панель об исследователях и исследованиях, где обсуждалась идея о том, что ресеч никому не нужен... Нет, это не так, поскольку:
1. только благодаря этим, никому не нужным, ресечерам, даже не важно на какой стороне, мы из года в год повышаем безопасность. Старые уязвимости, как и многие старые болезни человечества, ушли в далекое прошлое и сейчас многие принципы безопасности, которые ранее были открытием, сейчас считаются очевидными вещами.
2. лично для меня лучшая мотивация - это видеть результат моей работы. Только жажда результата заставляла меня в свое время сидеть по ночам и писать какие-то программки. А когда желаемый результат наступает остается приятное ощущение маленького подвига. Это может казаться смешным, но в моем случае это так и, лично я, готов многое отдать за это короткое счастье. Могу предположить, что талантливые ресечеры имеют такой же маленький секрет, поскольку уверен, что шедевры не пишутся за деньги, ну, по крайней мере, лично я на внутренней увлеченности уеду намного дальше, чем за деньги. Самим ресечерам нужен ресеч.
3. Есть разные ресечи и почти все они нужны. Не только академические ресечи (которые не финансируются, как правило) есть, есть и сугубо практические, результат которых сразу начинает использоваться. Например, вам нужно выбрать для себя решение DLP. При этом все вендоры вам скажут, что они лучшие (скажу более, не всегда присейлы знают возможности своих продуктов хорошо - надо смотреть). Опыт показывает, что для успешности выбора надо со всеми с ними поиграться какое-то время, только после этого будет более или менее объективное мнение. Чем не ресеч? В свое время я это делал, с финансированием этой задачи проблем не было.
Ну и самое последнее (о чем мы упомянули в речи), в основном все доклады были посвящены (как это почему-то и принято на хакерской конференции) способам и средствам атак, тема защиты представлена довольно скудно. Вот мы и решили этот пробел заполнить и посвятить презентацию именно обороне, а не нападению, как большинство.

Кто же это был?

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

S/MIME в Microsoft

Продолжая криптографическую тему хочется отметить некорректности вот этой статьи (Outlook S/MIME certificate selection):
http://blogs.technet.com/b/pki/archive/2008/12/17/outlook-s-mime-certificate-selection.aspx

Достаточно много народа на нее ссылались, поэтому тема ее неточностей - актуальна.

"When sending an encrypted eMail, Outlook actually requires two certificates. One certificate is owned by the recipient and one is owned by the sender. The recipient’s certificate is used by the sender for encrypting the eMail which is sent out. The sender’s certificate is used by the sender to encrypt the eMail that is stored in the Sent Items folder in Outlook"

Из абзаца может показаться, то письмо шифруется дважды: на ключе отправителя и кладется в Отправленные, и на ключе получателя - и отправляется.

На самом деле это не так: письмо шифруется один раз на ключах всех получателей и на ключе отправителя. Цитата из RFC3851, раздел 3.3:

"Step 2. The MIME entity and other required data is processed into a CMS object of type EnvelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content-encryption key SHOULD be encrypted for the originator and included in the EnvelopedData (see [CMS] Section 6)."

Из сего факта есть интересно следствие, что, будучи получателем письма, я могу залезть в ящик к отправителю и прочитать отправленное мне письмо своим ключом. Это может повторить любой из получателей, причем, применительно и к отправителю и к любому из получателей.

Далее,
"To find a valid certificate owned by the recipient, Outlook verifies if any certificates are stored in the userSMimeCertificate attribute in Active Directory. If so, Outlook examines the PKCS#7 blobs to find out if Outlook is the one that published them. In that case, there is an extra signed attribute that indicates which is the default certificate. If the certificate marked as default is found in the userSMimeCertificate attribute, it is chosen. If the default certificate is not found, the first valid certificate in the store is selected. In case the userSMimeCertificate attribute stores no certificates, Outlook queries the userCertificate attribute in Active Directory"

Может сложиться впечатление, то Outlook берет сертификат непосредственно из AD, и, увидев сертификат в AD, можно долго удивляться почему же Outlook его никак не находит при попытке написать письмо.

На самом деле все не так. Может пройти аж до 48 часов с момента выпуска пользователю сертификата до момента появления возможности отправки ему шифрованного письма.

Очень понятно и подробно об этом написано в KB#841273 - Administering the offline address book in Outlook. Очень рекомендую это внимательно почитать. В двух словах - сертификат берется не из АД, а из локальной копии автономной адресной книги, которая на сервере Exchange генерится не часто (по умолчанию - раз в день), и также нечасто забирается Outlook-ом для автономной работы (если включено кеширование, которое включено по умолчанию).

Еще важно отметить, что по умолчанию Outlook всегда хочет проверять CRL как для сертификатов получателей, так и для сертификата отправителя. Тут может быть масса проблем, начиная с недоступности указанных в сертификате CDP, заканчивая банальными настройками прокси, когда локальный CRL не скачивается по HTTP через настроенный прокси. Не хочу говорить, что я бы рекомендовал отключение проверки CDP, но думать об этом надо.

Вообще, полезно почитать перечень криптопараметров Outlook и решить что как подкрутить в соответствии с потребностями (Plan for e-mail messaging cryptography in Outlook 2010):
http://technet.microsoft.com/en-us/library/cc179061.aspx