URL и ссылки в письмах
Немного про разные подставные URL/URI, используемые в целевых рассылках по электронной почте (имитирующих “запрос на смену пароля”, “просмотр заказа” или ещё что-то), а также в других подобных инструментах. Такие ссылки, как известно, могут вести совсем не туда, “куда написано”, или почти туда, но, всё же, не совсем – последнее актуально для корпоративных сред. Помимо подмены DNS и прочих внешних действий, у самих ссылок есть некоторые занимательные признаки, повышающие “степень подозрительности”.
Понятно, что современные почтовые клиенты позволяют замаскировать реальную ссылку многими способами, начиная от простой замены с использованием HTML и вплоть до изящных трюков с CSS, спецсимволами, сочетаниями букв, которые похожи по начертанию на “настоящее имя”, с картинками и Punycode. Бывает, что ссылка отображается верно, но выглядит от этого только подозрительнее. Простой признак: какое-то странное “цифровое” имя – site-11.test.ru. (Здесь test.ru выбрано вместо того или иного “корпоративного” домена.) Очень редко использование разных “технических хостнеймов” может быть тут уместным. Скорее – это просто случайный взломанный узел в корпоративной сети: используется то имя, которое досталось, то есть, было присвоено ранее, возможно, автоматически.
Открытый протокол HTTP (http://), если его использование вообще возможно, тоже добавляет баллы подозрительности. Если ссылка указывает на http://example.com/api/123/, то это вовсе и не означает, что, при клике, она поведёт браузер на настоящий узел под example.com. И речь даже не про подмену DNS. Запрос с протоколом HTTP – то есть, направляемый в открытом виде, – может быть перехвачен и перенаправлен на промежуточном узле. Скажем, взломан либо сам этот промежуточный узел (читай – “роутер”), либо, через ту или иную атаку с подменой сетевых маршрутов, трафик конкретной атакуемой рабочей станции может быть перенаправлен в направлении нужного узла (иногда это может делаться при помощи атаки на уровне клиента VPN). Понятно, что при таком перенаправлении перехватить можно любые запросы, однако, если используется TLS/HTTPS, то защищённый трафик ещё нужно раскрыть, что довольно трудно, да и аккуратная подмена открытых запросов требует более изящного подхода – поэтому прочий трафик, не с заданным в ссылке хостнеймом, будет переправляться к месту назначения без изменений.
Отдельный характерный момент, про который часто забывают, – непривилегированный номер порта. Если в ссылке указано example.com:7788 (то есть, на порт с номером 7788, больше 1000), то это может свидетельствовать о том, что трафик будет принимать какое-то приложение, запущенное с правами обычного пользователя. Другими словами: на каком-то произвольном сервере в локальной сети подсажена программа с правами непривилегированного пользователя, сервер имеет имя в локальном DNS-сервисе – всё, можно принимать трафик по HTTP. Можно и по HTTPS, если удалось получить подходящий TLS-сертификат, однако с сертификатом всё несколько сложнее.
Адрес записки: https://dxdt.ru/2024/10/09/14021/
Похожие записки:
- Реплика: атака посредника в TLS и проблема доверия сертификатам
- Новые корневые сертификаты на audit.statdom.ru
- Google и LLM ИИ в поиске
- Набеги ботов под прикрытием AI
- Занятный замок Fichet 787
- Реплика: преодоление air gap
- Реплика: возможный доступ приложений "Яндекса" к OBD автомобиля
- Статья Cloudflare про ECH/ESNI
- Реплика: интернет-названия
- Приложение про DNS к описанию TLS
- Наложенные сети Google и браузеры в будущем
Написать комментарий