Оценка безопасности приложений COVID-19

[Carding 4 Carders]

Многие правительства во всем мире начинают обращаться к технологиям, которые помогут им снова открыть свою экономику, часто за счет использования приложений для мобильных телефонов, которые призваны помочь в традиционном отслеживании контактов. Эти приложения используют связь ближнего действия, такую как Bluetooth, для подключения к другим ближайшим устройствам, на которых запущено то же приложение (или совместимое), с обменом идентификаторами, которые впоследствии могут быть использованы как часть процесса отслеживания контактов, если у кого-то диагностирован COVID- 19.

Конечно, соображения конфиденциальности и безопасности должны быть сбалансированы с необходимостью поддержки здравоохранения и содействия экономике - с проблемами, с которыми сейчас сталкивается почти каждая страна. В связи с этим Европейская комиссия опубликовала призыв к использованию общего подхода и опубликовала руководящие принципы, связанные с реализацией приложений для отслеживания контактов с целью создания общеевропейского подхода к официальному признанию мобильных приложений COVID-19, позволяющего людям свободно перемещаться внутри своего транснационального пространства.

Основные поставщики мобильных операционных систем (ОС) также работают над интеграцией отслеживания контактов в свои системы, уделяя особое внимание попыткам обеспечить более высокий уровень конфиденциальности и безопасности. Вероятно, что после выпуска многие из существующих приложений будут перенесены на эту платформу. Это становится более вероятным из-за того, что разрабатываемые в настоящее время приложения, похоже, имеют операционные проблемы с использованием Bluetooth в фоновом режиме (или когда экран выключен) на некоторых из целевых платформ.

Однако даже при разработке новых фреймворков интерфейса прикладного программирования (API) эти решения по-прежнему будут полагаться на сторонние приложения для использования новых функций ОС, и эти приложения быстро создаются в сложной ситуации из-за карантинных мер. во многих странах, а потребность в них обусловлена экономическим давлением и проблемами со здоровьем. Что это означает для безопасности самих приложений? UL загрузил и протестировал 17 различных мобильных приложений, связанных с COVID-19, со всего мира и изучил их с точки зрения передовых методов обеспечения безопасности.

Скриншоты из вредоносных приложений
Хотя многие из приложений не делают ничего, кроме сигналов отслеживания контактов, некоторые приложения (включая приложения для карантина, телемедицины и анкетирования) по-прежнему запрашивают личную информацию, включая контактную информацию и информацию о состоянии здоровья. Примерно 13 из 17 приложений не реализуют контрмеры против внешних снимков экрана, сделанных другими приложениями, которые могут раскрыть личную и конфиденциальную информацию, введенную пользователем приложения. Учитывая крупномасштабное внедрение, которое подразумевает очень большую базу установки, отсутствие такого контроля конфиденциальности здесь вызывает озабоченность.

Небезопасное хранение
Целых 10 из 17 протестированных приложений используют разрешения READ_EXTERNAL_STORAGE и WRITE_EXTERNAL_STORAGE. Это не рекомендуется для конфиденциальных данных, поскольку другие приложения могут иметь доступ к данным в этих местах. Возможно, не менее важно, учитывая возможность изменений в использовании инфраструктуры Google / Apple в будущем, данные, которые хранятся в этих местах, не могут быть удалены при удалении приложения.

Кроме того, мы обнаружили, что 11 из 17 приложений используют базу данных SQLite, выполняют необработанные SQL-запросы и хранят данные без локального шифрования (полагаясь исключительно на безопасность платформы для защиты файла, что является проблемой из-за использования внешнее хранилище, как указано выше). Больше внимания следует уделять защите конфиденциальных данных, которые они содержат.

Небезопасное общение
Было обнаружено, что более половины приложений (девять из 17) не реализуют (или не реализуют безопасным образом) привязку сертификатов для защиты связи с серверными системами. Это открывает возможность компрометации конфиденциальной передачи данных между пользовательским устройством и серверной частью - либо раскрывая данные, либо даже позволяя манипулировать данными, передаваемыми с помощью атак «посередине».

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

Недостаточная криптография
Работа с данными, находящимися в поле зрения Общего регламента защиты данных (GDPR), означает, что данные, которые могут привести к идентификации (PII) и отслеживанию отдельных лиц, должны быть защищены. Однако с точки зрения криптографии только пять из 17 изученных приложений были сочтены соответствующими передовой практике с точки зрения использования криптографических средств контроля. Часто использовались слабые алгоритмы, подверженные хорошо известным атакам, такие как SHA1 или MD5. Более того, было замечено, что в трех из 17 приложений некоторые жестко запрограммированные ключи были легко найдены из-за отсутствия обфускации, что делало шифрование бесполезным.

заголовки строк	Количество вхождений
ECB используется для шифрования.	2 из 17 (те же два также используют слабые хеш-функции)
SHA-1 или MD5 используются в качестве хэш-функции.	12 из 17

Чрезмерно разрешающие приложения
Просматривая разрешения, запрашиваемые приложениями, мы обнаружили следующее:

Разрешение	Количество приложений	Описание
android.permission.ACCESS_BACKGROUND_LOCATION	3 из 17	Позволяет приложению получать доступ к местоположению в фоновом режиме.
android.permission.ACCESS_COARSE_LOCATION	5 из 17	Получите доступ к источникам приблизительного местоположения, таким как база данных мобильной сети, чтобы определить приблизительное местоположение телефона, если таковое имеется. Вредоносные приложения могут использовать это, чтобы определить ваше приблизительное местоположение.
android.permission.ACCESS_FINE_LOCATION	7 из 17	Доступ к источникам точного определения местоположения, таким как Глобальная система определения местоположения на телефоне, если таковая имеется. Вредоносные приложения могут использовать это для определения вашего местоположения и могут потреблять дополнительный заряд аккумулятора.
android.permission.BLUETOOTH	6 из 17	Позволяет приложению просматривать конфигурацию локального телефона Bluetooth, а также устанавливать и принимать соединения с сопряженными устройствами.
android.permission.BLUETOOTH_ADMIN	6 из 17	Позволяет приложению настраивать локальный телефон Bluetooth, а также обнаруживать удаленные устройства и связываться с ними.
android.permission.INTERNET	14 из 17	Позволяет приложению создавать сокеты сети.
android.permission.READ_APP_BADGE	1 из 17	Неизвестное разрешение из справочника Android.
android.permission.READ_CONTACTS	1 из 17	Позволяет приложению читать все контактные (адресные) данные, хранящиеся на вашем телефоне. Вредоносные приложения могут использовать это для отправки ваших данных другим людям.
android.permission.READ_EXTERNAL_STORAGE	12 из 17	Позволяет приложению читать с SD-карты.
android.permission.READ_PHONE_STATE	5 из 17	Разрешает приложению доступ к функциям телефона на устройстве. Приложение с этим разрешением может определить номер телефона и серийный номер этого телефона, активен ли вызов, номер, к которому подключен вызов, и т. Д.
android.permission.SYSTEM_ALERT_WINDOW	2 из 17	Позволяет приложению отображать окна системных предупреждений. Вредоносные приложения могут занимать весь экран телефона.
android.permission.WAKE_LOCK	12 из 17	Разрешает приложению предотвращать переход телефона в спящий режим.
android.permission.WRITE_EXTERNAL_STORAGE	12 из 17	Позволяет приложению записывать на SD-карту.
android.permission.WRITE_SETTINGS	1 из 17	Позволяет приложению изменять данные настроек системы. Вредоносные приложения могут повредить конфигурацию вашей системы.

В приведенном выше списке есть несколько перекрывающихся разрешений, и было обнаружено, что многие приложения (семь из 17) используют избыточные разрешения, такие как запрос ACCESS_FINE_LOCATION, когда также запрашивается ACCESS_COARSE_LOCATION. Эти приложения также запрашивали разрешения Bluetooth, включая BLUETOOTH_ADMIN для некоторых из них. Разрешение BLUETOOTH позволяет приложению осуществлять связь по Bluetooth, например запрашивать соединение, принимать соединение и передавать данные. Наряду с разрешением ACCESS_FINE_LOCATION сканирование Bluetooth может использоваться для сбора информации о местоположении пользователя. Эта информация может поступать от собственных устройств пользователя, а также от маяков Bluetooth, используемых в таких местах, как магазины и транспортные средства.

Разрешение BLUETOOTH_ADMIN является более агрессивным, поскольку оно позволяет обнаруживать и сопрягать новое устройство Bluetooth поблизости (с согласия пользователя) и не требуется для целей, для которых эти приложения развернуты.

Подделка кода и обратная инженерия
Ни одно из приложений не использовало какие-либо механизмы защиты от взлома, такие как Google SafetyNet. Это позволяет распространять потенциал измененных приложений через другие магазины приложений, но там, где модификации реализованы для сбора дополнительных данных о пользователе или предоставления векторов для вредоносных программ на телефон пользователя.

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

Резюме
В целом, рассмотренные нами приложения не соответствовали стандартам, которые обычно ожидаются от приложения, обрабатывающего конфиденциальные данные о состоянии здоровья, установленных на большинстве мобильных устройств в определенном регионе. Мы твердо верим, что эти приложения могут сыграть важную роль в восстановлении после кризиса COVID-19 в рамках более надежного и обширного процесса отслеживания контактов, но в равной степени считаем, что риски, связанные с этими приложениями, должны быть тщательно снижены за счет полной разработки и обзор процесса. Это особенно верно в свете необходимости преобразовать существующие приложения из их текущей реализации в структуру Google / Apple, когда она будет полностью выпущена. Как обрабатываются исторические данные о приложении? Как обеспечивается безопасность приложения? Как мы можем гарантировать, что эти системы обеспечивают ту ценность, на которую они рассчитывают? Цель, на которой мы все должны сосредоточиться, - это максимально безопасное управление этими приложениями.

 

[Carding 4 Carders]

Важность безопасности программного обеспечения для приложений отслеживания COVID-19​

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

Ожидается, что приложения для отслеживания контактов на смартфонах будут эффективны, поскольку их должно установить как можно больше людей. Фактически, исследование, проведенное учеными из Института больших данных Оксфордского университета, показало, что 60% населения страны должны участвовать в обеспечении эффективности любых таких решений. Конечно, когда приложение проникает в миллионы людей, внимание киберпреступников возрастает, а также усиливается обеспокоенность по поводу конфиденциальности пользователей. Поскольку пациенты опасаются публичного порицания, возможность чрезмерного раскрытия информации может быть контрпродуктивной для принятия приложения.

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

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

Создание SDLC
Надежный процесс SDLC должен учитывать риски, с которыми может столкнуться программное обеспечение на протяжении всей его разработки, выпуска и использования. Это начинается с знания и понимания общих проблем (включая языковые недостатки и подводные камни) и передовых методов проектирования безопасности программного обеспечения, а также обеспечения того, чтобы все проекты программного обеспечения обрабатывались в рамках процесса объективного анализа рисков.

Рассмотрение вопросов безопасности на ранних этапах проектирования вплоть до производства и далее может помочь избежать серьезных последствий, таких как утечка данных и вторжения в производственную среду. Если такие риски вызывают беспокойство - а они часто связаны с отслеживанием приложений, - планы по снижению рисков проще всего реализовать на стадии проектирования. Эти риски включают небезопасное взаимодействие между программными компонентами, рискованное управление ресурсами при кодировании, слабую защиту (из-за множества проблем с реализацией программного обеспечения) и так далее.

Добавить безопасность позже всегда сложнее: секрет заключается в балансе скорости, необходимой для развертывания, с уровнем проектирования, необходимым для обеспечения надежной и адаптируемой системы после развертывания.

Вот некоторые примеры публично раскрытых безопасных SDLC:

• Жизненный цикл разработки безопасности MS (MS SDL ): распространенные в 2008 году практики, которые корпорация Майкрософт использовала внутри компании для создания более безопасных продуктов и услуг.
• NIST 800-64 : Вопросы безопасности SDLC, разработанные Национальным институтом стандартов и технологий, которые должны соблюдаться федеральными агентствами США. Также обратитесь к NIST 800-163 - Проверка безопасности мобильного приложения.
• OWASP Mobile Security Testing Guide : стандарты для мобильных приложений с подробным руководством по тестированию, в котором описаны процессы, методы и инструменты, используемые во время тестирования безопасности мобильных приложений, а также исчерпывающий набор тестовых примеров, позволяющий тестировщикам предоставлять согласованные и полные результаты.
• ИСО / МЭК 20734 : Стандарт SDLC, не зависящий от метода, который не требует одного или нескольких конкретных методов, подходов или этапов разработки, но написан в общем виде, применимым ко всем ним.
• BSIMM и SAMM: хотя сами процессы SDLC не являются процессами, их можно использовать в качестве эталонных моделей для измерения уровня безопасности решения.

Все эти модели имеют общую основу концепций - с разными подходами или определениями - и могут применяться к любому типу решения, с некоторыми различиями, связанными с типом решения, таким как мобильное, облачное, веб, Интернет вещей (IoT) и т. . Кроме того, SAFEcode публикует полезный справочник по SDLC.
Но как все это конкретно относится к приложениям для отслеживания контактов? Читай дальше.

Некоторые соображения по приложениям для отслеживания контактов
Применение безопасного SDLC важно для обеспечения безопасности развернутого кода и его соответствия назначению. В то же время часто бывает сложно понять и хорошо реализовать. Основная проблема для каждой организации - это трения между:

• Скорость развития
• Дизайн-цели проекта
• Изменение ландшафта, в котором развертывается продукт
• Угрозы безопасности, которые постоянно меняются.

В этом разделе мы собираем основные ссылки и действия, которые следует учитывать при разработке решения для отслеживания мобильных контактов.

Требования
На раннем этапе важно - наряду с функциональными требованиями - учитывать требования безопасности.

• См. Местные нормативные акты: см. Руководящие принципы, разработанные органами местного самоуправления, например, Европейским советом по защите данных: руководящие принципы 04/2020 ,об использовании данных о местоположении и инструментов отслеживания контактов в контексте пандемии COVID-19. Важно учитывать местные правила, такие как Общий регламент по защите данных (GDPR) в Европе, в котором доступ к документу оценки воздействия на конфиденциальность данных обеспечит большую прозрачность. Согласно Европейскому совету по защите данных (EDPB), оценка воздействия на защиту данных (DPIA) должна быть проведена до внедрения такого инструмента, поскольку обработка считается вероятным высоким риском (данные о здоровье, ожидаемое широкомасштабное внедрение, систематический мониторинг и использование нового технологического решения). EDPB настоятельно рекомендует публиковать DPIA.
• Примите во внимание передовой опыт и требования к безопасности : примите во внимание рекомендации передового опыта, такие как Руководство GSMA Privacy Design Guidelines для разработки приложений и стандарт проверки OWASP Mobile AppSec .
• Мониторинг усилий по стандартизации: рынок по-прежнему фрагментирован с множеством различных альтернатив, и важно отслеживать уроки, извлеченные из различных структур, над которыми работают научные сообщества и организации, таких как PEPP-PT, DP-3T, TCN, PACT. OPENCOVIDTRACE , а также сотрудничество Google и Apple.
• Обеспечьте обучение: разработчики должны, как минимум, знать 10 лучших мобильных приложений OWASP, а также соответствующие и применимые передовые методы безопасного кодирования.

Дизайн
После того, как требования к решению были формализованы и собраны, сосредоточьтесь на деятельности по архитектурному проектированию. Однако убедитесь, что вы избегаете недостатков в конструкции безопасности и интегрируете действия по моделированию угроз для выявления и устранения рисков безопасности, связанных с приложением. Эти действия служат способом обеспечить достаточную защиту конфиденциальности пользователей, анализирующих поверхность атаки, не влияя при этом на объем решения для отслеживания контактов.

Формализация рисков жизненно важна, чтобы вы могли быть уверены, что каждый риск покрывается стратегией смягчения и что каждая функция приложения согласована с требованиями, определенными на предыдущем шаге, и может быть оправдана ими. Рекомендуются формализованный процесс управления рисками, реестр относительных рисков, основанный на деятельности модели угроз (такой как этот пример из инициативы DP-3T ) и оценки безопасности на более позднем этапе.

Выполнение
Решения по реализации должны определяться четко формализованными проектными предположениями и уменьшать, насколько это возможно, неоднозначности, которые упрощают введение связанных с безопасностью слабых мест или затрудняют их обнаружение.
Общее правило разработки безопасного кода - максимально автоматизировать тестирование и уменьшить количество ложных срабатываний. Для этого важно иметь стандартное руководство (например, для Android и iOS), описывающее, как выглядит безопасный код для вашего решения. Затем это можно интегрировать в инструменты статического тестирования безопасности приложений (SAST), которые автоматически применяют правила каждый раз, когда код проверяется.

В условиях быстрого реагирования, которые мы наблюдаем с приложениями для отслеживания COVID-19, такую автоматизацию, на правильную разработку которой могут уйти годы, не так легко реализовать. Тем не менее, сосредоточение внимания на существующих передовых методах отрасли с быстрыми преимуществами для безопасной разработки, такими как использование только известных хороших криптографических алгоритмов, по-прежнему может принести пользу.

Препродакшн
Статический анализ может только увести вас. Важно, чтобы тесты безопасности были реализованы во всем решении перед выпуском. На этом этапе инструменты динамического тестирования безопасности приложений (DAST) могут использоваться для выявления уязвимостей во время выполнения наряду с действиями ручного тестирования. Формальные требования по-прежнему важны, часто ссылаясь на модели угроз, разработанные в начале процесса. Многие организации находят ценность в использовании внешних агентств для помощи в периодическом тестировании на проникновение на этом этапе, потому что это позволяет по-новому взглянуть на проблему. Это особенно важно для общедоступных развертываний, таких как приложения для отслеживания контактов, в которых исследователям безопасности, вероятно, потребуется время, чтобы разобрать любые приложения.
В UL мы считаем, что такое исследование безопасности - это хорошо, но снижение шума, вызванного легко обнаруживаемыми проблемами, жизненно важно. Помимо очевидных проблем с безопасностью приложений для отслеживания контактов, существуют также серьезные проблемы с функциональностью. Насколько хорошо они на самом деле работают? Есть ли помехи для беспокойства и как далеко в переполненном поезде действует сигнал Bluetooth? Приложение для отслеживания, которое не работает, обеспечивает только повышенную уязвимость телефонов пользователей.

Производство и эксплуатация
Работа не останавливается на развертывании приложения. Важно постоянно отслеживать риски и обновлять тестирование в свете любых недавно обнаруженных уязвимостей в модулях или системах стороннего кода. Приложения должны сопровождаться программой управления уязвимостями, предоставляющей исследователям, обнаружившим потенциальные проблемы, возможность сообщать, сортировать и исправлять их при необходимости.
Предоставление исходного кода, который может быть подвергнут публичному аудиту, может повысить прозрачность работы приложения, потенциально уменьшая препятствия для внедрения. Кроме того, наличие четкой дорожной карты и примечаний к исправлению может обеспечить уверенность в будущем приложения.

Стадия вывода из эксплуатации и окончание срока службы (EOL)
Надежное управление кодом включает рассмотрение того, когда в приложениях больше нет необходимости или они каким-либо образом должны быть выведены из эксплуатации. Для приложений отслеживания контактов это жизненно важно, поскольку они специально разработаны для хранения потенциально конфиденциальной информации. Понимание того, как эти данные должны быть надежно удалены, и каков процесс или ценность этих данных при обновлении систем до новых API (например, тех, которые вскоре будут предложены Google и Apple), необходимо для обеспечения безопасности.