Это плашки DDR5 PMEM 300 😮

Технологический артефакт, инженерный образец энергонезависимой памяти Intel Optane PMEM в формате DDR5. Это гибрид между сверхбыстрой RAM и SSD, который не теряет данные после выключения питания. Технология должна была стереть грань между оперативной и постоянной памятью, но из-за высокой цены и слабой поддержки так и не взлетела.

Типичный 🥸 Сисадмин

Cначала ты работаешь на автоматизацию, а потом она работает... против тебя 😬

Типичный 🥸 Сисадмин

⌨️ Как один старый ключ из мануала привел к полному захвату сети

Тут Mandiant опубликовал детальный разбор атаки на CMS Sitecore. Получилась классическая история о том, как одна маленькая ошибка в документации может привести к полному фиаско. Хакеры нашли сервер с Sitecore, который торчал наружу в интернет, и воспользовались дырой в обработке ViewState (CVE-2025-53690). Суть проблемы в том, что в старых мануалах по развертыванию Sitecore (до 2017 года) лежал один и тот же демонстрационный ключ шифрования. Если админ при установке просто скопипастил конфиг из инструкции и поленился сгенерировать свой ключ, его система становилась уязвимой.

Пайплайн атаки красив. Сначала атакующий, зная этот дефолтный ключ, отправил на легитимную страницу /sitecore/blocked.aspx POST-запрос с вредоносным ViewState-объектом, получив удаленное выполнение кода. В качестве первого пейлоада использовалась малварь WEEPSTEEL, которая собрала всю информацию о системе и отправила ее атакующему, замаскировав под легитимный __VIEWSTATE ответ.

Получив доступ с правами NETWORK SERVICE, атакующий выгрузил на сервер свой тулкит, включая туннелер EARTHWORM и RAT DWAGENT. После этого он создал двух локальных админов (asp$ и sawadmin), чтобы выглядеть легитимно, сдампил SAM/SYSTEM и извлек хэши доменных админов.

После получения доступа к доменным админам, временные локальные аккаунты были удалены, и началось движение по сети. Атакующий использовал RDP для перехода на другие хосты и развернул SharpHound. Это легитимный инструмент для аудита безопасности 😬 Active Directory, который в руках атакующего превращается в навигатор по домену. С его помощью он провел полную разведку, выискивая слабые места, вроде GPO с сохраненными паролями.

Вся эта многоходовочка стала возможной из-за одной-единственной строчки, скопированной из старого мануала. В общем, RTFM - это, конечно, хорошо. Но иногда лучше сначала подумать, а потом копипастить 🎩

Типичный 🥸 Сисадмин

netcat слушает порты 😺

Типичный 🥸 Сисадмин

Пусть смеются. Зато это твой личный ДЦ, не требующий согласований с безопасниками и менеджерами. А эти люди просто завидуют свободе и контролю 😬

Типичный 🥸 Сисадмин

Обряд посвящения: первая попытка смонтировать 4U-сервер в стойку и осознание, что миллиметры имеют значение. Кто проходил, тот поймёт.

Типичный 🥸 Сисадмин

Вот почему у меня проблемы с доверием 😬

Типичный 🥸 Сисадмин

Бэкапы - это для тех, кто не верит в стабильность своего прода.

Типичный 🥸 Сисадмин

Как одна дыра в GitHub Action превратила 6700 приватных репозиториев в публичные 🤔

Тут подъехал детальный разбор недавней атаки на цепочку поставок Nx от Wiz Research. Все началось с компрометации npm-токена через уязвимый GitHub Action. Атакующий выпустил вредоносные версии пакетов Nx, которые собирали переменные окружения, npm- и GitHub-токены и публиковали их в открытых репозиториях. Затем, используя утекшие GitHub-токены, он сделал публичными более 6700 приватных репозиториев у почти 500 скомпрометированных пользователей, включая целые организации.

Вредонос проверял наличие в системе ИИ CLI-утилит (Claude, Gemini, Amazon Q) и просил их найти интересные файлы на диске. Однако эффективность этого подхода оказалась низкой. AI-инструменты были установлены только у половины жертв, а в некоторых случаев Claude просто отказывался выполнять вредоносный промпт из-за встроенных защит. В итоге, ИИ-часть атаки сработала успешно менее чем в 25% случаев.

Интересен и подход атакующего к собственной безопасности. Вместо того чтобы палить свою инфраструктуру и поднимать свой сервер, он сначала использовал webhook.site для слива данных, а затем переключился на создание публичных репозиториев на аккаунтах жертв. Это минимизирует его собственный след и не дает себя вычислить. Для доступа к скомпрометированным аккаунтам использовался TOR, а для публикации репозиториев простой Python-скрипт.

Типичный 🥸 Сисадмин

Как невнимательность к RTFM привела к появлению новой штатной единицы

Коллеги, тут подъехала история от подписчика, назовем его Денис, который в ~2012 году подрабатывал DBA на полставки.

Его контора держала две инстанции MySQL (одну в Москве, другую где-то в Новосибе). И все это на симметричной репликации, потому что отказоустойчивость. Ден сразу предупредил, что канал между городами слишком медленный и нестабильный. Но на это махнули рукой.

Однажды в московском ДЦ проводили тест (так сказали) системы аварийного электропитания. Тест, естественно, провалился. Московская база легла, и вся нагрузка полетела на сервер в Новосибе.

Когда Москва очнулась, Денису нужно было восстановить синхронизацию. Он открыл мануал и запустил REPAIR TABLE. Но забыл один маленький, но важный параметр LOCAL. А этот параметр, по иронии, был описан на второй странице мануала 😬

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

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

RTFM 🤬

Типичный 🥸 Сисадмин

Когда слетел BIOS на старой материнке X58, программатора под рукой нет, но есть малинка 🎹

Типичный 🥸 Сисадмин

Самое страшное, что ты сам добровольно построил три верхних кукловода 😬

Типичный 🥸 Сисадмин

Тимлид девопсов в отпуске

MemOps 😃

История c отлетающими SSD в Windows 11 получила продолжение. Так кто же виноват? 💩

Тут подъехала развязка детективной истории про умирающие SSD после обновления Windows 11 24H2 (KB5063878). Если помните, сначала была паника, когда японский энтузиаст заявил, что диски отваливаются, а блогеры подхватили и расфорсили, обвинив Microsoft.

И вот, кажется, нашлась разгадка. Китайская группа PC-энтузиастов PCDIY! докопалась до сути. Оказалось, что проблема возникает только на накопителях с пре-релизными, инженерными версиями прошивок. То есть, на тех самых ранних образцах, которые часто попадают к обзорщикам и энтузиастам, но никогда не доходят до розничных магазинов.

Обычные, розничные SSD поставляются уже с финальной, протестированной прошивкой, на которой этого бага нет. Именно поэтому ни Phison, ни Microsoft не смогли воспроизвести проблему в своих лабораториях. По слухам, инженеры Phison уже неофициально подтвердили эту версию.

Отдельно Phison добавила, что замедление работы дисков при копировании больших файлов не баг, а нормальное поведение при заполнении SLC-кэша. И лечится это не форматированием, а утилитой Secure Erase.

Тайна умирающих SSD раскрыта, Шindows в этот раз ни при чем 🎩

Типичный 🥸 Сисадмин