Как стать автором
Обновить

Приложение Microsoft Teams хранит токены аутентификации в незашифрованном виде, разработчики не считают это критичным

Время на прочтение3 мин
Количество просмотров4.9K
Всего голосов 14: ↑14 и ↓0+14
Комментарии24

Комментарии 24

Это очень сильный удар по репутации Office 365.

Не думаю, что ИБ в корпоративном сегменте согласится с оценкой рисков, которую легкомысленно сейчас предложила Майкрософт.

В каком-то смысле я их понимаю. Сохранение пароля ведёт к доступности сохраненного пароля, который всё равно доступен. Логично же...

Одно дело пароль, другое токен с доверенного устройства. При предъявлении которого 2FA вероятно не потребует дополнительного подтверждения.. Или я ошибаюсь в оценке ситуации?

Ну, рекомендация "юзайте браузер" -- откуда можно ровно так же увести куки. С тем же результатом..

А точно с тем же результатом? Они ж сеансовые, нет?

PS Надеюсь, несмотря на высказанную оценку "не горит, починим как-нибудь" , MS всё же повысит приоритет и пофиксит ситуацию.

Это вопрос -- оно умеет запоминать в браузере или нет. Вроде было так же (как минимум скайп месяцами держал сессию без проблем)

Есть же 2 типа. "Запомнить пароль" и нет, если речь про дженерик сайт. Во втором случае создаётся сессия, которая живет до закрытия браузера.

Дефолтное время жизни сессии МФА у Майков - 3 месяца, у самих тимсов - не уверен.

Ну вообще, если мне не изменяет память (лень в ААД лезть), ничто не мешает настроить время сессии до запроса МФА на те же тимсы через кондтшенал полиси. Требования: P1 лицензия.

Аля: апп = тимс, грант из опред локаций, сессия = месяц. Если из других локаций, то меньше.

Но таким образом пользователь будет очень сильно не рад, если у него будет просить МФА вместо раз в 3 месяца по дефолту, раз в неделю, напртмер.

Вообще, интересно ли, влияет ли уже на готовый токен локация. Опять же, если кондишенал рулами настраивать, чтобы те, кто на удаленке, чаще вводили МФА, проблема минимизируется (при условии, что уведенный токен становится невалидным при использовании его с Бангладеша). Но опять же, тогда мобильные приложения грустят.

Нормальная логика " «Описанная в ходе атаки методика не соответствует нашей планке для немедленного реагирования, поскольку требует, чтобы злоумышленник сначала получил доступ к внутренней части сети клиента или имел локальный доступ на ПК жертвы» " - при тотальной удаленке и тенденции BYOD, а BitLocker вскрывается зубочисткой

BitLocker вскрывается зубочисткой

Пруфы?

Ей пытать можно.

Разумно, но это точно так же вскроет и любое другое ПО. Заодно ещё пользователь признается в чём угодно, вплоть до подготовки теракта. ФСБ не даст соврать.

Но это уже вопрос трезвой оценки модели угроз. Если в ней присутствуют пытки, нужно отказываться от использования пароля и переходить, например, на использование ключевого файла на флешке (которую можно уничтожить, пока пилят дверь). BitLocker это позволяет.

А что делает "Elcomsoft Forensic Disk Decryptor" ?

Forensic Disk Decryptor позволяет мгновенно извлечь метаданные шифрования, необходимые для восстановления оригинального текстового пароля к зашифрованным дискам ... BitLocker, ..., а также контейнерам ..... Метаданные шифрования можно извлечь как с физического носителя, так и из файла-контейнера или образа диска.

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

  • Анализом файла гибернации (исследуемый компьютер выключен);

  • Анализом слепка оперативной памяти компьютера (может быть получен посредством встроенной утилиты)

  • Атакой через порт FireWire (компьютер должен быть включён, а зашифрованные тома – подключены). Для проведения атаки через порт FireWire требуется дополнительный компьютер с установленным бесплатным продуктом (например, Inception).

  • Снятие образа оперативной памяти при помощи встроенного инструмента (есть возможность запуска с USB накопителя)

еще инструментарий

Encrypted drives can be decrypted using BitLock Key

BitLocker encrypted drives can be recovered using this tool, even if the data has been lost or deleted. Simply enter the BitLocker decryption key and then run the BitLocker decryption software. Encrypted drives can be recovered in the same way as ordinary drives.

Анализом файла гибернации (исследуемый компьютер выключен);
Это если файл гибернации располагается на незашифрованном накопителе.

Атакой через порт FireWire
Атака невозможна при грамотной настройке политики «Отключать DMA устройства, подключенные, пока сеанс заблокирован». Если сеанс разблокирован, то см. далее.

Остальные 2 способа применимы к любому средству шифрования и требуют, чтобы у атакующего был доступ к работающей системе с разблокированным накопителем и незаблокированным сеансом. Ну то есть, вы расшифровали всё, сидите, работаете, тут вам заламывают руки и ваше место занимает товарищ майор. В таком сценарии никакое ПО вас уже спасёт.

еще инструментарий
«Simply enter the BitLocker decryption key» — а откуда вы собрались его брать? Да, зашифрованный накопитель может быть расшифрован либо паролем, либо ключом восстановления. Но вы ведь не знаете ни того, ни другого. Ключ восстановления, по сути, это резервный пароль. Кто же вам его даст.

А линуксовый LUKS, позволяет, например, вообще иметь 8 (вроде) разных паролей для одного накопителя. Ну да, узнав любой из них, вы расшифруете накопитель.

Ну то есть, вы расшифровали всё, сидите, работаете, тут вам заламывают руки и ваше место занимает товарищ майор. В таком сценарии никакое ПО вас уже спасёт.

Давайте будем различать рабочую среду построенную специалистами согласно ISO 2700x со всеми пропусками-зонами доступа с периодическими аудитами и BYOD обычного среднего удаленного работничка, который идет за смузи в кофейне не делая lock своего ноутбука. Бухгалтера, в эпоху маски-шоу, шли курить оставляя все варианты бухгалтерии разбросанные на столе и открытые рабочие места. Разве что пачки денег по столу не разбрасывали и могли пересчитывать с открытыми дверьми.
Никогда не пробовали, например, настоятельно рекомендовать использовать "Secure folder" на телефоне Samsung ? Это оказались эпические битвы и все равно люди не понимали "что это и зачем ?" и ввод еще одного пароля вызывал истерики и искренне изумлялись "А почему мои фото в фейсбуке? я же не выклыдывала их туда!!"

Что говорить сейчас о непуганных идиотах которые могут на телефон пароль не ставить (ну неудобно !!!), а вы о " Отключать DMA устройства, ..." и " файл гибернации располагается на незашифрованном накопителе "

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

Тоже жду пруфы и ссылку на зубочистку.

По хорошему, приложения друг от друга должна изолировать система. Костыли на уровне приложений – принципиально так себе по надёжности (ну, зашифруешь ты файл. А ключ где хранить? То-то...)

Согласен, как ни крути, будет какой-то секрет, который всеравно придется хранить локально

Угу. Программа-минимум – keychain в системе, с ограничением доступа по приложениям (в MacOS так) и проверкой подписи обращающегося приложения.

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

А почему это вообще считается проблемой, вернее, каким может быть реалистичное исправление? Судя по виду, эти токены - уже и так зашифрованные строки, и их содержимое прочитать злоумышленник не может. Если их шифровать ещё раз перед записью на диск, то приложение должно уметь и расшифровывать их обратно при чтении с диска, а, значит, алгоритм и ключ шифрования должны были быть зашиты в приложение - а, значит, умельцы легко извлекли бы его обратно.

Другое дело, что можно было бы улучшить сами токены для того, чтобы они были привязаны к конкретному компьютеру на аппаратном уровне. TPM даёт хорошие примитивы для этого - например, можно было бы хранить в TPM приватный ключ, положить внутрь токена соответствующий публичный ключ, и делать сервер-клиентскую challenge-response аутентификацию через этот ключ перед разрешением токена к использованию. Вот это было бы настоящим решением проблемы, правда, с дополнительными сложностями (не сработает на компьютерах без TPM, потребуется усложнение клиент-серверного протокола, и т. п.).

Как извлечь из приложения работу public-private ключей (сертификатов x.509), которые, к слову там просто, поддерживаются в ААД приложениях. Скрипты и кастомные аппсы с аутентификацией по сертификатам, вместо сикретов или логин пароля? Легко

Забавно сколько в комментария людей, не понимающих разницу между reusable session token (который имеет срок действия и уменьшает количество аутентификаций без сохранения пароля, но его утечка всё-же позволяет воспользоваться чужим аккаунтом) и шифрованием пароля, а то и вовсе x.509 аутентификации (которая подменяет парольную авторизацию на протоколы цифровой подписи).

Проблема актуальная. Хотя, тот-же skype 4 business вообще в не зашифрованном виде в lsass пароль хранит, о чём известно десятилетие и MS не шибко спешит исправлять.

Проблема актуальная

так вы знаете какие-то решения её, не использующие внешние хранилища секретов (аппаратные, или на уровне ОС)?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости

Истории