• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Статья DNS Spoofing или "Галя, вставай у нас http украли"?

Форумчане, приветствую! Для того чтоб понять суть вопроса желательно ознакомиться с https://habr.com/post/415981/ Кому лень читать, вкратце, Google начал выдавать предупреждение пользователям при подключениях по http к каким либо сайтам, к каким именно сейчас не важно - важна суть, что мол соединение не защищено и тд. Казалось бы при чем здесь спуфинг? Но, не далее чем неделю назад все было иначе. Многие ресурсы с SSL сертификатами подгружали скрипты с CDNов по http, возьмем для примера СDN с jQuery. То есть при переходе на https://example.com если в html мы видим src="//code.jquery.com/jquery-х.х.х.js он успешно подгружался по http и выполнялся, не смотря на то что сам ресурс на https. Но, теперь все изменилось, если пользователь подключается по https то и все содержимое должно загружаться по https даже если в src будет явно указан http, иначе это содержимое не будет загружено. Хотя это все логично, с точки зрения безопасности, если мы можем подгрузить скрипт в обход https, тогда сам этот протокол теряет смысл. Теперь по спуфингу, в данном контексте, интерес именно в масштабах, а не в отдельно взятом target. К примеру у нас есть DNS сервер (здесь вообще все для примера, не расцените как призыв к действию или true story), который является мастером для интересующих зон и кэширующим для остальных. При запросе записи типа А клиент получает подставной IP вышеуказанного src, он идет туда и видит два порта 80 и 443, если сайт с которого подгружается src на http то он с 80 загружает и выполняет, а если на ssl то то это 443 и естественно нет валидного сертификата. Пробовал решить через запись (там сверху, SOA jquery.com, A и NS тоже присутствуют )

code IN CNAME myevildomain.com. (естественно он потом в другой мастер зоне резолвится в нужный IP)

Делал несколько CNAMЕов с одного на другой, клиент все равно просит сертификат на code.jquery.com В обратном порядке выстраивать цепочку, образно говоря типа myevildomain.com CNAME code.jquery.com, тоже смысла нет, поскольку запросы будут выполняться рекурсивно с com. > jquery.com. и тд. Короче, суть такова есть валидный серт myevildomain.com и нужно чтоб клиент просил сертификат именно от него. Возможно кто то сталкивался или есть идеи. Сразу говорю что HSTS тут не причем, редирект 443>80 не прокатит - браузер сначала серт проверит, ngrok тоже ничего не изменит, запись DNS типа CAA тоже ничего не даст она для CA, а не для браузеров (хотя штука довольно таки интересная, с ее помощью можно запретить выдачу сертификатов любыми CA конкретному домену )
 

Yevgen

Green Team
28.06.2018
16
17
BIT
0
Если вдруг кто что не понял в эти src вполне себе хорошо дописывается скрипт на майнинг в браузере, антивирус и адблокеры молчат. Если у кого есть идеи по решению вопроса пишите, все моменты обсуждаемы
 
R

r4gnar0ck

Но, теперь все изменилось, если пользователь подключается по https то и все содержимое должно загружаться по https даже если в src будет явно указан http, иначе это содержимое не будет загружено. Хотя это все логично, с точки зрения безопасности, если мы можем подгрузить скрипт в обход https, тогда сам этот протокол теряет смысл.
Это то понятно, но расскажите другую вещь. Что если ситуация обратная: у нас есть , к которому образно подключается файл . В таком случае, если спуфить cdn.jquery.com, получится подменить cdn.jquery.com/jquery-1-4-8-8.js на сайте
Надеюсь пример понятный. Там главное обратить внимание на HTTP и HTTPS протоколы.
Жду ответов, камрады.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!