Kubernetes Privilege Escalation.
#Kubernetes #Red_team #Blue_Team

Помимо того что Tailscale делают крутой продукт, они круто пишут в свой блог.
Вот это очень крутой пост про RBAC и другие модели разграничения доступа.
Сама модель RBAC родилась в американской армии.

https://tailscale.com/blog/rbac-like-it-was-meant-to-be

bpython - удобный интерпретатор python с подсветкой синтаксиса и подсказками 🔥

👉 https://github.com/bpython/bpython

#python

​​🔎 Дорки для различных инструментов поиска

Практически каждый из вас слышал про Google Dorks, но гораздо менее известны дорки для Yandex, DuckDuckGo, Bing, VirusTotal, Github, Shodan и тд

Вот вам небольшая коллекция утилит и ссылок на списки дорков для различных инструментов поиска.

Google, Bing, Ecosia, Yahoo или Yandex
https://github.com/Zarcolio/sitedorks

Google dorks
https://github.com/BullsEye0/google_dork_list
https://github.com/sushiwushi/bug-bounty-dorks
https://github.com/rootac355/SQL-injection-dorks-list
https://github.com/unexpectedBy/SQLi-Dork-Repository
https://github.com/thomasdesr/Google-dorks
https://github.com/arimogi/Google-Dorks
https://github.com/aleedhillon/7000-Google-Dork-List

DuckDuckGo dorks
https://github.com/d34dfr4m3/goDuck

Github dorks
https://github.com/techgaun/github-dorks
https://github.com/jcesarstef/ghhdb-Github-Hacking-Database
https://github.com/H4CK3RT3CH/github-dorks

Shodan dorks
https://github.com/humblelad/Shodan-Dorks
https://github.com/AustrianEnergyCERT/ICS_IoT_Shodan_Dorks
https://github.com/lothos612/shodan
https://github.com/jakejarvis/awesome-shodan-queries
https://github.com/IFLinfosec/shodan-dorks

Virus Total dorks
https://github.com/Neo23x0/vti-dorks

Binary Edge + Shodan + Google
https://github.com/iGotRootSRC/Dorkers

#web #recon #dork

👨🏻‍💻 S.E.Заметка. Network Security Labs.

🖖🏻 Приветствую тебя user_name.

Пентестеры выявляют бреши в безопасности, атакуя сети точно так же, как это делают злоумышленники. Чтобы стать пентестером высокого уровня, тебе необходимо освоить наступательные концепции безопасности, использовать проверенную методологию и постоянно тренироваться. В этом посте ты найдешь ссылки на полезные лабы, которые охватывают тему сетевой безопасности: от атак и уязвимостей протоколов TCP/IP и DNS до VPN и IPSec. Описание каждой лабы, ты можешь найти по ссылкам ниже:

• TCP/IP Attack Lab;
• Heartbleed Attack Lab;
• Local DNS Attack Lab;
• Remote DNS Attack Lab;
• Packet Sniffing and Spoofing Lab;
• Linux Firewall Exploration Lab;
• Firewall-VPN Lab: Bypassing Firewalls using VPN;
• Virtual Private Network (VPN) Lab;
• Minix IPSec Lab;
• Minix Firewall Lab.

‼️ Дополнительный материал, ты сможешь найти по хештегу #Пентест #ИБ #Сети и #CTF. Твой S.E.

"A tale of making internet pollution free" - Exploiting Client-Side Prototype Pollution in the wild

https://blog.s1r1us.ninja/research/PP

Коллега с Hexlet рассказывает про DNS и стадии выполнения сетевого запроса
https://www.youtube.com/watch?v=z4K9_Ezk6NQ&ab_channel=%D0%92%D0%B5%D0%B1%D0%B8%D0%BD%D0%B0%D1%80%D1%8B%D0%9D%D0%B0%D0%A5%D0%B5%D0%BA%D1%81%D0%BB%D0%B5%D1%82%D0%B5

Recon Guide for Pentesters and Bug Bounty Hunters

#Red_team

Не самые очевидные баги, которые многие зачастую пропускают:
https://telegra.ph/10-tipov-veb-uyazvimostej-kotorye-chasto-ne-zamechayut-09-30

Про третий из списка как раз недавно рассказывал LiveOverflow на примере занимательного кейса с CSCG.

Репост из канала Данилы Кутенина (орфография и пунктуация автора) про тестирование движка для регулярных выражений:

В последние 2 недели периодически, когда мне было лень работать, я пытался сделать что-то интересное, но до большого и громкого поста не дотягивало. В любом случае, поделиться стоит.

Меня задолбали различные движки регулярных выражений и каждый раз, когда я смотрел на них, мне хотелось понять, как они под капотом тестируются. После изучения многих библиотек, я понял, что поддержка огромного количества токенов так грустно покрыто юнит тестами, что я захотел либо найти достойное тестирование (спойлер, не нашёл), либо десятки багов в этих движках. Суммарно за несколько дней я нашёл 11 багов, 2 в boost (уже были зарепорчены 1, 2), 4 новых в hyperscan, 5 новых в compile time regular expressions (будущие regex в плюсовом стандарте) и огромное количество (нет, просто капец тьму) несоответствия между синтаксисами различных движков, например, что в RE2 синтаксисе whitespace (\s) не поддерживается вертикальный tab \v, хотя во всех остальных движках оно одинаково поддерживается. Или даже лучше (не баг, различие в грамматиках):

#include <boost/regex.hpp>
#include <regex>
#include <iostream>

int main() {
  {
    std::regex e{"\\<\\<\\w+"};
    std::cout << std::regex_search("a ", e) << std::endl; // prints 0
  }
  {
    boost::regex e{"\\<\\<\\w+"};
    std::cout << boost::regex_search("a ", e) << std::endl; // prints 1
  }
}

Python RE, PCRE/PCRE2, RE2 прошли тестирование. Видимо, big tech является для них самым главным тестировщиком :)

В отличие от стандартного тестирования, я пытался сделать что-то новое, а именно

1. Создаем случайное валидное регулярное выражение, например, с помощью случайного дерева или автомата
2. Если движок отказывается его компилировать, это баг. Можно здесь ещё считать majority от движков и репортить те, которые не подчиняются ему
3. Создаем строки подходящие под это регулярное выражение, если они не матчатся, то это баг. Создаём почти подходящие строки, если они матчатся, это баг. Здесь я использовал идеи из статьи egret и питонячнее .sre_parse
4. Фаззим с помощью libfuzzer входные строки для поиска, пытаемся найти рантайм баги и сверяем корректность у majority движков

У многих движков настроен фаззинг, только они не проверяют полноту. К счастью, видимо, весь хлеб такого тестирования фаззинг у меня и забрал, мой план лишь быстрее увеличивал покрытие. Например, такой план увеличивал покрытие hyperscan до 90% за 2 часа, когда как обычный фаззинг делал это 3 дня.

Несмотря на баги, hyperscan всё ещё считаю лучшим движком by far от всех остальных. Там очень много очень классного кода, написано хорошо, работает очень быстро (сотни мегабайт в секунду). Недавно узнал, что там можно собирать регулярные выражения в satisfiability дерево, например, в ((1 & 2) | (!3 & 2)), где 1, 2, 3 — регулярные выражения. Так они ещё там внутри и оптимизируются.

Если говорить про различие синтаксисов, то есть неплохая табличка.

Ну, 11 багов, that ain't much but that's honest work. Надеялся на много десятков минимум :)

Facebook выложил в паблик инструмент Mariana Trench для анализа исходных кодов для Android и Java. До этого они уже выкладывали свои анализаторы исходников Zoncolan и Pysa (для Hack и Python) https://t.co/omuM4FuKqn
— Alexey Lukatsky (@alukatsky) Sep 30, 2021

#dns #network