2022-10-21 18:53:09
Всем саламчик.
Лан, хорош бакланить, пора отрабатывать свое предназначение
Уязвимости цепочек поставки приложений
Цепочка поставки (supply chain) - термин должен быть знаком многим, особенно людям бизнеса: добыча и поставка сырья, производство компонентов, склады/распред.центры, логистика, в конечном итоге - готовый продукт на полке/витрине. Общий смысл уловили, будем считать.
При разработке и дистрибуции, а также последующем обслуживании мобильных (и не только) приложений - похожая история, в особенности, если мы говорим не о простейших офлайн-калькуляторах, но о сложно-сочиненных сервисах, типа банков/соц.сетей/онлайн-игр: такие приложения тоже используют
цепочки поставок (или
цепочки обслуживания, если будет угодно).
Зачем писать с нуля библиотеки/модули/api/sdk для какого-либо приложения, если уже есть полно готовых, логично? Зачем самому бегать-напаривать свое приложение (да это и нереально в сегодняшних условиях), если можно выставить его на витрину в appstore/googleplay/huaweistore/итд?
В конечном итоге, зачем самому вообще писать какое-то приложение (и/или отдельные его части), если ты компания с
n-миллионной капитализацией? Не проще ли нанять кодеров на аутсорсе?
Вот вам и
цепочка поставки/обслуживания/дистрибуции приложения. И, конечно, в таких цепочках сидит дохуя и больше уязвимостей, разной степени опасности.
AWS
Пожалуй наиболее распространенная дырка в подобных цепочках -
прописанные прям в самом приложении токены доступа к AWS. То есть прямо в коде приложения содержаться данные для подключения и аутентификации к серверам/контейнерам AWS (типа как логин/пароль, только токен, аналог логина/пароля, скажем так).
AWS (amazon web services) на сегодня монополист в сфере облачных сервисов.
По факту это сервер-склад, где хранятся всякие библиотеки, sdk (набор средств разработки, т.е. готовые куски кода, модули), а также, внимание(!), множество персональных данных: от ip и марки/модели устройства, вплоть до платежных реквизитов и полных данных на человека (так называемые фулки, с помощью которых совершаются identity theft, т.е. кража личности), а также данных для входа в платежные инструменты (те же лог/пасс, токены, куки и прочие вкусняшки), и даже биометрия (пальчики, глазки, голоски, и что там еще нынче используется в этом качестве)
То есть, условный банк берет в аренду сервак на AWS, складывает туда всякую чувствительную инфу (о самом себе, о своих механизмах/инфраструктуре, о своих клиентах, итд), после чего напрямую прописывает токен доступа к этому серваку в своем же приложении. Ну так же удобнее, и проще, и быстрее. И дырявее
Обычный пользователь, конечно, этого токена не видит, просто вбивает свой лог/пас, или прикладывает палец/лицо/пипку - а приложение уже само шлет/сверяет инфу на AWS, используя встроенный токен. Так себе конструкция, не правда ли? Но она цветет и пахнет, как бы неприятно вам сейчас от этого ни стало.
Согласно отчету symantec (они же broadcom, а эти вообще любят поискать AWS-дырки, т.к. сами продают множество cloud-сервисов), ребятки проанализировали
1 859 приложений, которые любой из нас может скачать из соответствующего стора.
И вот что обнаружили:
в 77% случаев в приложении были прописаны токены доступа к AWS
в 47% случаев эти токены дают доступ к множеству чужих файлов (часто миллионам файлов ), хранящихся на AWS (хранилище Amazon S3)
в 53% случаев приложения используют ОДИНАКОВЫЕ ТОКЕНЫ, несмотря на то что они
как бы от разных разработчиков (привет индийским аутсорсерам)
Кстати, абсолютное большинство (98%) этих приложений - под iOS. Не хочу кидать очередной камень в яблочный огород (и так хватает ), но они пишут, что это связано в том числе с политикой appstore, куда такое разгильдяйство проще пропихивается.
2.1K views15:53