.NET Kings

👁‍🗨Hello world~ Автоматизированный обход DPI на роутере: B4 • Много было написано про DPI, и про сам принцип, и про обход через VLESS/VMess. Но прокси требуют сервер — это деньги и лишний пинг. GoodbyeDPI и Zapret работают без сервера, но требуют вручную ковырять параметры и списки доменов. B4 удобнее: никакого сервера, а настройка через веб-интерфейс с автоподбором стратегий. • B4 (Bye Bye Big Bro) — процессор сетевых пакетов на Go. Перехватывает трафик через netfilter и модифицирует его так, чтобы DPI провайдера не могла распознать, куда вы заходите. • Чем отличается от Zapret и GoodbyeDPI. Все три инструмента делают одно и то же, обманывают DPI без VPN и прокси, но подход разный: • GoodbyeDPI: Только Windows, минимум настроек, нет баз доменов, нет автоподбора. • Zapret: Linux, роутеры, имеет богатый CLI набор (iptables, nftables, скрипты, профили), а так же хорошую гибкость (параметры, списки, правила) • B4: Linux и роутеры (OpenWRT, Keenetic/Entware, Asus Merlin). Веб-интерфейс, встроенные geodata (не нужно вручную вести списки доменов), подключаешь категорию (youtube, netflix, facebook) и готово. Discovery, автоподбор рабочей стратегии под конкретный домен и провайдера. Изменения применяются на лету, без перезапуска. • Как поставить. Нужен Linux и root-доступ. Всё. Установщик сделает остальное. • На обычный Linux (ПК или сервер): подключаетесь по SSH или открываете терминал и выполняете: wget -O ~/b4install.sh https://raw.githubusercontent.com/DanielLavrushin/b4/main/install.sh && chmod +x ~/b4install.sh && ~/b4install.sh • На OpenWRT: подключаетесь по SSH, выполняете ту же команду. Управление: /etc/init.d/b4 restart • После установки открываете http://IP-устройства:7000, скачиваете geosite/geoip в настройках, создаёте набор доменов или подключаете категорию, запускаете Discovery на проблемном домене, B4 сам переберёт стратегии и предложит рабочую. Сохраняете и все применяется мгновенно. • У кого-то заработает сразу, у кого-то нужно будет поиграть с Discovery, для этого он и существует. Удачи! • GitHub: https://github.com/DanielLavrushin/b4 • Поддержать автора монеткой: @v_meshke

👁‍🗨Hello world~ BFLA: Уязвимость, когда функции доступны всем • Broken Function-Level Authorization (BFLA) — это критическая уязвимость безопасности веб-приложений и API, которая возникает, когда приложение неправильно проверяет, имеет ли пользователь право на выполнение конкретного действия, даже если он аутентифицирован. • BOLA и BFLA тесно связаны, так как раньше все это называлось одним Broken Access Control и его так же путают с IDOR, давайте быстро по тому, чем они отличаются. • IDOR: Пользователь получает доступ к данным/ресурсу, которому не должен (например, меняет user_id=101 на user_id=102 в URL, чтобы просмотреть чужой профиль). Проблема в объекте. • BFLA: Пользователь получает доступ к функции/действию/эндпоинту, которое ему не положено (например, вызывает административный API-метод DELETE /api/users/{id} будучи обычным пользователем). Проблема в функции. • Уязвимость возникает, когда приложение правильно аутентифицирует пользователя (он успешно вошёл в систему), но не проверяет или неправильно проверяет, имеет ли этот пользователь право выполнять конкретное действие. • Происходить это может по разным причинам, вот основные из них: • Доверие клиентской части (браузеру, мобильному приложению), которая сама решает, какие кнопки/меню показывать • Проверка прав только на уровне интерфейса • Применение проверок не во всех критичных эндпоинтах • Применение горизонтальной авторизацию, забыв про вертикальную • Главный принцип при защите: Каждый запрос к привилегированному эндпоинту должен проходить строгую проверку. Удачи! • Поддержать автора монеткой: @v_meshke

👁‍🗨Hello world~ Атаки на телефонную сеть: Изменение профиля абонента в VLR • Полгода спустя продолжаем изучать атаки на SS7. • Изменение профиля абонента в VLR (Visitor Location Register) — это атака, при которой злоумышленник с доступом к SS7 подделывает сообщения от HLR и посылает в MSC/VLR фальшивые Insert Subscriber Data или другие MAP-команды, чтобы изменить параметры абонента. • Как происходит атака: • Атакующий получает MSISDN (прямая цель) и с помощью SRI-For-SM или подобных запросов выясняет IMSI и адрес обслуживающего MSC/VLR и HLR. • Выдав себя за HLR (или за доверенный узел), атакующий отправляет в VLR Insert-Subscriber-Data с изменёнными параметрами: • Смена роуминг/биллинг-параметров (чтобы трафик не биллился) • Активация/деактивация услуг (call barring, call forwarding) • Добавление CAMEL/gsmSCF адреса для перехвата исходящих вызовов • Подмена маршрута SMS • Изменение параметров абонента (например, IMSI <-> MSISDN mismatch для прокси) • VLR отвечает Insert-Subscriber-Data-ACK и атакующий получает подтверждение успешного изменения. • Используя изменённый профиль, атакующий может совершать мошеннические звонки (в обход биллинга), перенаправлять входящие/исходящие звонки и SMS на свои узлы, отключать уведомления или менять настройки, чтобы жертва не получила оповещений. • Атакующий может позднее вернуть профиль в исходное состояние (еще раз ISD), чтобы скрыть следы, или поддерживать "тихую" подмену. • Поддержать автора монеткой: @v_meshke

👁‍🗨Hello world~ Интернет не анонимен...?: Все посты • Все посты из цикла, где мы рассматривали разные темы, связанные с анонимностью и безопасностью. • [Часть 1] Конфиденциальность vs Анонимность • [Часть 2] Как удалить свою онлайн-личность. Гугл • [Часть 3] Телеметрия приложений • [Часть 4] Пароли и их хранение • [Часть 5] DNS и его утечка • [Часть 6] Двухфакторная аутентификация • [Часть 7] Самый анонимный поисковик • [Часть 8] Базовая физическая приватность • [Часть 9] Защита сети и роутера • [Часть 10] Как вас могут раскрыть по радио волнам • [Часть 11] Самая анонимная ОС(?): Qubes OS • [Часть 12] Тор не анонимен: деанонимизация в даркнете • [Часть 13] Работа с сомнительными файлами и ссылками • [Часть 14] OPSEC: Как не стать мишенью при проведении расследований • Приятного чтения!

👁‍🗨Hello world~ Как найти айпи бекенда за CDN • Практически все нынешние веб-приложения, от малых до больших, стоят за CDN. Невозможность получить оригинальный айпи делает вектор нашей атаки ограниченным, сегодня мы поговорим, как можно попытаться это обойти. • Сразу стоит оговориться, что это не 100% способ, но часто рабочий. • Для начала мы собирает все поддомены, можно использовать sublist3r, subfinder, GooFuzz, theHarvester и другие, чем больше инструментов вы используете, тем больше будет потенциальных находок. Инструменты очень часто выдают одинаковый результат, так что получив все файлы с поддоменами объединяем их и оставляем только уникальные вхождения: cat file1.txt file2.txt файл3.txt ... file.txt | sort -u > subdomains.txt • Далее получаем данные с crt.sh: curl -s "https://crt.sh/?q=%25.example.com&output=json" -o crt.json • Получаем оттуда хосты: jq -r '.[].name_value' crt.json | sed 's/\*\.//g' | sort -u > crthosts.txt • Точно так же объединяем и оставляем только уникальные строки: cat subdomains.txt crthosts.txt | sort -u > stage2.txt • Получаем данные с веб архива: curl -s "http://web.archive.org/cdx/search/cdx?url=*.example.com&output=json&fl=original,timestamp" -o targwb.json • Снова получаем хосты: jq -r '.[1:][] | .[0]' targwb.json \ sed 's|https\?://||' \ cut -d'/' -f1 \ sort -u > targwbhosts.txt • Объединяем полученные хосты с предыдущим этапом и снова проводим дедупликацию: cat stage2.txt targwbhosts.txt | sort -u > stage3.txt • На этом этапе у нас есть максимально полный список доменов, которые когда-либо были связаны с таргетом. • Следующим шагом смотрим DNS записи в dnsdumpster и viewdns. Особый интерес представляют исторические A записи, хосты без CDN, адреса, относящиеся к обычным хостингам. • После этого проверяем текущие DNS записи локально: while read -r h; do dig +short A $h done < stage3.txt > dns.txt • Приводим все найденные IP к уникальному списку и внимательно анализируем адреса, которые выбиваются из общей картины CDN. • Далее переходим к TLS фингерпринтингу. CDN провайдеры, как правило, используют свои собственные сертификаты и массовые wildcard SAN. • Проверяем сертификаты у каждого домена: while read domain; do echo | openssl s_client -connect $domain:443 -servername $domain 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName done < stage3.txt • Обращаем внимание на: нестандартного Issuer, одинаковые даты выпуска, SAN, указывающие на инфраструктурные или технические домены. • Домены с SaaS назначением, support сервисами и сторонними платформами можно исключать. • На основе DNS и TLS данных формируем список наиболее вероятных кандидатов на origin. • Финальным шагом будет проверка прямого доступа к IP с сохранением SNI: curl -vk --resolve target.example.com:443:IP https://target.example.com/ • Если сервер отвечает корректно, сертификат валиден, а в заголовках отсутствуют упоминания CDN, то с высокой вероятностью это и есть айпи бекенда. • Метод не универсален, но при слабой сегментации инфраструктуры работает достаточно часто и позволяет существенно сузить поверхность атаки. Удачи! • Поддержать автора монеткой: @v_meshke

👁‍🗨Hello world~ Цифровая гигиена: День 3. Пароли и MFA: Забудьте про замены букв цифрами • На этом канале уже поднимались эти темы в цикле "интернет не анонимен" (про пароли, про MFA), но повторение никогда не повредит. • Слабые и повторяющиеся пароли, одна из главных уязвимостей большинства пользователей. Самые популярные пароли это 123456, admin, 12345678 и так далее. Даже не слив БД, а обычная лень делает людей уязвимыми. • Короткий пароль P@ssw0rd взломать легче, чем длинную фразу ulibok_tebe_ded_mokar. Длина важнее сложности спецсимволов, старайтесь использовать пароли и/или фразы от 20-30 символов. • Менеджеры паролей. Человек не способен запомнить 50 уникальных длинных паролей. Используйте локальные менеджеры, такие как KeePassXC. • Многофакторная аутентификация. Пароль — это только половина защиты, вторая половина — второй фактор. • Не используйте SMS. Симкарту можно перевыпустить по поддельной доверенности. Лучше используйте приложения генерации ключей, например: Aegis, Google Authenticator или Raivo. • Самый лучший, но оттого и не самый удобный способ, это аппаратные ключи, такие как YubiKey. • Если есть что добавить по этому поводу, пишите в комментарии. Удачи! • Поддержать автора монеткой: @v_meshke

👁‍🗨Hello world~ Security Misconfiguration: Уязвимость "по умолчанию" • Security Misconfiguration (Неправильная конфигурация безопасности) — это не уязвимость, а ситуация, при которой система настроена некорректно с точки зрения безопасности, что приводит к появлению уязвимостей. • В новом издании OWASP Top 10 она поднялась с пятого на второе место, так как 100% протестированных приложений имели ту или иную форму неправильной конфигурации. Чаще всего это были CWE-16 Конфигурация и CWE-611 XXE. • Приложение может быть уязвимым, если: • Включены или установлены ненужные функции • Стандартные учётные записи и их пароли включены и не изменены • Отсутствует централизованная конфигурация для перехвата избыточных сообщений об ошибках • Чрезмерный приоритет обратной совместимости приводит к небезопасной конфигурации • Параметры безопасности серверов приложений, фреймворков, баз данных и тд не установлены в безопасные значения • Не стоит легкомысленно относится к данным уязвимостям, так как на самом деле человеческий фактор может проявиться даже в крупных компаниях. Удачи! • Поддержать автора монеткой: @v_meshke

👁‍🗨Hello world~ Цифровая гигиена: День 2. Безопасная почта: Принцип разделения • Электронная почта — это ключ ко всей вашей цифровой жизни. Если взломают основной ящик, злоумышленники смогут сбросить пароли от соцсетей, облачных хранилищ и других важных приложений. Использовать один меил для всего это фатальная ошибка. • Возможное решение. Создаем "Управляющий аккаунт" (Control Account): Вам нужен отдельный, защищенный почтовый ящик (например ProtonMail, Tutanota или любой другой), который вы не будете использовать для переписки. • Этот адрес должны знать только вы и критически важные сервисы. Самое главное правило: нигде не светить его публично. • Маскировка адресов (Email Masking): Не оставляйте свой реальный меил на сомнительных сайтах, форумах или в магазинах. Используйте сервисы переадресации (SimpleLogin, AnonAddy или встроенные алиасы в Proton). • Так для каждого сервисы вы создаете уникальный адрес и если база данных магазина утечет, ваш основной ящик не попадет в спам-листы и другие базы. Ну а скомпрометированный алиас можно просто удалить. • Итог: Разделяйте личную переписку, финансы и мусорные регистрации по разным ящикам. Удачи! • Поддержать автора монеткой: @v_meshke

👁‍🗨Hello world~ BOLA: Самая частая уязвимость API • BOLA (Broken Object Level Authorization) — это уязвимость, при которой приложение не проверяет, имеет ли пользователь доступ к конкретному объекту. Она относится к Broken Access Control и является самой распространенной. • Некоторые могут подумать, что это тот же самый IDOR, но не совсем. IDOR это частный случай BOLA, когда объект доступен напрямую по идентификатору. BOLA шире: уязвимость возникает в любом случае, когда API не проверяет права доступа к объекту, даже если ID спрятан или сложный. • Пример BOLA. Пусть API заказов: GET /api/orders/98765 Authorization: Bearer USER_TOKEN • На сервере: SELECT * FROM orders WHERE id = 98765; • Ошибка. Нет проверки: AND user_id = current_user_id • Атакующий может посмотреть чужие заказы, узнать адрес доставки, а иногда отменить или изменить заказ, если есть: DELETE /api/orders/98765 • Особенно часто такую уязвимость можно заметить у GraphQL. • UUID, hash или random ID не защищают, если нет проверки владельца объекта. • BOLA не баг аутентификации, а проблема логики доступа, от чего она так часто встречается в проде. Удачи! • Поддержать автора монеткой: @v_meshke

👁‍🗨Hello world~ Цифровая гигиена: День 1. Бумага надежнее облака • Кибербезопасность это игра на опережение, если вы начинаете действовать только после инцидента, скорее всего, уже поздно. Последствия взлома всегда дороже и болезненнее, чем профилактика. • В этом цикле постов я решил адаптировать гайд по "базовой гигиене" от IntelTechniques. Это не про то, как стать невидимкой и уйти в леса, а про то, как не стать самой легкой добычей. • Всего будет 10 постов, приятного чтения! • Концепция Security Journal. Это физический блокнот, который находится в безопасном месте (ваш дом/сейф) и никогда его не покидает. Никаких заметок в телефоне, никаких текстовых файлов на рабочем столе, лишь бумага и ручка. • Зачем и почему? Очевидно, вероятность взлома ПК или облака кратно выше, чем шанс того, что к вам проберутся воры, чтобы украсть блокнот. • Что там хранить. • Мастер пароль. Пароль, который дает доступ ко всем остальным (условно от менеджера паролей). • Коды восстановления доступа (2FA) на случай потери телефона. • Сетевые данные. IP-адреса админок, логин/пароль администратора, настройки подсети. • Ответы на секретные вопросы. Никогда не пишите правду (девичья фамилия матери легко гуглится). Придумывайте ложь, а саму ложь записывайте в журнал. • Итог: заведите бумажный носитель. Это ваше "холодное хранилище" (Cold Storage), которое физически оторвано от интернета. Если завтра у вас сгорит телефон и заблокируется ноутбук, то этот блокнот вернет вам контроль над цифровой жизнью. Удачи! • Поддержать автора монеткой: @v_meshke