Рубрика: Безопасность

Что можно найти, если сделать реверс-инжиниринг 16 тысяч Android-приложений

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

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

Некоторые разработчики даже оставляют секретные коды к аккаунту Amazon Web Services c правами на запуск и остановку экземпляров виртуальных машин. Тут стоит упомянуть о существовании помощников, которые могут защитить от нечаянного коммита секретов в публичный репозиторий. Например, https://github.com/awslabs/git-secrets.

Простая обфускация через ProGuard лишь замедляет декомпиляцию и не остановит упорного злоумышленника от извлечения секретов. Рекомендуется по возможности не использовать коды доступа внутри приложения или использовать разные коды с разными уровнями доступа. Здесь можно почитать про способы защиты чувствительных данных в Android-приложениях.

via Hackernoon

 

Почему протокол NTLM устарел

Аутентификационный протокол NTLM является устаревшим, так как обладает недостатками, которые могут скомпрометировать безопасность приложений и операционной системы. Отсутствие серверной аутентификации — одна из главных проблем, позволяет хакеру обмануть пользователей и заставить их подключиться к взломанному серверу.

Как следствие отсутствия серверной аутентификации, приложения, использующие NTLM могут быть уязвимы к атакам типа «отражение« Идея такой атаки состоит в том, чтобы запутать целевой компьютер в Challenge-response authentication ) и заставить его  правильно ответить на свой же запрос инициировав новое встречное подключение с теми же параметрами. Правильный ответ можно использовать для дальнейшего нормального процесса аутентификации.

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

Стоит помнить, что Negotiage не серебряная пуля — можно найти случаи, в которых атакующий может соединиться через NTLM, но такие случаи более редко и трудно эксплуатируемы. Как минимум, приложения, правильно переписанные на Negotiate перестают страдать от уязвимости к NTLM атакам типа «отражение».

Еще одним предостережением против использования NTLM является возможность прекращения поддержки NTLM в новых версиях Windows, такие приложения просто не смогут аутентифицироваться.

 

По материалам ServerFault.