При таком положении вещей единственный способ убедиться в аутентичности скаченного продукта — это цифровая подпись инсталлятора.
Это Ваша точка зрения. Моя точка зрения, что в настоящий момент такого способа в Windows, вообще нет, т.к. контролируется целостность только непосредственно исполняемого файла. Разультат выполнения приложения зависит не только от исполняемого файла, который непосредственно запускается, но и от среды выполнения — динамических библиотек, данных, с которыми приложение оперирует, параметров настройки. Пока не контролируется целостность и валидность хотя бы одной компоненты — есть возможность модифицировать результат работы подписанного приложения. PoC когда запуск подписанного приложения приводит к выполнению троянского кода — выше. И это не особенность конкретного инсталлятора, такое можно сделать с практически любым подписанным EXE-файлом.
Мне кажется, для десктопных систем надо полностью отказаться от установки приложений мимо подписанных пакетов установки и не разрешать запускать приложения или менять их среду выполнения другими способами, что-то похожее есть в мобильных системах Пока этого нет в десктопных системах, но к этому все и идет.
Я не знаю, какое решение теоретически правильное, я показываю что тот механизм проверки целостности, который есть, сейчас на практике не работает и тривиально обходится, PoC выше.
То, что Вы предлагаете при текущей организации загрузки приложения в Windows не сработает. Производитель EXE файла не знает какие именно библиотеки будут подгружены итоге в адресное пространства процесса. Системные библитеки могут подгружать другие библиотеки. Для того, чтобы все это контролировать надо писать свой динамический линковщик взамен системного и перехватывать системные вызовы на загрузку библиотек. Т.е. подменять функционал системы. При этом вирмейкеру достаточно для маскировки любого одного приложения, которое так делать не будет. Вот это как раз перекладывание с больной головы на здоровую — реализовывать системный функционал в каждом исполняемом файле.
Вот PoC с тремя разными setup.exe с разными подписями: cloud.mail.ru/public/8b9e46cd16ff/virus.zip
запускает безопасный «вирус» переименованный в data1.cab.
Сорсы приложены.
Т.е. воспроизведите действие обычного пользователя — загрузите, откройте в проводнике. Он предложит извлечь, после чего запускайте любой из сетапов.
Похожий фокус можно провернуть практически с любым подписаным файлом и это будет до тех пор, пока система не начнет проверять все исполняемые файлы на наличие подписи.
Я чуть выше написал. Если пользователь из недоверенного источника готов скачать исполняемый файл и его запустить, то помочь ему очень сложно. Если это будет не setup.exe, а zip-файл в котором будет дистрибутив чего-то с setup.exe, причем с вполне доверенной подписью — что-то изменится?
Зачем на чужой смотреть, давайте прямо сейчас свой сделаем.
Идем в папку c:\program files\InstallShield Installation Information / c:\program files (x86)\InstallShield Installation Information (она скрытая)
Cмотрим по папочкам.
Ищем setup.exe с электронными подписями. У меня есть на выбор с подписями от:
Могу подарить любой.
Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.
P.S. Я не спорю хорошо это или плохо, более того, негативно отношусь к дистрибуции посредством партнерских программ. И еще более того, 20 лет участвую в опенсорсных проектах. Но это же технический чятег, да, я могу указать кому-то на техническую неточность?
Сертификатиом подписывается только наш бинарник, который занимается загрузкой и установкой. Устанавливаемый бинарник нашим сертификатом не подписывался. Примерно то же самое, что Install Shield или Akamai'евский загрузчик обвинять в том, что он устанавливает вредоносное ПО.
Если вы имеете ввиду разные ресурсы mail.ru, то у нас централизованная система аутентификации, почти для всех ресурсов mail.ru пользователь авторизуется в одном месте и нет необходимости хранить и защищать много паролей в разных местах. Что во многом спасло нас от этой атаки.
А вто то, что пользователь использует один и тот же пароль в разных сервисах — это действительно проблема, о ней мы стараемся говорить при каждом удобном случае. Вот здесь, например: http://habrahabr.ru/company/mailru/blog/169801/ достаточно подробно объясняется почему не надо так делать.
Если вы в онлайновом магазине подписались на изменение цены на интересующий Вас товар или на появление новых товаров в определенной категории и получили соответствующее письмо — это спам или нет?
Спам это всегда субъективное понятие. Статья именно о том, как не слать то, что пользователь считает спамом.
Коллега, скажите, при какой температуре утюга вы согласитесь по секрету рассказать мне свой пароль? И если такая температура существует (а она существует) — то какой смысл вообще что-то защищать?
Странно: двукратное увеличение скорости перебора понятно, оно как раз и ожидается. Но откуда берется повышение скорости перебора более чем в два раза? Вылезли за пределы блока:?
Все возможные преобразования, константы и поля базы перенумеровываются и дальше последовательно генерируется постфиксное выражение увеличивающейся глубины по количеству констант и количеству операций, пока результат вычисления сгенерированного выражения для известного пароля не совпадет с известным хэшем. Т.е. фактически обычный брютфорс, в котором роль алфавита играют преобразования и переменные. Естественно, как и в случае любого брютфорса, чем сложнее алгоритм, тем сложнее его подобрать.
Конечно, очень сложный протокол, состоящий из большой последовательности разных вызовов разных алгоритмов и скрытых констант в таком случае будет фактически выполнять роль локального параметра и перебор всех возможных вариантов становится затруднителен. В простом случае (например Вашего примера) он достаточно легко обнаруживается. Точно так же легко восстановить слишком короткий локальный параметр. Но дополнительно к достаточно длинному локальному параметру такое усложнение алгоритма ничего не дает.
На самом деле все это уже реализовано, именно так выглядит хранение паролей в Windows. И есть именно та самая проблема о которой вам рассказали — угнав базу хэшей, можно войти с любой учетной записью, PoC (модификация к smbclient позволяющая логиниться с используемым в Windows NT-хэшем пароля вместо самого пароля есть в этой статье, там же описаны способы доступа к хэшам, база которых хранится в шифрованном виде. Статья писалась 10 лет назад, некоторые аспекты устарели, но это место до сих пор более-менее актуально, насколько я знаю.
Тем, что если на проекте работала, например, CRAM-MD5 аутентификация (стандартная для браузера) — она работать перестанет, пароли будут улетать, например, при доступе из публичных вайфайных сетей. Такой вектор атаки гораздо более вероятен.
1 — достаточно просто, с учетом того, что взломщик знает пароль от своего эккаунта и время регистрации. Можно составить всех возможных преобразований и функций типа time(), их не так много, и устроить перебор по возможным сочетаниям.
2 — зависит от того, какой доступ у взломщика. Если он разово «слил» код и базу, но не сумел закрепиться в системе — то узнать алгоритм он может, а узнать пароли — нет.
3 — а что это даст? соль хранится вместе паролем. Усложнить время вычисления хэша проще добавив еще несколько прогонов, зачем лишние данные хранить?
4 — удаленный брут не имеет никакого отношения к хэшированию паролей. Хэширование спасает от ситуаций, когда слита база эккаунтов и брут можно выполнять локально. Соответственно никакие ограничения здесь не помогут.
Во-первых, Вы путаете аутентификацию и авторизацию.
Во-вторых, вы путаете хэширование пароля на стороне сервера и challenge-response аутентификацию. При challenge-response аутентификации хэш пароля не передается, передается хэш от пароля известного обоим сторонам и случайного challenge, который передается открыто + некоторой соли.
В-третьих, Вы предполагаете полный доступ злоумышленника к компьютеру пользователя и возможность манипулирования клиентским приложением. При таком условии действительно нет разницы в способе аутентификации, т.к. именно клиентское приложение представляет пользователя. В любой момент времени компьютеры, скажем, 1% пользователей контролируются злоумышленниками. Это нехорошо, но не смертельно для сервиса. Но бывают другие ситуации:
1. злоумышленник получил доступ к базе эккаунтов сервера. Если не предусмотрено защиты, то вместо 1% пользователей страдают 100% пользователей, это может быть смертельно для сервиса. Тут спасает хэширование перолей на стороне сервера, чтобы угнанную базу нельзя было использовать, можно было бы восстановить только небольшой процент слабых паролей.
2. злоумышленник имеет доступ к каналу связи. Например контролирует точку доступа Wi-Fi. В таких случаях спасает шифрование с публичным ключом, если оно возможно или challenge-response аутентификация если возможности шифрования до аутентификации нет, иначе злоумышленник «угонит» пароли всех пользователей, которые через эту точку авторизуются.
Пока вы продолжаете хранить старый хэш для существенной части эккаунтов, фактически вы не повысили защищенность хранимых паролей. Т.е. как минимум, старый хэш надо удалять немедленно после генерации нового, и это все равно не устранит проблему хэша у юзеров, которые редко заходят.
При таком подходе хэширование это тоже security through obscurity. Если скомпрометирована вся сеть, то атакующий может снять пароли в открытом тексте в точке авторизации.
Но я скажу страшную вещь: о плохости security through obscurity говорилось тогда, было идеализированное представление о безопасности. Сейчас понимание безопасности другое. Невозможно сделать что-то безопасное. Возможно сделать что-то безопасное до определенной степени. Например, то, что требет 0-day эксплоита и что невозможно взломать за $1000 — уже неплохая степень защиты. В этом плане все, что усложняет взлом, делает его затратней по времени и ресурсам или закрывает один из возможных векторов можно считать полезным.
Это Ваша точка зрения. Моя точка зрения, что в настоящий момент такого способа в Windows, вообще нет, т.к. контролируется целостность только непосредственно исполняемого файла. Разультат выполнения приложения зависит не только от исполняемого файла, который непосредственно запускается, но и от среды выполнения — динамических библиотек, данных, с которыми приложение оперирует, параметров настройки. Пока не контролируется целостность и валидность хотя бы одной компоненты — есть возможность модифицировать результат работы подписанного приложения. PoC когда запуск подписанного приложения приводит к выполнению троянского кода — выше. И это не особенность конкретного инсталлятора, такое можно сделать с практически любым подписанным EXE-файлом.
Мне кажется, для десктопных систем надо полностью отказаться от установки приложений мимо подписанных пакетов установки и не разрешать запускать приложения или менять их среду выполнения другими способами, что-то похожее есть в мобильных системах Пока этого нет в десктопных системах, но к этому все и идет.
То, что Вы предлагаете при текущей организации загрузки приложения в Windows не сработает. Производитель EXE файла не знает какие именно библиотеки будут подгружены итоге в адресное пространства процесса. Системные библитеки могут подгружать другие библиотеки. Для того, чтобы все это контролировать надо писать свой динамический линковщик взамен системного и перехватывать системные вызовы на загрузку библиотек. Т.е. подменять функционал системы. При этом вирмейкеру достаточно для маскировки любого одного приложения, которое так делать не будет. Вот это как раз перекладывание с больной головы на здоровую — реализовывать системный функционал в каждом исполняемом файле.
Вот PoC с тремя разными setup.exe с разными подписями:
cloud.mail.ru/public/8b9e46cd16ff/virus.zip
запускает безопасный «вирус» переименованный в data1.cab.
Сорсы приложены.
Т.е. воспроизведите действие обычного пользователя — загрузите, откройте в проводнике. Он предложит извлечь, после чего запускайте любой из сетапов.
Похожий фокус можно провернуть практически с любым подписаным файлом и это будет до тех пор, пока система не начнет проверять все исполняемые файлы на наличие подписи.
Идем в папку c:\program files\InstallShield Installation Information / c:\program files (x86)\InstallShield Installation Information (она скрытая)
Cмотрим по папочкам.
Ищем setup.exe с электронными подписями. У меня есть на выбор с подписями от:
InstallShield Software Corporation
Macrovision Corporation
Realtek Semiconductor Corp
CyberLink
Могу подарить любой.
Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.
P.S. Я не спорю хорошо это или плохо, более того, негативно отношусь к дистрибуции посредством партнерских программ. И еще более того, 20 лет участвую в опенсорсных проектах. Но это же технический чятег, да, я могу указать кому-то на техническую неточность?
А вто то, что пользователь использует один и тот же пароль в разных сервисах — это действительно проблема, о ней мы стараемся говорить при каждом удобном случае. Вот здесь, например: http://habrahabr.ru/company/mailru/blog/169801/ достаточно подробно объясняется почему не надо так делать.
Спам это всегда субъективное понятие. Статья именно о том, как не слать то, что пользователь считает спамом.
2 — зависит от того, какой доступ у взломщика. Если он разово «слил» код и базу, но не сумел закрепиться в системе — то узнать алгоритм он может, а узнать пароли — нет.
3 — а что это даст? соль хранится вместе паролем. Усложнить время вычисления хэша проще добавив еще несколько прогонов, зачем лишние данные хранить?
4 — удаленный брут не имеет никакого отношения к хэшированию паролей. Хэширование спасает от ситуаций, когда слита база эккаунтов и брут можно выполнять локально. Соответственно никакие ограничения здесь не помогут.
Во-вторых, вы путаете хэширование пароля на стороне сервера и challenge-response аутентификацию. При challenge-response аутентификации хэш пароля не передается, передается хэш от пароля известного обоим сторонам и случайного challenge, который передается открыто + некоторой соли.
В-третьих, Вы предполагаете полный доступ злоумышленника к компьютеру пользователя и возможность манипулирования клиентским приложением. При таком условии действительно нет разницы в способе аутентификации, т.к. именно клиентское приложение представляет пользователя. В любой момент времени компьютеры, скажем, 1% пользователей контролируются злоумышленниками. Это нехорошо, но не смертельно для сервиса. Но бывают другие ситуации:
1. злоумышленник получил доступ к базе эккаунтов сервера. Если не предусмотрено защиты, то вместо 1% пользователей страдают 100% пользователей, это может быть смертельно для сервиса. Тут спасает хэширование перолей на стороне сервера, чтобы угнанную базу нельзя было использовать, можно было бы восстановить только небольшой процент слабых паролей.
2. злоумышленник имеет доступ к каналу связи. Например контролирует точку доступа Wi-Fi. В таких случаях спасает шифрование с публичным ключом, если оно возможно или challenge-response аутентификация если возможности шифрования до аутентификации нет, иначе злоумышленник «угонит» пароли всех пользователей, которые через эту точку авторизуются.
Но я скажу страшную вещь: о плохости security through obscurity говорилось тогда, было идеализированное представление о безопасности. Сейчас понимание безопасности другое. Невозможно сделать что-то безопасное. Возможно сделать что-то безопасное до определенной степени. Например, то, что требет 0-day эксплоита и что невозможно взломать за $1000 — уже неплохая степень защиты. В этом плане все, что усложняет взлом, делает его затратней по времени и ресурсам или закрывает один из возможных векторов можно считать полезным.