Архив за месяц: Июнь 2024

Основная фича грядущего июньского релиза MaxPatrol VM 2.5 - новый сканер веб-приложений

Основная фича грядущего июньского релиза MaxPatrol VM 2.5 - новый сканер веб-приложений

Основная фича грядущего июньского релиза MaxPatrol VM 2.5 - новый сканер веб-приложений. И здесь речь не только о детектах для известных CVE уязвимостей, например, для Confluence или GitLab, которые, безусловно, очень важны для любого VM-продукта, о чём я уже писал ранее. Речь о полноценном DAST-сканере уязвимостей, с такой же функциональностью как в решениях PT BlackBox и PT AI.

Вообще вопрос о месте DAST-сканирования WEB-приложений дискуссионный. Этим нужно заниматься в рамках инфраструктурного VM-а или в рамках процессов AppSec-а? Рассмотрим аргументы.

Аргументы за AppSec:

🔻 Таргеты различаются. DAST-ом обычно сканят собственные разработки, а не чужие (коммерческие и опенсурсные) продукты. Если собственная разработка, значит AppSec.
🔻 Таски на исправление найденных уязвимостей летят в разработчиков, а не в админов. Опять же, разработка = AppSec.
🔻 Если же сканировались чужие продукты и при этом были найдены уязвимости, то по-хорошему нужно довести эту инфу до вендора и не попасть при этом под какие-нибудь юридические ограничения (анализ приложения может быть запрещён в лицензионном соглашении). Эти активности также более привычны AppSec-ам.
🔻 Одного DAST-а для полноценного анализа приложений всё равно не хватит, нужен SAST, IAST. Давайте не будем заниматься ерундой и будем анализировать приложения полноценно в рамках процессов AppSec.

Аргументы за инфраструктурный VM:

🔹 Вот сканируем мы хост и видим там веб-сервис (нашу разработку или не нашу - не суть важно). Почему бы не проверить его на ту же XSS-ку? Как-то глупо ограничивать себя только детектом CVE-шных уязвимостей. Тем более, что AppSec-и могут этот веб-сервис своими процессами вообще не покрывать, а мы может что-то массовыми сканами и продетектим.
🔹 Вот выстроили мы в рамках инфраструктурного VM-а процесс по поиску и исправлению известных уязвимостей. Почему бы не переиспользовать его и для web-уязвимостей? И там уязвимости, и там уязвимости. Удобно ведь будет работать со всеми уязвимостями в рамках одной единой системы, разве нет? 😏

В общем, есть аргументы у обеих сторон. В реальных организациях скорее это зависит от развития AppSec и VM отделов, кто кого подомнёт. 🙂 Моё мнение, что сканить веб-приложения DAST-ом должны и AppSec-и, и инфраструктурные VM-щики. Хуже не будет. А база для хранения продетектированных уязвимостей должна быть у них, в идеале, единой.

Но как бы ни выглядел итоговый процесс, его можно будет реализовать с помощью продуктов Positive Technologies. 😉

➡️ Более подробно о фичах нового MaxPatrol VM 2.5, включая сканирование веб-приложений, можно будет узнать на вебинаре 13 июня в 14:00. Регистрируйтесь!

3 года общего режима за нейтрализацию средств защиты компьютерной информации ЗОКИИ

3 года общего режима за нейтрализацию средств защиты компьютерной информации ЗОКИИ

3 года общего режима за нейтрализацию средств защиты компьютерной информации ЗОКИИ. Частенько сталкиваюсь с позицией людей неИБшников, что обход требований и средств ИБ в организации это, в целом, нормальная практика и ничего зазорного в этом нет. Если есть права администратора на десктопе, то чего бы, допустим, не грохнуть агент DLP или EDR? А то ж работать мешает. 😏 Раз ИБшники активно не воспрепятствовали такому, значит они сами и виноваты.

В связи с этим в новостях пролетело интересное уголовное дело. Инженеру предприятия ВПК дали реальные 3 года общего режима по 274.1 УК РФ "Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации".

Цитата того, что он сделал:

"Установлено, что инженер, находясь по месту работы, имея умысел на копирование с целью дальнейшей модификации информации о ходе технологического процесса изготовления изделий на предприятии, нейтрализовал средство защиты компьютерной информации программно-технического комплекса, являющегося значимым объектом критической информационной инфраструктуры РФ"

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

Нафантазировать себе можно, например, следующее. В некоторой организации с некоторыми файлами можно работать только на некоторых десктопах. Копирование файлов с этих десктопов на флешку блокируются СЗИ. А некоторому инженеру очень нужно было скопировать и отредактировать какой-то файл на другом десктопе. Возможно, что никакой зловредной цели у него при этом не было. Возможно, что он наоборот всей душой радел за общее дело и хотел как лучше. Где-то что-то почитал про то, как и чем блокируется копирование на флешку, как это обходить. Поэкспериментировал - получилось, скопировал! Возможно даже сам похвастался кому-то на радостях. И заверте… 😱

Мораль? Не нарушайте требований ИБ в организации. Даже если глубоко презирайте ИБшников и считаете, что всё что они делают - мешают вам выполнять настоящую важную работу. Даже если вам неудобно. Неудобно? Жалуйтесь начальству! В крайнем случае увольняйтесь. Но никогда и ни в коем случае не делайте что-то втихаря. Это может очень плохо закончиться лично для вас. Особенно, если имеете дело с КИИ и ЗОКИИ.

Если у вас есть такие умники-нигилисты в знакомых, пошарьте им этот кейс. Возможно убережёте от беды.

Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) добавили в CISA KEV

Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) добавили в CISA KEV

Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) добавили в CISA KEV. Сама уязвимость относительно старая, январская. Я уже писал про неё в марте, когда вышел write-up и публичный эксплоит.

Несмотря на тривиальную эксплуатацию, запустил утилиту - получил рута, до недавнего времени признаков активной эксплуатации этой уязвимости не фиксировали. Что довольно странно, такой полезный эксплоит должен сразу попадать в инструментарий злоумышленников. Тут либо практическая эксплуатация всё же чем-то осложнена, либо использующие её злоумышленники не оставляли следов. 🤔

Как бы то ни было, 30 мая уязвимость добавили в CISA KEV, а значит факт использования её в атаках всё-таки был установлен. Но подробностей по атакам пока нет. Обратите внимание на эту уязвимость при обновлении Linux хостов.

Поздравляю бывших коллег с долгожданным ребрендингом! 🎉

Поздравляю бывших коллег с долгожданным ребрендингом! 🎉

Поздравляю бывших коллег с долгожданным ребрендингом! 🎉 Больше двух лет история длилась.

Я, правда, поначалу предполагал, что имя сократят до "Тин". Так бы сохранилось неофициальное "Тинёк". Кроме того, т.к. "tin" это "жестяная банка", то получилась бы забавная игра слов. 🙂

Но Т - тоже хорошо. 💛

PS: Если Райффайзен всё-таки ребрендируют в R Банк, получится иронично. 😅

11 июня в 11:00 пройдёт вебинар К2 Кибербезопасность «Миссия выполнима: как эффективно защитить КИИ»

11 июня в 11:00 пройдёт вебинар К2 Кибербезопасность «Миссия выполнима: как эффективно защитить КИИ»

11 июня в 11:00 пройдёт вебинар К2 Кибербезопасность «Миссия выполнима: как эффективно защитить КИИ».

О чем будут рассказывать:

👾 Актуальные угрозы для субъектов КИИ
🗿 Какие подводные камни могут возникнуть в ходе работ
🏃‍♂️ Грамотный выбор продуктов ускоряет реализацию проекта
🕵️‍♀️ На что стоит обратить внимание при выборе подрядчика.

Там будет не столько про «бумажную безопасность» (хотя куда ж мы без регуляторики и ответственности за невыполнение требований 😏), сколько про реальную защиту промышленных и бизнес-процессов.

Учитывая, что на иллюстрации еще и «уязвимости» есть, надеюсь, что особенностей Vulnerability Management-а для КИИ также коснутся. 😉

Выступать будет Егор Куликов, руководитель направления безопасности КИИ и АСУ ТП компании К2 Кибербезопасность.

➡️ Подробности и регистрации здесь.

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

Хакатон MaxPatrol VM, часть 1: Linux стенд и Ansible

Хакатон MaxPatrol VM, часть 1: Linux стенд и Ansible

Хакатон MaxPatrol VM, часть 1: Linux стенд и Ansible. Как и обещал, делюсь впечатлениями от хакатона. Первым заданием у меня была автоматизации установки софта из TAR-архива на Debian 12 с помощью Ansible. Раньше я с Ansible толком не работал, поэтому появился повод немного разобраться.

Ansible - система управления конфигурациями, написанная на Python. Главное отличие Ansible от аналогов - не нужна установка агента или клиента на управляемые хосты. Обычно используется для управления Linux-хостами, но Windows также поддерживается. Взаимодействие происходит по модели push: сам Ansible запускается на "центральном" управляющем хосте, ходит на управляемые хосты и что-то делает. На управляемом хосте должен быть установлен Python версии 2.4 и выше, соединение выполняется по SSH или WinRM.

Управляющим хостом для Ansible будет мой десктоп на Ubuntu 23.10, а управляемым хостом будет виртуалка в VirtualBox.

Я завёл виртуалку в VirtualBox с Debian 12, добавил интерфейс Host-only adapter, чтобы можно было подключаться к ней по SSH. Я проверил, что подключение работает с помощью:

$ ssh vmuser@192.168.56.104

Для работы Ansible должна быть настроена аутентификация по ключам. Я сгенерировал ключ с помощью:

$ ssh-keygen -t ed25519 -C "alexander@avleonov.com"

Затем я закинул его на target-host:

$ ssh-copy-id vmuser@192.168.56.104

После этого команда уже не требовала пароль.

На десктоп с Ubuntu 23.10 я поставил Ansible при помощи утилиты pipx

$ sudo apt-get install pipx
$ pipx install --include-deps ansible

Обновлять можно с помощью:

$ pipx upgrade --include-injected ansible

Проверить версию ansible можно с помощью:

$ ansible --version
ansible [core 2.16.7]
...

Далее описываю управляемый хост (виртуалку) в yaml файле:

$ cat hosts.yaml 
myhosts:
hosts:
debian12:
ansible_host: 192.168.56.104

Валидирую файл hosts.yaml:

$ ansible-inventory -i hosts.yaml --list
{
"_meta": {
"hostvars": {
"debian12": {
"ansible_host": "192.168.56.104"
}
}
},
"all": {
"children": [
"ungrouped",
"myhosts"
]
},
"myhosts": {
"hosts": [
"debian12"
]
}
}

Проверяю соединение:

$ ansible myhosts -m ping -i hosts.yaml -u vmuser
debian12 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}

Всё работает, связь есть. Теперь можно попробовать выполнить какие-то команды на хосте с помощью Ansible. Делаю тестовый плейбук для вывода hostname и версии дистрибутива:

- name: Print Hostname and OS Version
hosts: all
tasks:
- name: Get Hostname
command: hostname
register: hostname_output

- name: Get OS Version
ansible.builtin.shell: lsb_release -a | grep "Description:" | awk -F"\t" '{print $2}'
register: os_version_output

- name: Display Outputs
debug:
msg: "Hostname is {{ hostname_output.stdout }} and OS Version is {{ os_version_output.stdout }}"

Запускаю его:

$ ansible-playbook -i hosts.yaml -u 'vmuser' playbook.yaml
...

TASK [Display Outputs] *********************************************************
ok: [debian12] => {
"msg": "Hostname is debian and OS Version is Debian GNU/Linux 12 (bookworm)"
}

Работает! В следующей части рассмотрим как описать в плейбуке установку софта из TAR-архива.

Периодически ко мне в личку приходят с просьбой порекламить в канале ИБ-шные оффлайн-мероприятия "от community для community" и я им обычно отказываю

Периодически ко мне в личку приходят с просьбой порекламить в канале ИБ-шные оффлайн-мероприятия от community для community и я им обычно отказываю

Периодически ко мне в личку приходят с просьбой порекламить в канале ИБ-шные оффлайн-мероприятия "от community для community" и я им обычно отказываю. И советую проводить подобные мероприятия исключительно официально от какой-то компании/организации с репутацией или хотя бы от известного лица.

Если конкретного организатора нет или это ноунейм (обычно симпатичная девушка 👩‍🦱), а вся коммуникация происходит в телеграм-чатах/ботах, то велики риски, что всё это некоторая зловредная активность третьей стороны. В лучшем случае просто соберут участников мероприятия для дальнейшей разработки или попробуют подсунуть зловред под видом программы мероприятия/схемы проезда. А хуже и в оффлайне может быть до бесконечности, времена сейчас неспокойные, трагичные кейсы сами вспомните.

ИБ-шник, бди! Не забывай, что конкретно ты одна из самых лакомых целей злоумышленников, целящих в твоего работодателя. Не ходи на мутные сходочки и не рекламируй их (не подставляй аудиторию)!