Архив метки: ITchaos

Я в прошлом посте про взлом Binance предполагал, что у них в инфраструктуре колхоз и адище, а сотрудники творят безответственную дичь, но реальность оказалась даже веселее

Добавить комментарий

Я в прошлом посте про взлом Binance предполагал, что у них в инфраструктуре колхоз и адище, а сотрудники творят безответственную дичь, но реальность оказалась даже веселее

Я в прошлом посте про взлом Binance предполагал, что у них в инфраструктуре колхоз и адище, а сотрудники творят безответственную дичь, но реальность оказалась даже веселее. 🙂

🔻 В сентябре 2026 года через легитимную платформу для поиска работы с инженером-программистом B связался человек, представившийся директором проекта. В профиле инженера был указан опыт работы в Binance, что, вероятно, привлекло внимание злоумышленника. Под предлогом трудоустройства он организовал два этапа собеседования с этим инженером-программистом: сначала с представителем отдела кадров, а затем с человеком, назвавшимся генеральным директором вымышленной компании.

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

Второе собеседование проходило в популярном мессенджере. Ближе к его завершению инженеру B предложили скачать на рабочий компьютер "тестовое задание", которое на самом деле представляло собой репозиторий с вредоносным кодом. Вредоносный код выполнялся в процессе настройки окружения, запуская цепочку несанкционированных действий. Для сокрытия своей активности вредоносная программа использовала сложные методы обфускации и обхода средств защиты. В частности, злоумышленники подменили компонент легитимного инструмента разработки его вредоносной версией, что позволило выполнять команды и устанавливать соединение с внешним сервером, находящимся под их контролем. На момент атаки вредоносная программа не обнаруживалась установленными на компьютере средствами защиты конечных устройств. 👍 Кроме того, злоумышленники предприняли меры по сокрытию своих действий и удалению следов компрометации, существенно осложнив обнаружение инцидента и его последующее расследование. 🙂

🔻 20 октября 2026 года злоумышленник воспользовался скомпрометированным компьютером инженера B и внутренним ИИ-инструментом, чтобы получить доступ к компьютерам инженера DevOps команды Wallet A (про этого уникума пишут, что в июне он скачал подменённый зловредный установщик Homebrew - популярного менеджера пакетов для macOS, но тогда атаку успели обнаружить 😏) и инженера-программиста команды Wallet C. Вскоре злоумышленник обнаружил, что на компьютере инженера DevOps команды Wallet A хранился токен, предоставляющий права на развёртывание контейнеров. 🤷‍♂️

🔻 29 октября с 17:15 до 19:56 злоумышленник получил доступ к компьютеру инженера-программиста C, воспользовался учётными данными, похищенными у инженера DevOps команды Wallet A, и развернул контейнер, из которого запустил вредоносный скрипт для проведения атаки. И заверте…

Какие уроки можно извлечь из этой истории?

🔹 Не запускайте непроверенный код и скрипты из сторонних репозиториев на рабочих устройствах. Особенно если речь идёт о "тестовых заданиях" от левых интервьюеров.

🔹 Не храните критичные секреты на десктопах. Ограничивайте права доступа и сроки действия токенов.

🔹 Контролируйте доступ ИИ-инструментов к данным, системам и выполнению команд.

🔹 Отслеживайте аномальную активность и несанкционированные изменения в системе.

🔹 Инвестируйте в IT и ИБ (особенно, когда миллиардами ворочаете). Не работайте с идиотами или хотя бы пытайтесь их обучать. 😉

Попался на глаза мем "объясните Управление Уязвимостями своими словами" - перевёл его в виде комикса

Добавить комментарий

Попался на глаза мем объясните Управление Уязвимостями своими словами - перевёл его в виде комикса

Попался на глаза мем "объясните Управление Уязвимостями своими словами" - перевёл его в виде комикса. В целом, типичный процесс Управления Уязвимостями в организации (с точки зрения VM-щика, естественно 🙂) - это разгребание постоянных косяков:

🔻 в работе инструментов детектирования уязвимостей (в принципе неподдерживаемое ПО и типы активов, фолсы, баги);

🔻 в качестве информации об уязвимостях (вроде эксплуатируется - но фиг знает как, где и кем; вроде эксплойт есть, но фиг знает, что конкретно он делает и при каких условиях работает);

🔻 в состоянии проверяемой инфраструктуры и понимании того, из чего она состоит, как НА САМОМ ДЕЛЕ функционирует и что в ней критично;

🔻 в безответственности формально ответственных за состояние инфраструктуры людей;

🔻 в отсутствии интереса со стороны руководства (пока не настанет полнейший карачун).

Это утомительное бесконечное бодание с аргументацией вроде "мы не будем ничего обновлять, это может нам что-то сломать" - при полном отсутствии плана тестирования, оценки рисков или конкретных шагов по устранению проблемы. 😖

И руководству следовало бы, конечно, задаваться не вопросом "Насколько мы защищены?" (здесь и сейчас), а гораздо более важным: "Понимаем ли мы, какими активами располагаем, какие риски с ними связаны, знаем ли, кто несёт за них ответственность и насколько эффективно ими управляют?" Так, чтобы Управление Уязвимостями перестало быть задачей одного несчастного технаря, практически не имеющего рычагов воздействия на решения, принимаемые в организации, и стало частью корпоративного управления…

Но это, конечно, уже что-то из области фантастики. 😅👽

ITшникам не до уязвимостей

Добавить комментарий

ITшникам не до уязвимостей

ITшникам не до уязвимостей. Мне написал подписчик, которого триггернули мои слова в посте про Vulnerability Management как порождение хаоса в IT.

"Почему есть потребность в VM-е? Потому что IT без живительной стимуляции со стороны не могут поддерживать удовлетворительный уровень безопасности инфраструктуры организации. "

Привожу его сообщение:

"У меня есть некоторый опыт работы в ИТ, включая ИБ-шные компании. ИТ нужна не живительная стимуляция со стороны, а ресурсы и нормально простроенные процессы. Я не видел ещё ни одной конторы, в которой бы подразделения ИТ не были бы тотально перегружены (из-за нехватки людей, большого количества задач или неудовлетворительной организации процессов их работы — в частности, недостаточного внимания к автоматизации IT ops.

Потому что в условиях, когда критериями является "чтобы не падало", и чтобы никто не жаловался [на сроки исполнения]", и очередь задач в десятки на одного сотрудника — совсем не до VM.

Вспоминаются слова одного руководителя ИБ-шной компании: "Смотрю я на наше ИТ, и постоянно возникает желание разгонать всех нахер, и нанять других, порасторопнее". В то время как ИТ страдала совсем не от недостатка расторопности — люди херачили днями и ночами."

Полностью согласен. Проблема не в том, что специалисты не осознают важность исправления уязвимостей, а в процессах организации. Они строятся таким образом, что ITшникам становится совсем не до уязвимостей. И не до информационной безопасности в целом. 🤷‍♂️

Vulnerability Management как порождение хаоса в IT

3 комментария

Vulnerability Management как порождение хаоса в IT

Vulnerability Management как порождение хаоса в IT. Тема очевидная и несколько избитая. Почему есть потребность в VM-е? Потому что IT без живительной стимуляции со стороны не могут поддерживать удовлетворительный уровень безопасности инфраструктуры организации. 🤷‍♂️

А как бы было хорошо: ITшники сами устанавливают регламент по обновлениям (включая экстренные обновления) и сами следят за его выполнением, сами разбираются в харденинге и внедряют его. А ИБ только периодически проводят аудиты и поражаются насколько же всё грамотно выстроено и работает как отлаженный смазанный механизм. И, со слезами умиления на глазах, закупают ITшникам всякие вкусняшки, поют соками-водами и долго трясут руки героям невидимого фронта. Нет, без шуток. Мой идеальный VM это полное отсутствие VM-а вообще, ввиду его ненужности, ведь безопасность в организации наступает сама, by design, без каких-либо избыточных костылей.

Но вот что-то в реальной жизни так решительно не получается. И чем больше масштаб организации, тем больше хаоса, адища, скверны и пагубы там образуется со временем. Возможно оттого, что цели разные. У кого-то учёт в рублях, а у кого-то в сутках. Когда в IT платят за то, чтобы просто надёжно работало, нужно быть отбитым фанатиком, чтобы ещё и по собственной инициативе постоянно обновлять своё хозяйство для исправления уязвимостей. Сложная задача становится сложной задачей со звёздочкой. И зачастую без какой-либо положительной мотивации, скорее наоборот - втыки за то, что опять что-то отъехало после обновления. И всё равно продолжать это делать. Потому, что "так надо", "так правильно". Мало таких буйных и не надолго их хватает.

Поэтому дорога одна - вниз, в адище и хаос. Из которого, после инцидентов или под воздействием регуляторной дубины, рождается то, что должно с ним как-то бороться - Vulnerability Management. Порождение по природе своей ограниченное, компромиссное и неполное. Ну а что вы хотели? От осинки не родятся апельсинки.

По определению неполная база известных уязвимостей становится отправной точкой для ещё более неполной базы уязвимостей с формализованными детектами. Детектами, которые не всегда могут достоверно найти уязвимость ввиду многообразия способов установки ПО. Затем набор продетектированных уязвимостей о большей части которых неизвестно вообще ничего подвергается анализу и приоритизации: "а ну малыш, давай, попробуй отгадай" какая из них станет трендовой завтра и через какую организацию поломают. 🙂 Чистый кайф.

И, к сожалению, ничего лучшего для борьбы с IT-хаосом пока не придумали. 🤷‍♂️