Comments 19
Мне кажется или кто-то "наконец" узнал о проблеме доверия в системах с электронной подписью?
Я думаю, проблему доверия к электронным подписям все эксперты в сфере IT безопасности понимают достаточно давно. Именно поэтому, такие источники как NPM, Bower. Composer/Packagist, Maven и прочие сомнительны для серьёзных проектов, но используются за неимением лучшего.
Лично у меня давно сформировались две идеи, до которых пока не доходят руки.
Ну, и разумеется не стоит использовать автоматические обновления для казалось бы безопасности. Вместо этого, админы должны вовремя реагировать на наличие обновлений, просматривать их источники, а заодно и release notes на случай нюансов. Конечно, это мало применимо к системам с закрытым исходным кодом, где приходится всецело доверять сторонней коммерческой структуре.
Лично у меня давно сформировались две идеи, до которых пока не доходят руки.
- Параноидальный режим для веб-браузеров, в котором пользователю нужно подтверждать, что именно конкретный CA должен использоваться для проверки сертификата конкретного сайта, а не любой из доверенных. Пока данная проблема решается созданием отдельных профилей со своим набором CA. Также возможности ранжирование CA по собственной доверительной шкале без необходимости совсем удалять сомнительные.
- Создание независимых репозиториев для источников с открытым исходным кодом (Debian, NPM, Bower, GitHub и т.д.), в которых организован независимый Code Review, независимый статический анализ и собственная сборка бинарных пакетов с проверкой воспроизводимости относительно оригиналов. Подобную услугу возможно продавать коммерческим и государственным организациям. Многие серьёзные компании, по сути организуют нечто подобное в малых масштабах для внутренних нужд и лишь по надобности (CVE, исправления, требуемые новые фичи) втягивают обновления.
Ну, и разумеется не стоит использовать автоматические обновления для казалось бы безопасности. Вместо этого, админы должны вовремя реагировать на наличие обновлений, просматривать их источники, а заодно и release notes на случай нюансов. Конечно, это мало применимо к системам с закрытым исходным кодом, где приходится всецело доверять сторонней коммерческой структуре.
1: DANE и проверка TLSA. Это даже ещё лучше, т.к. там будет указан не конкретный CA, а конкретный сертификат. Правда, цепочка доверия тут всё равно есть — DNSSEC, но она во всяком случае гораздо лучше структурирована, чем существующая инфраструктура CA — у неё один корень, а не сотни корневых сертификатов.
Вообще я давно тут на хабре говорю: доверять можно только тем CA, которые ты установил в браузер сам. Никаких предустановленных там в принципе быть не должно. Но это, к сожалению, утопия. Можно пытаться привлекать внимание разработчиков браузеров к этой проблеме, но что-то они не спешат придумывать решение. Вместо этого появляются всякие извращения, вроде letsencrypt, который по сути не решает проблему, а скорее наоборот — усугубляет.
2: Во-первых, у давно уже видно, что теория "тысяч глаз" не работает относительно намеренно внесённых ошибок для нарушения безопасности продукта. Она работает для случая поиска ошибок в функциональности продукта.
Во-вторых, по сути, Debian и прочие дистрибутивы именно таковыми "независимыми репозиториями" и являются. Посудите сами, сейчас у вас имеется вопрос доверия к Debian и их источникам; если вы организуете такой вот сервис, как вы описали, появится абсолютно такой же вопрос доверия к этому вашему новому сервису. Лучше помогите существующему репозиторию стать безопаснее (да, это трудно, но сделать свой безопасный, увы, не проще).
Вообще я давно тут на хабре говорю: доверять можно только тем CA, которые ты установил в браузер сам. Никаких предустановленных там в принципе быть не должно. Но это, к сожалению, утопия. Можно пытаться привлекать внимание разработчиков браузеров к этой проблеме, но что-то они не спешат придумывать решение. Вместо этого появляются всякие извращения, вроде letsencrypt, который по сути не решает проблему, а скорее наоборот — усугубляет.
2: Во-первых, у давно уже видно, что теория "тысяч глаз" не работает относительно намеренно внесённых ошибок для нарушения безопасности продукта. Она работает для случая поиска ошибок в функциональности продукта.
Во-вторых, по сути, Debian и прочие дистрибутивы именно таковыми "независимыми репозиториями" и являются. Посудите сами, сейчас у вас имеется вопрос доверия к Debian и их источникам; если вы организуете такой вот сервис, как вы описали, появится абсолютно такой же вопрос доверия к этому вашему новому сервису. Лучше помогите существующему репозиторию стать безопаснее (да, это трудно, но сделать свой безопасный, увы, не проще).
- Тот, кто в состоянии сделать поддельный сертификат хотя бы одного из стандартных Root CA, с большой вероятности найдёт административный ресурс и для подмены DNS. Например, если я установлю собственный Root CA, я хочу чтобы для определённых узлов всегда использовался только он. Пример, когда организация имеет корневой и несколько промежуточный CA без установки стандартных CA. Даже в специальном безопасной удалённой среде может понадобиться, чтобы отдельные узлы проверялись только более защищённым промежуточным CA.
- Суть в разной степени доверия и требования к доверенным лицам. Для обычных коммерческих проектов, несомненно, Debian один из самых лучших вариантов по безопасности, но вот для использования в условиях секретности явно не подходит. Создание дополнительных промежуточных репозиториев-отстойников скорее имеет цель работы многоступенчатого фильтра, где в главном репозитории идёт основная работа, а в промежуточных лишь проверка свежим особо доверенным глазом, к коим не могут относиться абсолютно не контролируемые иностранные разработчики.
Хорошее видео на тему.
Пункт 1 реализуется расширением Certificate Patrol. Но для массового пользователя это не решение. Массовый (не подкованный в криптографии) пользователь вынужден кому-то доверять.
В довесок нашёл такую фичу с намёком на стандартизацию: The Public Key Pinning Extension for HTTP (HPKP)
Я читал некоторые новости про конфликт Apple и ФБР — там ведь ситуация что у ФБР на руках залоченный смарт и они просили Apple извлечь с него данные. Смысл в этой ситуации просить подписи для апдейта? Потом по истори объявился Макафи (оказывается кандидат в президенты) — сказал что он за 30 минут уберёт блокировку одной левой (а правой будет писать текст для раскаяния перед братьями хакерами). Хотел использовать соц. Инженерию и дизассемблер с бряком на проверке пина, но выждал свои три дня славы и сказал что бессилен. За-то пиар сделал на чужой компании.
Ну и оф. Данные — Apple отказала в просьбе, выйграла суд и теперь с них взятки гладки.
Резюмирую)
Ну и оф. Данные — Apple отказала в просьбе, выйграла суд и теперь с них взятки гладки.
Резюмирую)
Вы не поняли сути.
У ФБР залоченный (и выключенный) смарт.
Что хочет ФБР — забрутфорсить пароль.
Если есть установка — стирать после 10 попыток — брутфорс не катит.
Что ФБР просит сделать — Apple, сделай нам такой апдейт ОС, который мы сможем накатить на смарт типа как апдейт в рековери режиме, потом он загрузится, но уже не будет стираться при брутфорсе, а лучше будет иметь ещё и программный интерфейс для брутфорса на уровне опять же рековери режима.
Поэтому принудительно обновив смарт можно будет подобрать пароль…
Это можно сделать, но чтобы апдейт применялся, надо чтобы он был подписан валидной подписью Apple. (видимо проверка подписи идет не только на уровне itunes/ но и на уровне смарта даже в рековери режиме).
Вот и вся история. МакАффи не комментирую. Он там тупо предполагал что пароль хранится плейнтекстом на устройстве, что может и было типично в те годы когда он ещё кодил а не гонял шлюх по джунглям.....
У ФБР залоченный (и выключенный) смарт.
Что хочет ФБР — забрутфорсить пароль.
Если есть установка — стирать после 10 попыток — брутфорс не катит.
Что ФБР просит сделать — Apple, сделай нам такой апдейт ОС, который мы сможем накатить на смарт типа как апдейт в рековери режиме, потом он загрузится, но уже не будет стираться при брутфорсе, а лучше будет иметь ещё и программный интерфейс для брутфорса на уровне опять же рековери режима.
Поэтому принудительно обновив смарт можно будет подобрать пароль…
Это можно сделать, но чтобы апдейт применялся, надо чтобы он был подписан валидной подписью Apple. (видимо проверка подписи идет не только на уровне itunes/ но и на уровне смарта даже в рековери режиме).
Вот и вся история. МакАффи не комментирую. Он там тупо предполагал что пароль хранится плейнтекстом на устройстве, что может и было типично в те годы когда он ещё кодил а не гонял шлюх по джунглям.....
По сути топика — да, в этом мире всё-таки многое построено на доверии и параноикам нелегко.
Как наглядно было показано в анекдоте про хакера который замучал столовую историями о том что можно хакнуть солонку и всех отравить…
"Уходя от одних угроз подвергаешься другим угрозам" — хочешь обновляться от уязвимостей\вирусов и прочей киберпреступности — получи уязвимость к атакам более высокого уровня.
Хочешь быть безопасным — в инет не выходи, читай газеты и подшивки в библиотеке.
Как наглядно было показано в анекдоте про хакера который замучал столовую историями о том что можно хакнуть солонку и всех отравить…
"Уходя от одних угроз подвергаешься другим угрозам" — хочешь обновляться от уязвимостей\вирусов и прочей киберпреступности — получи уязвимость к атакам более высокого уровня.
Хочешь быть безопасным — в инет не выходи, читай газеты и подшивки в библиотеке.
Любимая ОС Риге — это Debian.
Каждый раз, когда я запускаю команду apt-get update, любой, у кого есть доступ к одному из этих девяти ключей, и кто располагается между моим компьютером и серверами, с которых он скачивает обновления, может отправить мне зловредный софт, и я запущу его с правами root-пользователя.Может быть, apt-get upgrade?
Sign up to leave a comment.
Универсальный инструмент для установки бэкдоров: Что не так с системными обновлениями