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

https://github.com/nuvious/pam-duress

#фидбечат #pam #security

Моя учительница английского говорит, что если каждый день заполнять вот такую табличку времен английского (на английском, конечно же), то очень скоро проблем с этой частью грамматики языка не будет вовсе. И чтобы обучение шло проще, заполнять надо привычными нам словами - protect, securе, test, check, evaluate, outsource, defend, attack, avoid, comply и т.п.

Любопытный инструмент

На недавнем ZN, играя в CTF'чик, зайдя на хост, увидел любопытный инструмент - pspy64. Раньше такого не встречал.

Запустив, понял что этот инструмент находясь в *user space* показывает все запущенные процессы системы с их cmdline и т.д. (В том числе рутовые процессы и процессы других пользователей системы).

Понял что тут примешено чутка хакерской магии, т.к. просто дампнуть процессы пользователя root мы конечно же не можем. Я понимал, что можно спарсить /proc, но это не настолько подробно и мне казалось что это весьма долго.

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

Встречайте: https://github.com/DominicBreuker/pspy

pspy - unprivileged Linux process snooping

pspy - это инструмент командной строки, предназначенный для наблюдения за процессами без необходимости получения прав root. Он позволяет просматривать команды, запущенные другими пользователями, задания cron и т.д. по мере их выполнения. Отлично подходит для исследования систем Linux в CTF. Также отлично подходит для демонстрации коллегам, почему передача секретов в качестве аргументов в командной строке - плохая идея.

Как это работает

Существуют инструменты, позволяющие перечислить все процессы, выполняемые в системах Linux, включая те, которые завершились. Например, существует forkstat. Он получает уведомления от ядра о событиях, связанных с процессами, таких как fork и exec.

Эти инструменты требуют привилегий root, но это не должно вызывать у вас ложного чувства безопасности. Ничто не мешает вам подглядывать за процессами, запущенными в системе Linux. Много информации видно в procfs до тех пор, пока процесс запущен. Единственная проблема заключается в том, что вам нужно поймать недолговечные процессы за очень короткий промежуток времени, в течение которого они живы. Сканирование каталога /proc в поисках новых PID в бесконечном цикле делает этот трюк, но потребляет много CPU.

Более скрытный способ - использовать следующий трюк. Процессы обычно обращаются к таким файлам, как библиотеки в /usr, временные файлы в /tmp, файлы журналов в /var, ... Используя API inotify, вы можете получать уведомления всякий раз, когда эти файлы создаются, изменяются, удаляются, к ним обращаются и т.д. Linux не требует прав привилегированных пользователей для работы с этим API, поскольку он необходим для многих невинных приложений (например, текстовых редакторов, показывающих актуальный проводник файлов). Таким образом, хотя пользователи без права root не могут напрямую следить за процессами, они могут следить за влиянием процессов на файловую систему.

Мы можем использовать события файловой системы как триггер для сканирования /proc, надеясь, что мы сможем сделать это достаточно быстро, чтобы поймать процессы. Именно это и делает pspy. Нет гарантии, что вы не пропустите ни одного процесса, но в моих экспериментах шансы кажутся высокими. В общем, чем дольше идут процессы, тем больше шансов их поймать.

Что сказать? Гениально!

Дорожная карта для исследователя безопасности веб-приложений, разбитая на уровни подготовки.

https://securityflow.io/roadmap/

#roadmap

Окей, как показала практика netns может вполне себе существовать и без pid запущенных в нём, это называется persistent namespace и отличается наличием маунтпоинта в системе

ip netns add foo создаёт маунтпоинт в /run/netns/foo, и пока он существует, существует и нетворк неймспейс.

Если сделать ip netns del foo или umount /run/netns/foo, то нетворк неймспейс ожидаемо удаляется со всеми интерфесами, но только если в нём не осталось никаких процессов. В противном случае нетворк неймспейс продолжит существовать. Как только умирает послелний процесс в неймспейсе, то убивается и сам неймспейс со всеми интерфейсами.

Докер использует persistent неймспейсы, и маунтит их в /run/docker/netns, именно по этой причине они не видны в ip netns, который смотрит в /run/netns и, ожидаемо ничего там не находит.

Стоит упомянуть что для каждого запущенного процесса в procfs можно найти файл неймспейса в котором он работает ls /proc/*/ns/net

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

ln -s /proc/123/ns/net /run/netns/foo
ip netns foo exec /bin/bash

или ещё проще:

nsenter -t 39608 -n /bin/bash

Чтобы вывести список всех неймспесов:

персистентных (включая неймспейсы без процессов):

grep nsfs /proc/mounts

неперсистентных (неймспейсы с запущенными процессами)

lsns -t net

PS: всё вышесказанное валидно не только для network неймспейсов но так же и для всех остальных
https://man7.org/linux/man-pages/man1/unshare.1.html

сегодня я стал чуточку умнее 🙂

The Show Must Go On: Securing Netflix Studios At Scale

Статья от Netflix о том, как они сделали аутентификацию аспектом архитектуры, а не вопросом реализации того или иного приложения. Как итог Netflix отказались от security-листа для разработчика, заменив весь пул вопросов на один - "Будете ли вы использовать наш gateway Wall-E"? (доработанная версия Zuul с точки зрения безопасности). Команда рассказывает, с какими сложностями она при этом столкнулась и к каким решениям пришла.

Основной вывод статьи в следующем - вместо предоставления разработчикам вариации путей, по которым они могут сделать свой продукт безопасным, целесообразнее (в том числе и с точки зрения масштабирования на скорости Netflix) создать "единую асфальтированную дорогу", которой можно воспользоваться для быстрого решения security-проблем.

#ops

Есть очень важная вещь, которую вообще мало кто может реализовать.

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

Теперь сложное.

Чтобы этот канал связи работал, сотрудник должен быть абсолютно уверен в том, что на любое его сообщение отреагируют серьёзно и ответственно.

Во первых, что разберутся, примут меры (обязательно примут, не забьют!) и дадут какую-то обратную связь.

А во вторых, и это самое важное, даже если он сообщит о собственном косяке: вбил пароль на фишинговом сайте; словил троянца на порносайте; вставил флэшку, найденную перед входом в офис; переслал фиг знает кому документ с самой страшной тайной компании; оставил в интернете сервер, на который разрешено логиниться под root с паролем "123"...

В общем, о чём бы он ни сообщил, он должен быть уверен, что ему за это ни-че-го не бу-дет.

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

В продолжение истории про несанкционированно установленное оборудование в МВД, выложу презентацию, в которой этот сценарий был описан еще несколько лет назад, так ровно также сливали данные в NASA и у ряда других компаний

sysz - A fzf terminal UI for systemctl

https://github.com/joehillen/sysz