В нашем блоге на Хабре мы не только рассказываем о развитии своего продукта — биллинга для операторов связи «Гидра», но и публикуем материалы о работе с инфраструктурой и использовании технологий.
Немецкий журналист и хакер Ляйф Риге (Leif Ryge) написал для издания Ars Technica интересный материал о том, что современный подход к организации обновлений программного обеспечениях несет в себе серьезные риски информационной безопасности. Мы представляем вашему вниманию главные мысли этой заметки.
Предыстория
Еще в 2014 году редакция Washington Post писала о том, что компаниям вроде Apple и Google стоило бы изобрести нечто вроде секретного ключа, с помощью которого можно было бы получать доступ к их продуктам и который бы они хранили и передавали спецслужбам только в случае получения ими судебного решения».
Авторов материала тогда раскритиковали за сам факт выдвижения такой идеи — интернет-сообщество выступило резко против, мотивируя это тем, что если разрешить пользоваться таким инструментом для взлома только «правильным» людям вроде государственных служащих и спецслужб, то все равно нет никакой гарантии, что он не окажется не в тех руках.
Проблема в том, что такой «золотой ключик», открывающий доступ к любому устройству, и так уже существует, пишет Риге — это системные обновления.
Немного теории
Риге пишет о существовании «слабых звеньев», в которых цепь безопасности программного обеспечения может разорваться, позволив злоумышленнику обмануть компьютер жертвы и заставить его «поверить» в то, что предложенное ему зловредное обновление на самом деле является легитимным. Такая «направленная атака обновлений» позволит получить доступ к системе конкретного человека — это значит, что другие пользователи того же самого софта о ней не узнают, что позволит хакеру долгое время оставаться незамеченным.
Риге выделяет два условия для проведения атаки такого типа: злоумышленник должен иметь возможность отправить обновления на систему жертвы, и каким-то образом убедить систему, что обновления пришли из доверенного источника. Если ему удастся это сделать, то он получит поистине неограниченные возможности по совершению противоправных действий. Если представить, что злоумышленник смог обманом установить специально сгенерированное обновление операционной системы, то он сможет получить доступ к данным любых используемых ею приложений, завладеть всеми ключами доступа и паролями, а также всеми незашифрованными данными.
В случае бэкдора в системе шифрования хакер сможет расшифровывать случайные данные, зашифрованные жертвами, а не запускать зловредный софт. Риге пишет, что по его мнению, многие люди, осудившие идею материала Washington Post, имели в виду бэкдор последнего типа.
С точки зрения же атакующего каждый из двух вариантов имеет свои плюсы, пишет немецкий исследователь. Первый вариант позволяет пассивно собирать данные, в том числе зашифрованные, для их дальнейшей расшифровки. Второй вариант же позволяет провести атаку только при возникновении условий для этого, однако если такие условия появляются, хакер получает куда больший простор для действий, чем в случае доступа к полученным, но зашифрованным данным. В таком случае, он сможет перехватывать данные всех приложений и даже подключенных устройств, вроде микрофонов или камер.
При всем масштабе возможных проблем многие разработчики софта только в последнее время задумались о том, чтобы как-то подтверждать аутентичность своих обновлений. Однако даже в случае большинства проектов, которые этим озаботились, их создатели все равно оставляют возможные слабые звенья в цепи, уверен Риге.
В чем проблема
Исследователь пишет, что проблема существует в случае большинства операционных систем. Любимая ОС Риге — это Debian. С помощью простой команды, пользователь может узнать, сколько существует «слабых звеньев», в которых злоумышленники могут попытаться нарушить цепь безопасности при загрузке обновлений:
sudo apt-key list | grep pub | wc -l
В случае системы Риге это число — девять. Вот как проблему описывает он сам:
Каждый раз, когда я запускаю команду apt-get update, любой, у кого есть доступ к одному из этих девяти ключей, и кто располагается между моим компьютером и серверами, с которых он скачивает обновления, может отправить мне зловредный софт, и я запущу его с правами root-пользователя.
Почему это стало возможным
Риге пишет, что тот факт, что огромное количество умнейших людей, занимающихся проектированием и разработкой софта, до сих пор не обращают внимание на эту проблему, просто удивителен. Исследователь объясняет это смесью «наивности и самоуверенности». Разработчики уверены, что им удастся обезопасить свои ключи в условиях реальной атаки, но они не задумывались о том, что правительства разных стран могут просто заставить их пользоваться собственными ключами для подписи нужных им, но зловредных для пользователей обновлений.
Apple против ФБР: что происходит на самом деле
Текущие события вокруг требований ФБР к Apple по предоставлению возможности расшифровки данных iPhone, говорят о том, что люди вроде Риге, которые беспокоились из-за тех самых «слабых звеньев безопасности» больше не являются маргинальными параноиками, и проблема существует на самом деле.
Во всей это истории самым важным, по мнению исследователя, является тот факт, что ФБР требует от Apple предоставить ведомству подписанное обновление, которое будет отключать функцию iPhone для удаления данных после определенного количества попыток подбора PIN-кода.
В системах вроде Debian подобной функциональности нет — если кто-то сможет получить доступ к зашифрованному жесткому диску, то у него будут все возможности по проведени брутфорс-атаки на пароль. Однако сделать это в целом сложнее, чем в случае с коротким PIN-кодом — на компьютерах с клавиатурой люди выбирают куда более сложные и длинные пароли. Однако если атакующий сможет «убедить» компьютер запустить случайный код без расшифровки диска, то можно будет просто получить доступ к ключу, а сложность его пароля станет просто бесполезной.
Поэтому, когда Apple говорит о том, что ФБР пытается «заставить нас создать бэкдор к нашим продуктам», на самом деле они говорят, что спецслужба пытается заставить компанию использовать бэкдор, который в этих продуктах уже присутствует, считает Риге. Исследователь говорит, что тот факт, что ФБР просит Apple написать еще и какой-то дополнительный код, в данном случае роли не играет — они всегда могут нанять для этого других разработчиков. Единственное, что может сделать Apple и только она — это предоставить ФБР подпись для обновлений.
Стоит ли рассматривать те самые «слабые звенья» в качестве полноценных бэкдоров? Риге пишет, что многие специалисты по безопасности не согласятся с этим, поскольку это не общепринятое определение того, что считать бэкдором — все-таки подобная конфигурация систем не является тайной ни для кого. Но в деле Apple сама же компания и использует слово «бэкдор», описывая «слабое звено» криптозащиты своих систем.
Что это означает
Apple может победить в текущем споре с ФБР, пишет Риге. Однако, они могут и проиграть, а это значит, что в прошлом компания могла уступить в этом вопросе кому-либо еще. Что если какая-то криминальная группировка так же, как сейчас ФБР, захотела получить возможность получать данные с защищенных PIN-кодамаи «айфонов»? И что, если эта организация нашла людей, которые понимают устройство технологий, и те объяснили злоумышленникам, кого нужно «заставить» сделать такую возможность реальностью? Люди внутри компании, у которых есть доступ к этому «золотому ключику» могут оказаться в серьезной опасности, если по-настоящему мотивированные люди захотят тоже завладеть им.
Риге надеется на то, что ситуация со спором Apple и ФБР послужит тревожным звонком для разработчиков популярных систем, использующих распределенную инфраструктуру рассылки обновлений. Исследователь считает, что в итоге уже в ближайшем будущем текущие неэффективности этого механизма должны быть устранены, и чтобы провести атаку, подобную описанной выше, злоумышленникам придется заняться компрометацией нескольких ключей, которые хранятся у разных людей, находящихся в различных юрисдикциях. Существует целый ряд проектов, которые могут помочь добиться решения этой задачи, включая Cothority от Dedic и Notary от Docker.
Избавление от «слабых звеньев», атака на каждое из которых может стать критической, должно стать базовым требованием к любым новым механизмам распространения программного обеспечения.
Комментарии (16)
andvgal
15.03.2016 17:27Я думаю, проблему доверия к электронным подписям все эксперты в сфере IT безопасности понимают достаточно давно. Именно поэтому, такие источники как NPM, Bower. Composer/Packagist, Maven и прочие сомнительны для серьёзных проектов, но используются за неимением лучшего.
Лично у меня давно сформировались две идеи, до которых пока не доходят руки.
- Параноидальный режим для веб-браузеров, в котором пользователю нужно подтверждать, что именно конкретный CA должен использоваться для проверки сертификата конкретного сайта, а не любой из доверенных. Пока данная проблема решается созданием отдельных профилей со своим набором CA. Также возможности ранжирование CA по собственной доверительной шкале без необходимости совсем удалять сомнительные.
- Создание независимых репозиториев для источников с открытым исходным кодом (Debian, NPM, Bower, GitHub и т.д.), в которых организован независимый Code Review, независимый статический анализ и собственная сборка бинарных пакетов с проверкой воспроизводимости относительно оригиналов. Подобную услугу возможно продавать коммерческим и государственным организациям. Многие серьёзные компании, по сути организуют нечто подобное в малых масштабах для внутренних нужд и лишь по надобности (CVE, исправления, требуемые новые фичи) втягивают обновления.
Ну, и разумеется не стоит использовать автоматические обновления для казалось бы безопасности. Вместо этого, админы должны вовремя реагировать на наличие обновлений, просматривать их источники, а заодно и release notes на случай нюансов. Конечно, это мало применимо к системам с закрытым исходным кодом, где приходится всецело доверять сторонней коммерческой структуре.
merlin-vrn
15.03.2016 21:03+11: DANE и проверка TLSA. Это даже ещё лучше, т.к. там будет указан не конкретный CA, а конкретный сертификат. Правда, цепочка доверия тут всё равно есть — DNSSEC, но она во всяком случае гораздо лучше структурирована, чем существующая инфраструктура CA — у неё один корень, а не сотни корневых сертификатов.
Вообще я давно тут на хабре говорю: доверять можно только тем CA, которые ты установил в браузер сам. Никаких предустановленных там в принципе быть не должно. Но это, к сожалению, утопия. Можно пытаться привлекать внимание разработчиков браузеров к этой проблеме, но что-то они не спешат придумывать решение. Вместо этого появляются всякие извращения, вроде letsencrypt, который по сути не решает проблему, а скорее наоборот — усугубляет.
2: Во-первых, у давно уже видно, что теория "тысяч глаз" не работает относительно намеренно внесённых ошибок для нарушения безопасности продукта. Она работает для случая поиска ошибок в функциональности продукта.
Во-вторых, по сути, Debian и прочие дистрибутивы именно таковыми "независимыми репозиториями" и являются. Посудите сами, сейчас у вас имеется вопрос доверия к Debian и их источникам; если вы организуете такой вот сервис, как вы описали, появится абсолютно такой же вопрос доверия к этому вашему новому сервису. Лучше помогите существующему репозиторию стать безопаснее (да, это трудно, но сделать свой безопасный, увы, не проще).andvgal
15.03.2016 21:28+1- Тот, кто в состоянии сделать поддельный сертификат хотя бы одного из стандартных Root CA, с большой вероятности найдёт административный ресурс и для подмены DNS. Например, если я установлю собственный Root CA, я хочу чтобы для определённых узлов всегда использовался только он. Пример, когда организация имеет корневой и несколько промежуточный CA без установки стандартных CA. Даже в специальном безопасной удалённой среде может понадобиться, чтобы отдельные узлы проверялись только более защищённым промежуточным CA.
- Суть в разной степени доверия и требования к доверенным лицам. Для обычных коммерческих проектов, несомненно, Debian один из самых лучших вариантов по безопасности, но вот для использования в условиях секретности явно не подходит. Создание дополнительных промежуточных репозиториев-отстойников скорее имеет цель работы многоступенчатого фильтра, где в главном репозитории идёт основная работа, а в промежуточных лишь проверка свежим особо доверенным глазом, к коим не могут относиться абсолютно не контролируемые иностранные разработчики.
- Тот, кто в состоянии сделать поддельный сертификат хотя бы одного из стандартных Root CA, с большой вероятности найдёт административный ресурс и для подмены DNS. Например, если я установлю собственный Root CA, я хочу чтобы для определённых узлов всегда использовался только он. Пример, когда организация имеет корневой и несколько промежуточный CA без установки стандартных CA. Даже в специальном безопасной удалённой среде может понадобиться, чтобы отдельные узлы проверялись только более защищённым промежуточным CA.
ComodoHacker
16.03.2016 11:01+1Пункт 1 реализуется расширением Certificate Patrol. Но для массового пользователя это не решение. Массовый (не подкованный в криптографии) пользователь вынужден кому-то доверять.
- Параноидальный режим для веб-браузеров, в котором пользователю нужно подтверждать, что именно конкретный CA должен использоваться для проверки сертификата конкретного сайта, а не любой из доверенных. Пока данная проблема решается созданием отдельных профилей со своим набором CA. Также возможности ранжирование CA по собственной доверительной шкале без необходимости совсем удалять сомнительные.
devbutch
16.03.2016 00:49Я читал некоторые новости про конфликт Apple и ФБР — там ведь ситуация что у ФБР на руках залоченный смарт и они просили Apple извлечь с него данные. Смысл в этой ситуации просить подписи для апдейта? Потом по истори объявился Макафи (оказывается кандидат в президенты) — сказал что он за 30 минут уберёт блокировку одной левой (а правой будет писать текст для раскаяния перед братьями хакерами). Хотел использовать соц. Инженерию и дизассемблер с бряком на проверке пина, но выждал свои три дня славы и сказал что бессилен. За-то пиар сделал на чужой компании.
Ну и оф. Данные — Apple отказала в просьбе, выйграла суд и теперь с них взятки гладки.
Резюмирую)
OlegAndr
16.03.2016 02:32-1Вы не поняли сути.
У ФБР залоченный (и выключенный) смарт.
Что хочет ФБР — забрутфорсить пароль.
Если есть установка — стирать после 10 попыток — брутфорс не катит.
Что ФБР просит сделать — Apple, сделай нам такой апдейт ОС, который мы сможем накатить на смарт типа как апдейт в рековери режиме, потом он загрузится, но уже не будет стираться при брутфорсе, а лучше будет иметь ещё и программный интерфейс для брутфорса на уровне опять же рековери режима.
Поэтому принудительно обновив смарт можно будет подобрать пароль…
Это можно сделать, но чтобы апдейт применялся, надо чтобы он был подписан валидной подписью Apple. (видимо проверка подписи идет не только на уровне itunes/ но и на уровне смарта даже в рековери режиме).
Вот и вся история. МакАффи не комментирую. Он там тупо предполагал что пароль хранится плейнтекстом на устройстве, что может и было типично в те годы когда он ещё кодил а не гонял шлюх по джунглям.....
St_androsik
16.03.2016 04:28А ещё стоит добавить, что ФБР просрали шанс получить бекап этого телефона, когда сами ресетнули аккаунт, насколько я помню. Так-то эпл им советовали попробовать телефон принести домой к террористам, поставить на зарядку и подождать. Был шанс, что он сделает бекап в облако и эпл этот бы бекап отдала фбр.
Я правда не очень понимаю момента, был бы это залоченный бекап, или нет, из того, что почитал на эту тему, скорее всего залоченный, те фбровцам всё-равно пришлось бы как-то его расшифровывать.OlegAndr
16.03.2016 16:33Бекап на сервере можно брутфорсить как угодно, он отделен от железа же.
St_androsik
16.03.2016 17:58-1Почитал больше, кстати, вроде как пока бекап на сервере лочится не с помощью ключа на телефоне (к которому эпл доступа не имеет), но с помощью ключа эпл, а потому сама эпл может разлочить бекап айклауда и передать его фбр, что они и сделали в данном случае, только он был довольно старый, а возможность получить новый, как я уже написал, фбр просрали.
Надеюсь, что в новой версии iOS они будут лочить бекапы на серваке с помощью ключа на телефоне, так, чтобы даже они ничего не смогли с таким бекапом сделать.
Брутфорсить то можно, да только на это может уйти непомерно много времени.St_androsik
16.03.2016 23:31+1А теперь бы ещё объяснили, минусаторы, долбанные, что вам не понравилось в моём высказывании?
OlegAndr
16.03.2016 02:37+5По сути топика — да, в этом мире всё-таки многое построено на доверии и параноикам нелегко.
Как наглядно было показано в анекдоте про хакера который замучал столовую историями о том что можно хакнуть солонку и всех отравить…
"Уходя от одних угроз подвергаешься другим угрозам" — хочешь обновляться от уязвимостей\вирусов и прочей киберпреступности — получи уязвимость к атакам более высокого уровня.
Хочешь быть безопасным — в инет не выходи, читай газеты и подшивки в библиотеке.
kafeman
16.03.2016 13:50+1Любимая ОС Риге — это Debian.
Каждый раз, когда я запускаю команду apt-get update, любой, у кого есть доступ к одному из этих девяти ключей, и кто располагается между моим компьютером и серверами, с которых он скачивает обновления, может отправить мне зловредный софт, и я запущу его с правами root-пользователя.
Может быть, apt-get upgrade?
vilgeforce
Мне кажется или кто-то "наконец" узнал о проблеме доверия в системах с электронной подписью?
kozyabka
Еще и бизнес на продажах сертификатов. Решил релизить аппу,- купи серт за 500 баксов…
vilgeforce
А толку-то? Начнет центр сертификации "Вася Пупкин" давать сертификаты всем подряд за бабло, и окажется он в блэклисте после первого же подписывания дряни таким сертификатом :-) Но бабло гребут, да...