👩‍💻 Kubenomicon.

• Интересный проект в стиле MITRE ATTACK для Kubernetes, который ориентирован на наступательную безопасность. С акцентом на то, как использовать каждую атаку.

• Initial access:
➡Using cloud credentials;
➡Compromised image In registry;
➡Kubeconfig file;
➡Application vulnerability;
➡Exposed sensitive interfaces;
➡SSH server running inside container.

• Execution:
➡Exec inside container;
➡New container;
➡Application exploit (RCE);
➡Sidecar injection.

• Persistence:
➡Backdoor container;
➡Writable hostPath mount;
➡Kubernetes cronjob;
➡Malicious admission controller;
➡Container service account;
➡Static pods.

• Privilege escalation:
➡Privileged container;
➡Cluster-admin binding;
➡hostPath mount;
➡Access cloud resources.

• Defense evasion:
➡Clear container logs;
➡Delete events;
➡Pod name similarity;
➡Connect from proxy server.

• Credential access:
➡List K8S secrets;
➡Access node information;
➡Container service account;
➡Application credentials in configuration files;
➡Access managed identity credentials;
➡Malicious admission controller.

• Discovery:
➡Access Kubernetes API server;
➡Access Kubelet API;
➡Network mapping;
➡Exposed sensitive interfaces;
➡Instance Metadata API.

• Lateral movement:
➡Access cloud resources;
➡Container service account;
➡Cluster internal networking;
➡Application credentials in configuration files;
➡Writable hostPath mount;
➡CoreDNS poisoning;
➡ARP poisoning and IP spoofing.

• Collection:
➡Images from a private registry;
➡Collecting data from pod.

• Impact:
➡Data destruction;
➡Resource hijacking;
➡Denial of service.

• Fundamentals:
➡Nodes;
➡Services;
➡etcd;
➡RBAC;
➡Kubelet;
➡Namespaces;
➡Secrets;
➡Interesting Files.

S.E. ▪️ infosec.work ▪️ VT

👨‍💻 Киберкухня: разбор современных киберугроз и практические рецепты безопасности.

• Мир кибербезопасности стремительно меняется: атаки становятся быстрее, сложнее и разрушительнее. Сегодня злоумышленники все чаще нацелены не только на кражу информации, но и на полную остановку процессов компании - от блокировки систем до уничтожения критически важных данных.

• При этом серьезные инциденты чаще всего начинаются с простых вещей: сотрудник переходит по фишинговым ссылкам, игнорирует 2FA и использует слабые пароли. Именно поэтому защита компании больше не может строиться только на технологиях - она требует готовности процессов и повышения осведомленности персонала об ИБ-угрозах!

• Так вот, это я к тому, что 7 апреля у F6, Контур.Эгиды и Staffcop пройдет бесплатный вебинар, где будут обсуждать тему социальной инженерии, расскажут о новых схемах мошенничества и обсудят реальные кейсы атак на компании.

➡ Зарегистрироваться можно по ссылке.

S.E. ▪️ infosec.work ▪️ VT

• Забавная и интересная история от программиста Предрага Груевского: много лет назад, будучи студентом, он приехал на каникулы к родителям. Отец пожаловался, что с домашним интернетом происходят странные вещи: большую часть времени потери пакетов достигали 98%, но стоило пойти дождю, как Wi-Fi начинал работать стабильно.

• Ранее отец программиста настроил Wi-Fi-мост с направленными антеннами между домом и своим офисом, находившимся в двух кварталах (но в прямой видимости). Так он обеспечивал семью высокоскоростным корпоративным интернетом.

• Система проработала безупречно почти десять лет, пока на соседнем участке не выросло большое дерево с раскидистыми ветвями. Когда дерево стало достаточно высоким, оно начало блокировать радиосигнал.

• Однако во время дождя капли тянули вниз ветки и листву, и сигнал снова проходил беспрепятственно. Нет, Груевский не вырубил дерево, но поменял антенны, поддерживающие стандарт 802.11g, на 802.11n. Технология формирования луча (beamforming), в том числе позволила фокусировать Wi-Fi-сигнал в нужном направлении, и связь стала стабильной.

• Кстати, читатели, которые обсуждали эту историю, нашли интересным тот факт, что инженер первым делом не проверил возможное наличие препятствий на пути сигнала, учтивая, что в его сети имелся LOS-компонент. Впрочем, как часто бывает, очевидное решение приходит в голову последним. Также участники обсуждения поделились похожими "магическими" историями. Один из комментаторов рассказал, как связь между офисом его компании и ретрансляционной вышкой каждую ночь прерывалась ровно на десять минут. Причиной неполадки были новые натриевые газоразрядные лампы наружного освещения - во время включения они генерировали радиочастотные помехи в диапазоне 5 ГГц. Проблему решили заменой освещения на менее "шумное". Такая вот история...

➡ https://predr.ag/blog/wifi

S.E. ▪️ infosec.work ▪️ VT

💻 BSOD.

• Как думаете, почему "синий экран смерти" в Windows имеет именно такую цветовую палитру (белый текст на синем фоне)? Ответ на данный вопрос весьма прост. Дело в том, что Джон Верт (создатель BSOD) выбрал комбинацию белого текста на синем фоне по одной простой причине - ему просто так было удобно. Так и пошло...

• В то время Джон использовал машину на базе MIPS RISC, где использовалась именно такая цветовая палитра - белый текст на синем фоне. Более того, его любимый редактор кода, SlickEdit, тоже по умолчанию отображал все белым на синем. Получилась идеальная, хоть и непреднамеренная, унификация. Можно было загружаться, писать код и наблюдать падение ОС в одной и той же привычной глазу цветовой гамме.

• Кстати, многие думают, что "синий экран смерти" появился вместе с самой Windows. Но это не так. Да и синим он был не всегда. Пользователи самой первой версии Windows могли увидеть синий экран с ошибкой, но это было совсем не то явление, к которому мы привыкли. Вместо внятного сообщения был лишь лишь хаотичный набор символов, появлявшихся, предположительно, из ОЗУ, после чего все зависало и помогала лишь перезагрузка.

• С выходом Windows 3.0 ситуация немного изменилась. Появились сообщения об ошибках на синем фоне, но, это могли быть и не фатальные ошибки - скорее уведомления, после которого можно было продолжить работу. А вот по-настоящему серьезный сбой приводил к появлению "черного экрана смерти" (Black Screen of Death) с текстом вроде: "Не удается продолжить работу Windows из-за…".

• Точно сказать, кто первый произнёс фразу "Blue Screen of Death", уже сложно. Согласно архивам, термин "Black Screen of Death" впервые можно увидеть в журнале Computerworld за 1993 год (на скриншоте), а первое задокументированное упоминание "Blue Screen of Death" - в 1995 году. Тем не менее, к концу 90-х это выражение уже прочно вошло в лексикон всех, кто имел дело с ПК.

S.E. ▪️ infosec.work ▪️ VT

🔑 Зачем ПК запирали на ключ?

• В начале 80-х, когда IBM PC начали распространяться по офисам и домам, концепция компьютерной безопасности кардинально отличалась от современной. Системы того времени, как правило, не предусматривали никаких встроенных механизмов защиты данных. Каждый, кто имел физический доступ к машине, автоматически получал контроль над всей информацией.

• Ситуация усугублялась тем, что многие профессиональные задачи уже тогда требовали длительного времени выполнения. Инженер, оставивший на ночь расчет сложной модели, или программист, компилирующий объемный проект, рисковали обнаружить утром прерванный процесс - достаточно было любопытному коллеге случайно нажать любую клавишу.

• Именно в этот момент появился скромный, но эффективный механизм - замок на панели системного блока. Впервые появившись на машинах от IBM, этот элемент быстро перекочевал на другие компьютеры.

• Принцип работы был до гениальности прост. Поворот ключа физически разрывал цепь, отвечающую за работу клавиатурного контроллера. В результате все попытки ввода просто игнорировались системой - своеобразный аналог современной комбинации Win+L, но реализованный на аппаратном уровне.

• Нередко такие замки блокировали не только ввод с клавиатуры, но и процесс загрузки. В таких моделях попытка включить заблокированный компьютер приводила к появлению на экране ошибки "302-System Unit Keylock is Locked". А в ряде случаев, например, в IBM PC AT, ключом можно было и вовсе закрыть сам корпус компьютера. Такие вот были времена...

S.E. ▪️ infosec.work ▪️ VT

👩‍💻 Kubernetes Security.

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

• Проект называет Simulator. С его помощью мы можем развернуть готовый кластер Kubernetes, запустить сценарии, которые неправильно настраивают его или делают его уязвимым, и обучает устранению этих уязвимостей в формате CTF. Есть разные уровни сложности, так что решение подойдет как новичкам, так и опытным специалистам.

• Вся необходимая информация по установке и более детальное описание есть на GitHub: https://github.com/controlplaneio/simulator

S.E. ▪️ infosec.work ▪️ VT

💬 true story...

• Есть забавная история от одного инженера, который в 1980-х работал в Storage Technology, занимавшейся разработкой аппаратного обеспечения для хранения данных (ленточных накопителей в частности). К слову, эта история является очень старой, но до сих пор известна в интернете под заголовком: «Лучшая история отладки, которую я когда-либо слышал».

• Одна крупная компания, использовавшая ленточные накопители Storage Technology, столкнулась с загадочной проблемой во время обработки и печати данных. Оборудование сбоило во время многочасовых сессий, и техники не могли повторить ошибку в тестовых условиях. Специалисты даже заменили часть компонентов, но это не помогло решить проблему. Тогда они пригласили человека, которого автор называет «экспертом с большой буквы» (The Expert).

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

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

➡ https://patrickthomson.tumblr.com/

S.E. ▪️ infosec.work ▪️ VT