java -jar burploader.jar

Acunetix 15.5.230326230
Добавляем в файл hosts:
127.0.0.1 updates.acunetix.com
127.0.0.1 erp.acunetix.com
127.0.0.1 bxss.me
127.0.0.1 telemetry.invicti.com

license_info.json и wa_data.dat кидаем в директорию:
Windows >>> C:\ProgramData\Acunetix\shared\license\

Кладем "wvsc"в директорию:
Windows >>> C:\Program Files (x86)\Acunetix\core\

Или используем run.bat от админа.

Роадмапы по кибербезу
https://cybersecurity-roadmap.ru/
https://roadmap.sh/cyber-security

Когда решил разобраться в реверс-инжиниринге

Бложики на почитать
https://rt-solar.ru/solar-4rays/blog/
https://securelist.ru/
https://www.facct.ru/blog/
https://www.ptsecurity.com/ru-ru/research/analytics/
https://bi.zone/expertise/research/
https://www.securitylab.ru/analytics/

Переведенная на русский язык цепочка MITRE ATT&CK от PT
https://mitre.ptsecurity.com/ru-RU

CSP – Content Security Policy или Политика Безопасности Содержимого

Вкратце: это заголовок ответа сервера, в котором он определяет правила безопасности содержимого на данной странице, которым должен следовать браузер. Туда входят правила из разряда:
- скриптам с каких доменов разрешено исполняться на этой странице (script-src);
- каким доменам разрешено встраивать эту страницу в iframe (frame-ancestors);
- разрешено ли использование base-тегов (base-uri).

Подробнее: https://developer.mozilla.org/ru/docs/Web/HTTP/CSP

Когда оно нам нужно: если какая-то атака (обычно XSS или Clickjacking) не работает там, где должна – надо смотреть CSP-заголовок и изучать эти самые правила, чтобы понять, не в них ли причина.

Еще иногда я заранее смотрю CSP, если собираюсь ковырять какой-нибудь сложный XSS-санитайзер. Потому что бывали случаи, когда сутки его обходишь, а потом оказывается, что на странице CSP, и XSS все равно не добиться.

Есть классный сервис проверки безопасности CSP от гугла – https://csp-evaluator.withgoogle.com. Тут можно проверить, есть ли шанс обойти CSP или ловить нечего.

SOP – Same Origin Policy или Политика Одного Источника

Вкратце: это базовый защитный принцип, который обеспечивает безопасность нашего привычного веба, и в соответствии с которым работают все браузеры. Основная мысль очень простая: один сайт не должен иметь доступ к другому сайту. Под "сайтом" браузер понимает origin, который состоит из схемы, хоста и порта.

То есть скрипт, находящийся на сайте https://google.com никак не получит данные пользователя с сайта https://yandex.ru. И даже не пройдут запросы с https://yandex.ru на https://yandex.ru, так как все три составных части origin должны быть одинаковыми, чтобы браузер разрешил такой доступ.

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

Мы, конечно, можем отправить запрос от одного origin к другому, но браузер не пошлет вместе с ним cookie пользователя, а значит максимум мы сможем посмотреть версию страницы для неаутентифицированного пользователя, что бесполезно.

Подробнее: https://developer.mozilla.org/ru/docs/Web/Security/Same-origin_policy

Когда оно нам нужно: только когда мы еще не понимаем этот базовый принцип и пытаемся делать вещи, которые в 2022 году просто невозможны. А так один раз запомнили – и навсегда.

CORS – Cross-Origin Resource Sharing или Межсайтовое Разделение Ресурсов

Вкратце: это механизм, который позволяет легально обойти SOP. Иногда (часто) все-таки нужна возможность отправлять запросы с одного origin на другой. Для этого придумали CORS. Владелец сайта, данные с которого должны быть доступны для других сайтов, должен отправлять вместе с ответом разрешающие заголовки типа
Access-Control-Allow-Origin: https://google.com

В случае выше, запрос с сайта https://google.com сможет получить данные с такого сайта. Ну и там не все так примитивно, конечно.

Подробнее: https://developer.mozilla.org/ru/docs/Web/HTTP/CORS

Когда оно нам нужно: для поиска уязвимостей типа CORS misconfiguration. Иногда (опять же часто) список origin, которым разрешено получать данные с целевого сайта на фиксирован, а, допустим определен с помощью маски.

Например, владелец хочет, чтобы любой домен гугла мог бы прочитать данные с его сайта. И он пишет код, который смотрит на origin, который делает запрос, и если этот origin соответствует *.google.* – разрешает доступ. Периодически бывает, что этот код написан криво и мы можем также запросить эти данные, допустим, с вредоносного домена google.hacker.ru.
Бонус: https://blog.deteact.com/ru/csp-bypass/

https://websec.fr/# потыкать вебчик
https://application.security

Что такое CTF и как в него влиться
https://kmb.cybber.ru/
https://course.ugractf.ru/
Hackerdom's lessons: https://www.youtube.com/playlist?list=PLU-TUGRFxOHjDvu4NHrpFdpYI20-zOG2-

Принял участие в айти трансформации 2024, увидел много знакомых лиц, но ничего нового не узнал

Приятно, что где-то на просторах гитхаба еще остались хорошие репы:)

Например, тут рисуют майндмапы по безопасности_чего_нибудь, есть исходники, выглядит неперегруженно и адекватно:)

Like!🥰

Бинарщина
https://www.rsdn.org/article/baseserv/peloader.xml
https://habr.com/ru/articles/480642/
https://habr.com/ru/articles/266831/
https://wasm.in/blogs/vvedenie-v-mashinnyj-kod.131/
https://hackware.ru/?p=8654

Я обычно не ругаюсь, по крайней мере тут, но это просто "ебаный стыд"

CVE-2024-9313
Severity: High (8.8)
Os: Ubuntu
Target : PAM module
Affected versions: < 0.3.5

В двух словах, можно в su|sudo|sshd ввести имя одного пользователя, а пароль ввести от другого и это сработает....
Это, судя по всему, не касается вашей домашней убунты, речь идет про

Authd is an authentication daemon for cloud-based identity providers. It helps ensure the secure management of identity and access for Ubuntu machines anywhere in the world, on desktop and the server. Authd's modular design makes it a versatile authentication service that can integrate with multiple identity providers. MS Entra ID is currently supported and several other identity providers are under active development.

, но все равно это 🤦‍♂️🤦‍♂️🤦‍♂️.

https://github.com/ubuntu/authd/security/advisories/GHSA-x5q3-c8rm-w787