Уязвимость веб-сайта T-Mobile позволяла получить полные данные клиентов

Уязвимость веб-сайта T-Mobile позволяла получить полные данные клиентов

Уязвимость веб-сайта T-Mobile позволяла получить полные данные клиентов

Ошибка, найденная исследователем Райаном Стивенсоном на сайте крупнейшего мобильного оператора T-Mobile, находится в поддомене, который используется персоналом в качестве портала обслуживания клиентов, для доступа к внутренним инструментам компании. Домен promotool.t-mobile.com содержит скрытый API, который возвращает данные о клиенте, просто используя в качестве параметра номер его сотового телефона.

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

Кроме того, данные включали ссылки на PIN-коды для учетной записи, используемые клиентами в качестве вопроса безопасности, когда они контактируют со службой поддержки. Это означает, что злоумышленник может использовать эту информацию для получения контроля над аккаунтами клиентов.

Как сообщает ZDNet, несмотря на то, что API используется персоналом T-Mobile для поиска сведений о счете, он не защищен паролем и может быть использован любым желающим. 

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

Стивенсон сообщил о недостатке в T-Mobile в начале апреля, компания быстро отключила API и наградила исследователя суммой в 1000 долларов в рамках своей бонусной программы.

Хотя T-Mobile заявила, что в то время она не обнаружила «никаких доказательств», что данные о клиентах были украдены, позже выяснилось, что хакеры уже нашли открытый API и использовали эту ошибку в течение нескольких недель. Хакеры доказали это, предоставив репортеру ZDNet свои собственные данные.

Увы, это не первый случай обнаружения проблем в T-Mobile. В октябре компания сообщила о другом API, доступном из другого поддомена.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Опубликованные ключи ASP.NET используются для развертывания вредоносов

В конце прошлого года специалисты Microsoft зафиксировали серию атак инъекцией кода, проведенных с использованием статических ключей ASP. NET. В одном из случаев злоумышленникам удалось внедрить в IIS-сервер инструмент постэксплуатации Godzilla.

Примечательно, что validationKey и decryptionKey, предназначенные для защиты данных ViewState от подмены и утечки, не были украдены или куплены в даркнете. Их можно найти онлайн, исследователи обнаружили более 3 тыс. таких сливов.

Обычно ключи ASP. NET генерируются по месту и сохраняются в реестре либо задаются вручную в конфигурационных файлах. К сожалению, некоторые разработчики веб-приложений используют готовые, отыскав их в паблике (документация на код, репозитории), притом без изменений.

Злоумышленникам такие находки тоже облегчают жизнь. При наличии верительных грамот для ViewState отправленный на сайт вредоносный POST-запрос будет с успехом обработан, пейлоад загрузится в память рабочего процесса и запустится на исполнение.

Подобная тактика позволяет автору атаки удаленно выполнить вредоносный код на сервере IIS и развернуть дополнительную полезную нагрузку — к примеру, фреймворк Godzilla с плагинами.

 

«Человеческий фактор нередко приводит к печальным результатам, разработчикам следует понимать, что статические ключи должны быть уникальными и защищёнными, — комментирует эксперт компании «Газинформсервис» Михаил Спицын. — Размещение таких данных в открытых репозиториях или документах эквивалентно предоставлению злоумышленникам несанкционированного доступа к системе».

Похожие атаки были проведены лет пять назад на серверы Microsoft Exchange. Злоумышленники пытались использовать ошибку разработчика, которую тот устранил двумя неделями ранее: все экземпляры Exchange Server использовали одни и те же значения validationKey и decryptionKey, прописанные в web.config.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

RSS: Новости на портале Anti-Malware.ru