Уязвимост в OpenSSH, която позволява на отдалечени атакуващи да влизат в акаунти без парола в Alpine Linux и други базирани на musl системи, се експлоатира активно, предупреди компанията за разузнаване на заплахи Previdian.
Уязвимостта (CVE-2026-123158), наречена sshole от изследователя от Wakefield Йозгюн Кюлтекин (Özgün Kültekin), беше коригирана в OpenSSH 10.6p2 на 5 ноември.
„Атакуващ, който може да достигне вашия SSH порт, може да влезе, без да знае каквато и да е парола. Необходима е само една връзка, работи всеки път и не изисква повторни опити“, написа екипът на Alpine Linux в своето известие за сигурност.
В петък основателят на Previdian Раян Дюхърст разкри, че сензорите на компанията са засекли атаки срещу грешката и че поне една от тях е успяла да проникне напълно в системата.
„Първият регистриран от нас опит дойде по-малко от девет часа след публикуването на CVE и потвърдихме успешен root достъп в примамка (honeypot) на Previdian, работеща с реален Alpine Linux и OpenSSH“, сподели той пред Help Net Security.
„Засеченият IP адрес на източника, 89.116.89[.]18, е използвал прекалено дълги пароли, за да заобиколи удостоверяването, и е изпълнил разузнавателни команди, включително id, uname и hostname, чрез неинтерактивни SSH сесии“, каза Дюхърст.
Досега компанията е преброила осем опита, всички от този единствен базиран в Япония адрес и всички уловени от един сензор.
Previdian постави уязвимостта в своя собствен списък с известни експлоатирани уязвимости, докато CISA все още не я е включила в своя каталог KEV.
Според Дюхърст атакуващите стават все по-бързи с помощта на изкуствен интелект. „Тази уязвимост беше изключително тривиална за експлоатиране, което значително съкрати времевата линия.“
Един символ с две значения
Кюлтекин, който откри уязвимостта, създаде уебсайт, обясняващ проблема в неформален стил и изцяло с малки букви.
„акаунти, които изобщо не би трябвало да приемат парола (root, вашият deploy потребител само с ключове, ldap потребители, потребителят по подразбиране в образите на alpine за aws и azure), приемат всяка парола, по-дълга от 256 символа“, пише той. „да, всяка парола. да. знам. да.“
Кюлтекин проследява проблема до стари архитектурни решения, взети в OpenSSH и musl — C библиотеката, върху която е изграден Alpine. Тези акаунти съдържат „*“ на мястото на хеша на паролата в /etc/shadow.
През 2016 г., припомня той, за да се отстрани уязвимост със синхронизацията (timing issue), позволяваща на атакуващите да разберат кои потребителски имена съществуват на сървъра (CVE-2016-6210), OpenSSH променя sshd така, че да заема криптографска „сол“ (salt) от друг акаунт и въпреки това да хешира паролата, когато даден акаунт няма използваем хеш.
От 2012 г. насам функцията crypt() на musl отхвърля SHA-256 и SHA-512 пароли, по-дълги от 256 байта, и при неуспех връща „*“. Този резултат съвпада със символа „*“, съхранен за акаунта без парола, и sshd допуска потребителя в системата.
Кюлтекин компилирал sshd във всяка комбинация, за която се сетил, и изпратил около 17 600 необичайни опита за влизане към компилациите. Само компилацията с musl без PAM допуснала влизания, които е трябвало да откаже. Той обаче не го е направил сам. „о, казах ли „аз“? съжалявам. имах рояци от агенти. много от тях. нека не навлизаме в подробности“, признава той.
Кой е изложен на риск
Уязвимостта засяга версии на OpenSSH преди 10.6p2 в Linux системи, които използват C библиотеката musl и не проверяват паролите чрез PAM. Alpine Linux компилира своя пакет openssh-server по подразбиране точно по този начин, а Кюлтекин изброява OpenWrt, Buildroot и Yocto сред другите базирани на musl системи, които си струва да бъдат проверени, заедно с „много от docker образите, които сте изтеглили“.
За успешна атака е необходимо влизането с парола да бъде разрешено, което е настройката по подразбиране в OpenSSH, както и наличието на акаунт, който има само „*“ в полето си за парола, и друг локален акаунт с реален хеш на парола. Потребители, ползващи само ключове и създадени без парола, както и потребители, извлечени от директорийна услуга чрез musl-nscd, отговарят на описанието на целевия акаунт, отбелязва SOCRadar.
Акаунтът root се доставя със символ „*“ приблизително от версия Alpine 3.16 насам, въпреки че настройката по подразбиране PermitRootLogin на OpenSSH го държи недостъпен, освен ако администраторът не я е променил. „Непрекият root достъп е по-голямото притеснение“, твърдят от SOCRadar.
„в официалните образи на alpine за aws и azure това е потребителят alpine по подразбиране и той има doas без парола. така че на практика е root“, обяснява Кюлтекин. SOCRadar посочва като засегнати образите tiny-cloud във версии от 3.18.11 до 3.24.3.
Системите, изградени върху glibc (сред които Debian, Ubuntu и Fedora), конфигурациите, използващи PAM, както и Dropbear и OpenBSD са в безопасност, потвърждава изследователят.
Инсталиране на корекции за сигурност и рестартиране
OpenSSH 10.6p2 отстранява проблема, а SOCRadar съобщава, че Alpine са пуснали актуализирани пакети с корекции за сигурност за всеки клон от 3.16 до edge още същия ден. Компанията също така напомня на администраторите, че инсталирането на обновяването оставя работещия процес sshd непокътнат, така че старият изпълним файл продължава да приема връзки, докато услугата не бъде рестартирана.
Всеки, който използва базиран на musl Linux без PAM, трябва „да спре да чете и НЕЗАБАВНО да зададе PasswordAuthentication=no или да деактивира SSH за тези системи“, призова разработчикът на OpenSSH Деймиън Милър в Mastodon.
За да се засече евентуално проникване, SOCRadar препоръчва да се претърси файлът /var/log/messages за записи „Accepted password for“, съдържащи имена на акаунти, които нямат парола, като например alpine, root или потребители само с ключове, както и да се прегледа използването на doas, наскоро създадените потребители и файловете authorized_keys. Ако не може да се изключи неоторизирано влизане, машината трябва да се третира като компрометирана.
Експлойти, доказващи концепцията (PoC) за уязвимостта, вече са публикувани в GitHub, но Previdian предупреждава, че те не са проверени и могат да съдържат зловреден софтуер.