Пустили ботов по SSH на фейковый сервер с четырьмя H100: что они там делали Первый чужой бот пришёл через шесть минут после запуска ловушки. Она изображала Debian 12 со 128 ядрами AMD EPYC, терабайтом памяти и четырьмя NVIDIA H100. В nvidia-smi видеокарты были загружены примерно на 90%. Правда, ни одной настоящей H100 за этим не стояло. За двенадцать с половиной часов ловушка собрала 1846 подключений со 126 адресов. Одни боты просто перебирали пароли, другие заходили внутрь и вводили команды. Один возвращался 38 раз, каждый раз проверяя видеокарты. А с 59 адресов выполнялся один и тот же сценарий слово в слово. Подбор пароля был только началом. Что происходило после успешного входа, ловушка записала команду за командой.

Отличный материал: Ник Пратли 4 сентября 2026 года опубликовал полный разбор “тихого” патча MikroTik. Вот суть. Что случилось 3 сентября 2026 года MikroTik одновременно выкатил RouterOS 7.23.4 (long-term), 7.24.2 (stable) и 6.49.21 (v6) с одной и той же формулировкой: “важное обновление безопасности, детали пока не раскрываем”. Автор правильно заметил: когда ты выкладываешь пропатченный бинарник на зеркало — ты уже раскрываешь уязвимость. Diff между версиями и есть advisory. Три уязвимости 1. SSH-пользователь -2 -> полный root Самая критичная и уже активно эксплуатируемая. В RouterOS SSH-демон передаёт имя пользователя и маску прав в /nova/bin/login как позиционные аргументы. Если имя начинается с -, login воспринимает это как номер файлового дескриптора и читает из него доверенные данные. PTY (псевдотерминал) в SSH использует fd 0, 1, 2. Поэтому: • Пользователь логинится по SSH с именем -2 • Login читает данные из stderr/PTY (fd 2) • Атакующий отправляет два NUL-разделённых поля: имя и маску политики • Маска 654958 = 0x9fe6e = полные права RouterOS Автор воспроизвёл атаку в лабе: read-only сессия получала полный административный доступ. В логах RouterOS это выглядело как user ops added by ssh:-2@<адрес> — именно это видели администраторы на скомпрометированных роутерах. Ограничение: SSH должен принять имя -2 при аутентификации. Через локальную базу пользователей это не работает. Через RADIUS или User Manager — работает. Как именно атакующие в реальных инцидентах проходили этот барьер — пока неизвестно. 2. RSA-подпись без приватного ключа (forgery с e=3) В libucrypto.so функция parseHashFromDerEncoded при проверке PKCS#1 v1.5 подписи не проверяла, что после извлечённого дайджеста в буфере ничего нет. Кроме того, проверка паддинга FF FF FF... не требовала минимального количества байт — достаточно было 00 01 00. Если для аккаунта авторизован RSA-ключ с экспонентой e=3, атакующий может: 1. Взять публичный ключ (это не секрет) 2. Сформировать префикс: 00 01 00 || DER(SHA-256 DigestInfo) || хэш || мусор 3. Взять кубический корень от этого числа Кубирование при проверке восстанавливает корректный префикс, мусор в хвосте 7.23.3 игнорировал. Автор подтвердил: SSH-аутентификация без приватного ключа работала на 7.23.3, на 7.23.4 — отказ. Затронуты все потребители этой функции: SSH, IPsec/IKEv2, TLS (ssld), ACME (cloud). 3. Переполнение стека в mtget через TFTP В nova/bin/mtget при формировании TFTP-запроса имя удалённого файла копировалось в стековый буфер фиксированного размера через rep movsb без проверки длины. Команда: /tool fetch url="tftp://10.0.2.2/<длинный путь>" keep-result=no Это аутентифицированная атака, но право test входит в стандартную группу read. То есть read-only оператор может её выполнить. Автор подтвердил контролируемое перезаписывание EIP и выполнение произвольного ROP-вызова. Связанные цепочки атак Цепочка 1: известный публичный RSA e=3 -> подделка SSH-подписи -> аутентифицированный пользователь с правом test -> crafted TFTP URL -> ROP в mtget. Цепочка 2: SSH принимает имя -2 (через RADIUS/User Manager) -> PTY-инъекция политики -> полные права -> создание пользователя ops в группе full -> опционально mtget. Дополнительные исправления в 7.23.4 • www: блокировка path traversal (/../) • SSH/SCP: проверка путей при рекурсивном копировании • diskd: проверка размеров в локальном RPC • DHCP: замена небезопасных sprintf на bounded-форматирование • MAC-Telnet: закрытие скрытого API-транспорта через имя пользователя \x06/login • В nova/bin/mode добавлен детект и автоочистка следов кампании (пользователь ops, домены mythtime.xyz, leappoach.info, eeongous.com) Что делать прямо сейчас 1. Обновить до 7.23.4 / 7.24.2 / 6.49.21 или новее 2. Проверить /system/device-mode/print — если flagged: yes, роутер считать скомпрометированным 3. Найти неожиданного пользователя ops в группе full 4. Поискать в логах записи ssh:-2@<адрес> 5. Проверить scheduler на записи с fetch, /poll/<UUID> и import 6. Проверить конфигурацию RADIUS и User Manager 7. Аудит SSH RSA-ключей на предмет e=3 — заменить на Ed25519/ECDSA или RSA e=65537 8.

Оптимизация кода под космос: когда опускаются руки запускать новые спутники Представьте, что вы набираете rm -rf /home/pi/tmp/cache, а до сервера долетает rm -rf /home/pi. Привет. Именно так выглядел канал связи с орбитальным спутником, который команда RUVDS задумала как первый полноценный сервер в космосе с доступом по SSH. В сыром SSH дойти могла половина команды, поэтому весь стек протоколов пришлось переписывать. Дальше выяснилось, что настоящий SSH над горизонтом невозможен в принципе: аппарат уплывает за горизонт раньше, чем успеет обменяться ключами, а лучшее, что удавалось выжать, это около 45 байт в секунду. Пришлось откапывать протокол из контроллеров 90-х, а когда NORAD перестал давать данные о положении спутника, стучаться за орбитальной моделью в МГУ. А потом основной аппарат сгорел ровно в день, когда открывали публичный доступ.

Herdr еще один терминальный интерфейс на подобии tmux, но для кодинг-агентов Только tmux всё равно, что внутри окна, а Herdr понимает, что там агент. Так же не нужно держать ноут открытым (-_-;)・・・ , чтобы агент не умер, не надо настраивать tmux + ssh + уведомления и можно спокойно проверить агента с телефона. Каждый агент получает отдельный полноценный терминал, а не эмуляцию. Когда гоняешь несколько агентов параллельно, Herdr держит их в одном месте и показывает статус каждого, распознавая его по имени процесса и выводу терминала. Через локальный API агенты читают запущенные чаты и управляют друг другом: один запускает других, ждёт их завершения и читает результат. Можно собрать пайплайн, где агенты дирижируют агентами без тебя. - Вся архитектура создана под SSH и адаптируется под любое удаленное устройство - Есть плагины дающие бесконечно расширять функционал - Интерфейс текстовый, но всё в нём кликается мышью. Поддерживает Windows (beta), macOS и Linux. Сайт | GitHub @tips_ai #tools