ZeroDay | Кибербезопасность

ZeroDay | #мем

🤖Бесплатный ChatGPT

❔Через что проходит сервер перед релизом? Узнайте на экскурсии по лабораториям YADRO

В ноябре и декабре YADRO проводит экскурсии по своим лабораториям в Санкт-Петербурге и Москве. В программе тестовые стенды, серверы, системы хранения данных и телеком-оборудование, а также разговоры с инженерами, которые всё это проверяют.

◾Санкт-Петербург — 12 ноября и 1 декабря
◾Москва — 17 ноября и 8 декабря
Сбор гостей в 18:30, старт в 19:00.

Участие бесплатное — нужно зарегистрироваться и дождаться подтверждения от организаторов. Возраст участников — от 18 лет.

👉 Зарегистрироваться

Реклама. ООО "КНС ГРУПП". ИНН 7701411241. erid: 2W5zFGUJq7p

🤖Бесплатный ChatGPT

📝 Держите набор шпаргалок по кибербезу

🤖Бесплатный ChatGPT

ARP Flux: почему Linux отвечает за IP не с того интерфейса

👋 Приветствую в мире цифровой безопасности!

На сервере две сетевые карты, у каждой свой IP. Но в ARP-таблице соседнего устройства адрес первой карты вдруг оказывается привязан к MAC второй. Проверяешь настройки, а там всё вроде правильно. Откуда взялся чужой MAC? У Linux есть такая особенность, называется ARP Flux.

⏺В чём дело? Linux по умолчанию считает IP-адреса принадлежащими всему хосту, а не отдельной сетевой карте. Поэтому, когда оба интерфейса находятся в одной подсети, ядро может ответить на ARP-запрос через интерфейс, которому этот IP не назначен.

⏺В результате соседние устройства получают неожиданные соответствия IP и MAC. Особенно неприятно, когда из-за этого начинает скакать связность.

⏺Проверим, как настроен ARP:

sysctl net.ipv4.conf.all.arp_ignore
sysctl net.ipv4.conf.all.arp_announce
sysctl net.ipv4.conf.all.arp_filter

Если arp_ignore=0, ядро может отвечать на запросы о локальных IP, даже когда они назначены другому интерфейсу.

⏺Теперь посмотрим, что происходит в сети. На сервере запускаем захват ARP:

sudo tcpdump -eni eth0 arp
sudo tcpdump -eni eth1 arp

А с соседней машины отправляем запрос к одному из IP сервера:
sudo arping -I eth0 192.168.1.10
Сравниваем ответы и MAC-адреса. Если один IP отвечает через разные интерфейсы, причину уже легче искать.

⏺Как привести ARP в порядок? Для обычного сервера с двумя интерфейсами в одной подсети часто хватает:

sudo sysctl -w net.ipv4.conf.all.arp_ignore=1
sudo sysctl -w net.ipv4.conf.all.arp_announce=2

arp_ignore=1 заставляет отвечать только за IP принимающего интерфейса, а arp_announce=2 помогает выбирать подходящий исходный адрес для ARP-запросов. Только не применяйте настройки вслепую на серверах с VRRP, bonding или сложной маршрутизацией. Там могут понадобиться другие параметры, включая arp_filter и policy routing.

⏺Кстати, ARP Flux легко спутать с конфликтом IP или проблемой на коммутаторе. Поэтому, если в соседской ARP-таблице постоянно меняется MAC, сначала проверьте, не отвечает ли сам Linux сразу с нескольких интерфейсов.

🤖Бесплатный ChatGPT

3 топовых приёма для пентестинга

👋 Приветствую в мире цифровой безопасности!

Собрал ещё три приёма для проверки веб-приложений. На первый взгляд мелочи, но иногда именно в них прячутся интересные уязвимости.

⏺Mass Assignment - сервер может принимать поля, которых вообще нет в интерфейсе. Например, обычный запрос на изменение профиля:

PATCH /api/profile HTTP/1.1
Content-Type: application/json

{“name”:”Alex”,”email”:”alex@example.com”}

А что, если добавить isAdmin?

{“name”:”Alex”,”isAdmin”:true}

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

⏺HTTP Method Override - некоторые серверы позволяют переопределять метод запроса через заголовок:

POST /api/users/42 HTTP/1.1
Host: example.com
X-HTTP-Method-Override: DELETE

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

⏺JSON Type Confusion - попробуйте вместо ожидаемой строки передать массив:

{“userId”:”42”}

Заменяем на:

{“userId”:[“42”]}

Если API, промежуточный сервис и бэкенд по-разному работают с типами данных, могут возникнуть ошибки в проверках доступа и сравнении значений. Особенно стоит присмотреться к API, где запрос проходит через несколько компонентов. Главное, проверять не только ответ сервера, но и то, изменилось ли поведение приложения.

🤖Бесплатный ChatGPT

OWASP Juice Shop: интернет-магазин, который можно легально взломать

👋 Приветствую в мире цифровой безопасности!

Хотели попробовать веб-пентест на практике? У OWASP есть ``интернет-магазин``, который специально напичкали уязвимостями. Можно искать SQL-инъекции, обходить авторизацию, копаться в API и при этом никому не мешать.

⏺OWASP Juice Shop выглядит как вполне обычный магазин с товарами, корзиной и личным кабинетом. Но внутри спрятаны десятки заданий по OWASP Top 10 и другим уязвимостям. Некоторые находятся за пару минут, над другими придётся посидеть.

⏺Поднять свой магазин можно через Docker:

docker pull bkimminich/juice-shop

docker run —rm -p 127.0.0.1:3000:3000 \
bkimminich/juice-shop

Заходим на http://localhost:3000 и начинаем исследовать приложение.

⏺Например, попробуйте зарегистрировать два аккаунта и проверить, можно ли через изменение запросов получить доступ к чужой корзине. Или откройте Burp Suite, перехватите запрос авторизации и посмотрите, какие данные отправляет приложение.

⏺За успехами можно следить через Score Board. Там собраны задания разной сложности, а найденные уязвимости отмечаются автоматически. Если совсем застряли, есть бесплатное руководство Pwning OWASP Juice Shop с подсказками и решениями.

🔥Ещё на Juice Shop удобно тренироваться с OWASP ZAP и другими сканерами. Запускаете проверку, смотрите результаты, а потом вручную ищете то, что инструмент пропустил.

🤖Бесплатный ChatGPT

Хотел скачать ISO, а пришлось взламывать собственный роутер

У автора постоянно бились файлы при загрузке по Wi-Fi. SSH ругался на целостность данных, TLS выдавал bad record mac, хотя TCP уверял, что с пакетами всё нормально. Виновником оказалась точка доступа TP-Link с багом в драйвере Qualcomm. Исправление требовало всего двух команд, но производитель забросил прошивку, а root-доступ закрыл.

⏺Пришлось искать путь через ядро Linux. Автор связал CVE-2022-0185 с манипуляциями над буфером pipe и потратил 17 часов на доводку эксплойта с помощью Claude. В статье разбирают и сам взлом, и хитрый баг DMA-кэша, из-за которого 64 байта пакета превращались в мусор, но TCP этого даже не замечал.

🤖Бесплатный ChatGPT

ZeroDay | #мем

🤖Бесплатный ChatGPT

PATH Hijacking: когда Linux запускает не ту команду

👋 Приветствую в мире цифровой безопасности!

Сегодня разберём атаку PATH Hijacking. Она интересна тем, что хакеру по факту даже не нужно менять сам скрипт. Достаточно повлиять на то, какую команду он запустит.

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

tar -czf /backup/site.tar.gz /var/www

Но путь к tar не указан. Поэтому оболочка ищет исполняемый файл в каталогах из переменной $PATH, причём строго по порядку.

⏺Если первым в списке окажется каталог, куда атакующий может записывать файлы, он сможет разместить там свою программу с именем tar. При следующем запуске скрипта система может выполнить её вместо /usr/bin/tar. Особенно неприятно, если скрипт запускается через cron или от имени root. Тогда подменённая команда получит права этого процесса.

⏺Проверить порядок поиска можно буквально двумя командами:

echo “$PATH”
type -a tar

Первая покажет список каталогов, а вторая - все найденные варианты команды. Если раньше /usr/bin стоит подозрительный пользовательский каталог, это повод разобраться.

⏺Для защиты в критичных скриптах лучше указывать полный путь к исполняемым файлам:

/usr/bin/tar -czf /backup/site.tar.gz /var/www

А в начале скрипта можно явно задать безопасный PATH:

PATH=/usr/sbin:/usr/bin:/sbin:/bin
export PATH

⏺Отдельно стоит проверять задания cron, systemd-сервисы и скрипты, которые запускаются с повышенными правами. Даже безобидный вызов cp, tar или curl может стать проблемой, если команда ищется в каталоге, доступном для записи посторонним.

⏺И важный нюанс: сама по себе переменная PATH не даёт повышения привилегий. Для атаки нужно, чтобы привилегированный процесс действительно использовал небезопасный путь поиска.

Если нужна вторая часть с практическим разбором обнаружения PATH Hijacking, ставьте ``🔥

🤖Бесплатный ChatGPT

Как защитить Linux-сервис от чтения чужих файлов через systemd

👋 Приветствую в мире цифровой безопасности!

Допустим, на сервере работает небольшой API или бот. Вы запускаете его от отдельного пользователя, но процесс всё равно может читать множество системных файлов и обращаться к каталогам, которые ему вообще не нужны.

⏺Если в приложении найдут RCE, этим доступом смогут воспользоваться. У systemd есть встроенные механизмы, позволяющие сильно ограничить файловую систему для конкретного сервиса.

⏺Для начала посмотрим, насколько защищён сервис. У systemd есть собственный анализатор настроек безопасности:

systemd-analyze security nginx.service

Он покажет список ограничений и оценку доступных процессу возможностей. Чем выше exposure score, тем больше потенциальная поверхность атаки. Но это оценка конфигурации, а не проверка реальных уязвимостей.

⏺Закроем доступ к домашним каталогам. В конфигурации сервиса можно добавить:

[Service]
ProtectHome=true
ProtectSystem=strict
PrivateTmp=true

ProtectHome скрывает /home, /root и /run/user, ProtectSystem делает почти всю файловую систему доступной только для чтения, а PrivateTmp выделяет процессу отдельные временные каталоги.

⏺А куда тогда записывать данные? Вместо открытия доступа ко всей файловой системе разрешим только нужный каталог:

[Service]
StateDirectory=myapp
RuntimeDirectory=myapp

systemd создаст /var/lib/myapp и /run/myapp и обеспечит сервису возможность записи в них даже при ProtectSystem=strict.

⏺Ограничим доступ к устройствам и ядру. Большинству обычных веб-приложений не нужны управление модулями ядра, изменение системных параметров и прямой доступ к оборудованию:

[Service]
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
NoNewPrivileges=true

Эти настройки сокращают возможности процесса, если атакующему удастся выполнить в нём свой код.

⏺Применяем настройки через override, не редактируя исходный unit-файл:

sudo systemctl edit myapp.service

Добавляем параметры в секцию [Service], затем проверяем и перезапускаем:

sudo systemctl daemon-reload
sudo systemctl restart myapp.service
sudo systemctl status myapp.service

Если приложение перестало работать, смотрим ошибки:

journalctl -u myapp.service -n 50

И повторно проверяем ограничения:

systemd-analyze security myapp.service

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

🤖Бесплатный ChatGPT