Приложенията за мобилно банкиране излагат на риск 300 000 пръстови отпечатъка • Регистърът

Огромни количества лични данни – включително повече от 300 000 биометрични пръстови отпечатъка, използвани от пет приложения за мобилно банкиране – са били изложени на риск от кражба поради твърдо кодирани идентификационни данни на Amazon Web Services, според изследователи по сигурността.

Екипът Threat Hunter на Symantec заяви, че е открил 1859 публично достъпни приложения, Android и iOS, съдържащи вградени идентификационни данни за AWS. Това означава, че ако някой погледне вътре в приложенията, щеше да намери идентификационните данни в кода и потенциално би могъл да ги използва за достъп до сървъри, хоствани от Amazon, и да открадне потребителски данни. По-голямата част (98%) бяха приложения за iOS.

Общо 77% от тези приложения съдържат валидни токени за достъп до AWS, които позволяват достъп до частни облачни услуги на AWS, отбеляза разузнавателният екип в публикувано днес проучване.

Освен това почти половината (47%) съдържат валидни AWS токени, осигуряващи пълен достъп понякога до милиони частни файлове чрез кофи на Amazon S3. Тези твърдо кодирани токени за достъп до AWS биха били лесни за копаене и експлоатация и биха отразявали сериозен проблем с веригата за доставки, каза Дик О’Брайън, редактор на екипа Threat Hunter на Symantec. Регистърът.

Казват ни, че създателите на тези приложения може да не са вградили самите идентификационни данни или дори да знаят, че са там: токените може да са въведени от лошо проектирана софтуерна зависимост.

„Когато говорите за разработка на мобилни приложения, повечето хора не започват от нулата“, каза О’Брайън.

Вместо това разработчиците разчитат на софтуерни библиотеки, комплекти за разработка на софтуер (SDK) и други компоненти на трети страни, които съставляват „градивните елементи, от които са направени приложенията“, каза той.

„Всеки от тях взема решения за сигурността на продукт, който в крайна сметка предоставяте на клиентите си. Така че решението на, да речем, някой, предоставящ SDK, да постави твърдо кодирани идентификационни данни, може потенциално да повлияе на хиляди различни приложения, в зависимост от това колко широко използвано е.”

Не всички приложения, сканирани от ловци на заплахи, имаха масивна потребителска база. Но по-задълбочено гмуркане в някои от най-интересните се оказа “доста тревожно”, каза О’Брайън. „Това, което видяхме, профилът на кандидатурите и естеството на компаниите, които участваха, със сигурност ще ви накара да се замислите.

Ето някои примери за това, което са открили изследователите.

Разкрита чувствителна информация

В един случай доставчик на B2B услуги предостави мобилен SDK за клиентите си, за да го интегрират в техните приложения. Установено е, че SDK съдържа ключове за облачна инфраструктура на доставчика, потенциално излагайки всички негови данни – включително финансови данни, информация за служителите, файлове за над 15 000 средни и големи предприятия и компании, друга информация – която се съхранява на платформата.

SDK имаше твърдо кодиран AWS токен за достъп до услуга за превод, захранвана от Amazon. Въпреки това, този токен предостави пълен достъп до бекенд системите на доставчика, а не само до инструмента за превод. „Вместо да ограничава използването на твърдо кодирания токен за достъп с облачната услуга за превод, всеки с токена имаше пълен и неограничен достъп до всички AWS облачни услуги на B2B предприятието“, пише Кевин Уоткинс от Symantec.

В друг пример за това какво да не правите при разработката на мобилни приложения: Security Store откри пет приложения за банкиране на iOS, които използват един и същ уязвим SDK за цифрова самоличност на AI.

Използването на софтуер на трети страни за компонента за удостоверяване на приложението е доста често срещано явление.

Както отбеляза Уоткинс: „Сложността на предоставянето на различни форми на удостоверяване, поддържането на сигурна инфраструктура, достъпът и управлението на самоличности може да бъде скъпо и изисква експертни познания, за да го направите правилно.“

Това обаче може да доведе и до изтичане на данни. В този случай SDK включва вградени идентификационни данни, които разкриват биометричните пръстови отпечатъци на потребителите, използвани за удостоверяване, заедно с имена и рождени дати. „Пръстовите отпечатъци на над 300 000 души бяха разкрити“, каза О’Брайън.

Освен личната информация на банковите клиенти, ключът за достъп също разкри инфраструктурата и плановете на сървъра, включително изходния код на API и използваните AI модели.

И накрая, в трети пример за риск от веригата за доставка на мобилни приложения, Symantec откри 16 приложения за онлайн игри, използващи библиотека от уязвим софтуер, който според Уоткинс „излага пълна инфраструктура и облачни услуги във всички облачни услуги на AWS с пълен root акаунт за четене/запис акредитивни писма. .” Не е добър външен вид за силно регулираната индустрия за спортни залагания.

Фирмата за сигурност каза, че е информирала всички тези организации за недостатъците.

Защо приложенията използват твърдо кодирани ключове за достъп

Има няколко причини, поради които тези различни приложения са интегрирани в ключовете за достъп. Някои са законни: приложението трябва да изтегли ресурси или да получи достъп до определени облачни услуги, като услугата за превод на AWS, които изискват удостоверяване. Понякога е за разработчика да използва мъртъв код или софтуер, за да тества приложението и да не го премахва, преди да влезе в производство.

„В по-голямата си част това се дължи на известно невежество за това, което излагате“, каза О’Брайън. „Като използвате идентификационни данни за достъп до ресурс в облака, вие разкривате всичко, което е достъпно с помощта на тези идентификационни данни. Това вероятно е комбинация от малко невежество и може би от малко небрежност от страна на разработчиците.“

Организациите могат да се защитят от тези уязвимости на веригата за доставка на софтуер, като следват най-добрите практики за споделяне и използване на ресурси на доставчици на облачни изчисления, добави той.

„По-конкретно, разработчиците никога не трябва да използват повторно облачни споделяния, предназначени за потребителски данни, с вътрешни фирмени данни, и трябва да гарантират, че всички споделяния са правилно заключени с разрешения, предназначени за съхранени данни“, предупреди О’Брайън. „Краткосрочните ключове, ограничени само до данните и облачните услуги, от които се нуждае приложението, нищо повече, е правилният начин.“ ®

Add Comment