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

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