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

В продолжение темы, был оставлен еще один эксперимент (та же версия Деловой почты).
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).