Вход в личный кабинет Modlishka
В начале 2022 года польский исследователь Пётр Душиньский (Piotr Duszyński) выложил в открытом доступе реверс-прокси Modlishka. По его словам, этот инструмент может обойти двухфакторную аутентификацию, что мы сейчас и проверим.
Если сравнить его с тем же SEToolkit (он встроен практически во все популярные дистрибутивы для пентеста), то разница вот в чем: SET клонирует и размещает на локальном сервере страницу авторизации. Там все основано на работе скриптов, которые перехватывают вводимые учетные данные жертвы.
Modlishka действует иначе. Генерируется свой сертификат, которым шифруется соединение от жертвы до нашего сервера (чтобы не палиться). Затем эта машина выступает в роли обратного прокси.
Другими словами, весь трафик идет на оригинальный сайт с инстанцией на нашем сервере. У хакера остаются учетные данные, и захватывается авторизованная сессия жертвы. Классическая MITM-атака, которую предваряет фишинг (нужно как-то заставить жертву установить поддельный сертификат и направить ее на фейковый сайт).
Обсуждение – обход авторизации
Привет юным хакерам.
Короче дело было так. Я как всегда взламывал себе аккаунты в Майнкрафте (на новом сервере ютубера jake50, если шарите), и получилось так, что я вошёл на аккаунт какого то челика без ввода пароля, может вы шарите за обход авторизации на серверах Майнкрафта, подскажите как такое могло произойти, а то я не допёр.
Сейчас в кратце расскажу как это произошло.
Я заходил на аккаунты, и из-за подозрительной активности мне забанило айпишник на 10 минут, я переключил впн, начал заходить, в чат зарание прописал команду /l, потом свернулся чтобы скопировать пароль, разворачиваюсь, а я уже на войдёном аккаунте в игре, в итоге я вышел, не меняя айпишник опять зашёл, но уже просило ввести пароль. Проверил, пароль который был скопирован не подходил, да и вообще все пароли с базы не подошли. Пробовал повторить несколько раз, но не получилось. Может вы шарите?
Сервер стоит на 1.16.5
Название: Holy World
Обход авторизации
Все это хорошо, только кого волнует эта неотказуемость, если механизмы аутентификации остаются неприступными? Поэтому идем копать дальше. Напомним, что к этому моменту мы умеем просматривать список всех пользователей ДБО, менять им пароли и, кроме того, отправлять серверу приложений запросы таким образом, что криптосервер считает их корректно подписанными, а сервер приложений использует параметры без подписи.
Обход авторизации к админке роутера
Хорошо опишу все, у меня стоит задача получить контроль над роутером, т.е web интерфейс его(роутера) получить, чтобы я мог что-то изменить(ну к примеру перепрошить, пароль поменять и т.п) и так я получил пароль от сети и при подключении к 191.168.1.1 просит логин;пароль, стандартные все попробовал неудача, зайти в зону wi fi я могу(ну где роутер) я могу его даже увидеть, но физически контактировать никак, производитель Tp-Link, модель не знаю надеюсь теперь тебе понятна картина.
[doublepost=1513017854,1513017459][/doublepost]
Мне это ничем не помогло
Обход механизма обеспечения неотказуемости операций
Что ж, сначала мы посвятили немного времени анализу и фингерпринтингу. И вот что мы нашли:
Поднимаем стенд
Давай поднимем сервер с Modlishka внутри локальной машины. Я сделаю это на примере Kali Linux, но принципиальной разницы для других дистрибутивов не будет — разве что слегка изменится путь к исходникам Go.
Вначале ставим Go — на этом языке написан реверс-прокси, и без Go он не скомпилируется.
$ apt-get install golang
Следом указываем путь к директории исходников:
$ export GOPATH='/root/go'
Проверить все можно командой
$ go env
В выводе должен быть указан GOPATH.
Затем клонируем ветку с инструментом.
Предисловие
Как известно, существует три основных класса уязвимостей программного обеспечения: уязвимости проектирования, реализации и эксплуатации. Последние достаточно просты с точки зрения исправления, первые же наиболее сложны. При этом уязвимости проектирования не только труднее фиксить, но и наиболее «хлебно» искать с точки зрения исследователя безопасности или хакера, потому что в этом случае можно получить наиболее долгоживущую уязвимость и наибольшее число уязвимых инсталляций.
Если обратиться к истории, то можно увидеть, что банки одними из первых стали использовать гражданскую криптографию — шифрование, электронную цифровую подпись, криптографические протоколы и специализированную аппаратуру. Разработчики систем дистанционного банковского обслуживания (или просто ДБО), таких как онлайн-банки для физических лиц или банк-клиент для юридических лиц, как правило, неплохо знакомы с криптографией и умеют хорошо решать основные задачи в применении к банковским реалиям: обеспечение безопасной передачи данных, обеспечение неотказуемости банковских операций (то есть цифровой аналог собственноручной подписи) и аутентификацию, соответствие требованиям государственных регулирующих органов (регуляторов, в нашем случае — Банка России), защиту морально устаревших систем, которые нельзя оперативно обновить.
Так что если такие системы аккуратно разработаны программистами, которые хорошо знают основы криптографии и умеют их применять, используют признанные алгоритмы с хорошо изученной криптостойкостью, то их сложно сломать, потому что в этом случае придется искать уязвимости, к примеру, в реализации RSA или научиться эффективно факторизовать числа…
А вот и нет. Все так красиво и безопасно только на словах. Даже в военной сфере, авиации и прочих областях разработки ПО, где надежность жизненно важна и где в процессы разработки интегрированы методы формальной верификации, в программах время от времени находят ошибки.
Финансовые приложения существенно менее критичны в плане надежности (от сбоя ДБО, скорее всего, никто не умрет), и формальная верификация — нечастый гость даже в процессах разработки современных финансовых приложений, не говоря уже о старых системах, разработанных лет двадцать назад или еще раньше.
Каждый банк, который хочет предоставлять доступ к финансовым транзакциям через интернет, вынужден выбирать один из двух вариантов реализации:
В первом случае банк получит в готовом виде всю требуемую регуляторами криптографическую обвязку. Второй вариант оставляет решение вопросов, связанных с криптой, в ведении самого банка. И в этом случае на сцену выходят, все в белом (то есть сертифицированные ФСБ), многочисленные криптографические средства и криптопровайдеры, предоставляющие свои услуги.
О втором варианте как раз и пойдет сегодня речь. Мы рассмотрим современные системы дистанционного банковского обслуживания, работающие поверх обычных интернет-соединений (рис. 1). И предложим подход к поиску уязвимостей проектирования в этих финансовых приложениях, на примере клиент-банка одного из крупных европейских банков.
Забегая немного вперед, скажем: по нашему опыту, самая «вкусная» часть таких приложений — специализированный протокол взаимодействия компонентов между собой. Действительно, криптосервер должен передавать серверу приложений результаты проверки ЭЦП из запроса пользователя.
Сервер приложений при этом должен доверять этим результатам, так как сам не использует криптографические примитивы (в этом была вся идея!). Фактически методика взлома такой схемы состоит из обратной инженерии протокола взаимодействия с тем, чтобы понять, как серверу приложений передается результат валидации запроса пользователя, а потом научиться подделывать и передавать эти идентификационные данные.
Предлагаемый подход
Для начала сделаем пару утверждений общего характера на уровне здравого смысла о процессе разработки приложений в банковской сфере и оставим их без доказательства; они помогут нам в поиске уязвимостей проектирования.
Утверждение А: нельзя так просто взять и создать криптографический протокол уровня приложений с нуля.
Когда разработчик пытается изобрести «на коленке» безопасный специализированный протокол с использованием криптографических примитивов без предварительных шагов типа разработки спецификации, формального доказательства свойств протокола, использования безопасного процесса разработки, у него, скорее всего, ничего не выйдет.
Руководство по лечению сертифицированной криптографии в банковских приложениях
Почти каждый хакер или пентестер время от времени сталкивается с нестандартными криптографическими протоколами, которые можно встретить в банковской сфере, в технологических сетях предприятий и так далее. В этой статье мы расскажем о методике исследования и взлома таких систем на примере одного банковского приложения.
Статья – charles. обход api авторизации в android приложении
Добрый день, уважаемые форумчане. Давно от меня не было статей, из-за того что проходил курс
SQLiM aka SQL Injection Master
от codeby. Хоть наш поток и закончился почти месяц назад, я хотел максимально закрепить пройденный материал и практиковался на разных ресурсах. Курс, кстате, советую всем. Сегодня мы разберем необычную уязвимость в android приложениях для обхода авторизации клиентов. Сегодняшним нашим инструментов будет незаменимый Charles, который лучше всех справляется со своей задачей.
2. Charles
Charles (или Charles Web Debugging Proxy), если верить википедии – это кроссплатформенное приложение прокси-сервера отладки HTTP, написанное на Java. Он позволяет пользователю просматривать HTTP, HTTPS, HTTP / 2 и включенный трафик TCP-порта, доступ к которому, с локального компьютера или через него. Простыми словами, мы можем модифицировать request/response. А с помощью специальных правил, запрос будет модифицироваться автоматически.
3. Почему Charles, а не Burp Suite
После прочтения статьи, некоторые могут задуматься, почему автор решил использовать charles, если есть всеми любимый burp suite. Burp suite – несомненно мощный инструмент, но, для наших целей Charles отлично вставлялась в пазл. Вместо 1000 слов, приложу основные различия Charles vs Burp Suite.
Как мы можем заметить, каждый по своему хорош и выполняет определенную задачу лучше чем свой конкурент.
4. Подготовка рабочего окружения и настройка
Для запуска уязвимого приложения, нам естественно нужен будет Android девайс. Мы бы могли провернуть такую же операцию на реальном телефоне, но, яблочник раз – яблочник навсегда
Возьмем в качестве эмулятор Nox Player, который без грязных рук разрешает назначать прокси, в отличии от BlueStacks.
Итак, запускаем Charles, следом запускаем наш эмулятор и настраиваем для него прокси. В качестве IP адреса указываем локальный IP адрес компьютера, где у нас запущен Charles. В linux и mac os, ip адрес можно узнать командой ifconfig. Для windows существуют схожая команда – ipconfig.
И вбиваем его в качестве прокси сервера для беспроводной точки доступа на android устройстве.
Для просмотра HTTPS траффика в нормальном виде, нам нужно установить сертификат Charles на нашем android устройстве.
После этого процесса идем проверять всё ли сделали правильно. Открываем в браузере телефона любой сайт и наблюдаем изменения в Charles.
Если вы видите примерно такую картину, значит вы всё сделали правильно. Почему у нас в запросе везде ноли и единицы? Потому-что мы не включили для данного хоста пункт SSL Proxying, который служит расшифровкой SSL траффика. Включаем SSL проксирование для всех хостов, чтобы не включать каждый нужный хост индивидуально. Нажимаем Proxy -> SSL Proxying Settings -> Add и заполняем форму как на скриншоте
Открываем на эмулятор сайт еще раз и глянем в Charles
Теперь вместо нулей у нас реальные данные, такие как, размер запроса и ответа, скорость ответа от сервера, dns и много другой инфы.
5. Обход API авторизации
Итак, запускаем наше приложение. Ждем пока всё прогрузится. Для перехвата запроса пытаемся авторизоваться по своему номеру. включаем брекпоинты (правый клик по хосту и включить пункт Breakpoints) для хоста и переходим в режим брекпоинтов (красная галочка на верхней панели) и вводим полученный код.
Видим запрос который проверяет код. Запускаем запрос и смотрим на ответ.
В качестве подтверждения правильности кода, сервер отправил нам JSON ответ. Ладно, сохраним этот json объект, и теперь пытаемся авторизовать с рандомного номера и указываем любой код.
Смотрим ответ от сервера
Сервер сообщает нам что код неверный, по сути так и есть, ведь мы указали рандомный номер и код. А что будет если подставить ответ от успешного входа вместо этого ответа? Меняем JSON ответ
И пускаем ответ к приложению кнопкой Execute. Смотрим что произошло в приложении
Ура! Мы в системе под чужим номером. Хоть это было не совсем сложно, но, мы обошли авторизацию.
6. Заключение
Вся информация была предоставлена исключительно в образовательных целях. Эксплуатация уязвимости была выполнена на реальном примере, в реальном приложении. Т.е. это может встречаться на практике. Зафиксить эту уязвимость очень легко. Достаточно при каждом запросе от клиента, предоставлять ему токен, по которому сервер авторизует юзера, а не JSON объект или иной текст, подтверждающий удачный вход. До скорой встречи!
Заключение
В результате мы достигли возможности отправлять полностью доверенные запросы от имени «зловредного» клиента к серверу банка, как если бы они были сгенерированы легитимным клиентом. Мы полагаем, что подобный подход к анализу систем «сверху вниз» можно использовать практически для любой специализированной криптографической системы, потому что ключевое значение имеет человеческий фактор (в нашем случае это приняло форму неверного представления о современных протоколах уровня приложений, о сложных веб-фреймворках и их внутренней кухне).
В качестве послесловия процитируем слова Ади Шамира из его недавнего выступления на RSA Conference 2022: «Я действительно верю, что значимость криптографии снижается. Даже самые защищенные компьютерные системы в самых физически изолированных местах успешно взламывались в последние пару лет в результате APT (Advanced Persistent Threat, целенаправленная атака на конкретную систему) и других продвинутых атак».