OpenSSH објави итна безбедносна исправка за ранливост што овозможува заобиколување на SSH-автентикацијата со долги лозинки на Alpine Linux

Напаѓачите можат да се најават на сметки кои немаат поставена лозинка, како што се сметките што користат исклучиво SSH-клучеви, на одредени Alpine Linux сервери на кои е инсталиран стандардниот пакет openssh-server. За нападот им е потребен мрежен пристап до серверот, име на корисничка сметка и лозинка со должина од 257 до 1.024 бајти.

OpenSSH, кој ја оценува ранливоста како критична, денес ја објави верзијата 10.6p2 со цел да го спречи нападот. Alpine објави поправени пакети за сите верзии, почнувајќи од 3.16.

Нападот функционира кога SSH-серверот (sshd) ги проверува лозинките без користење на интерфејсот Pluggable Authentication Module (PAM), кога е овозможена најава со лозинка и кога најмалку една друга сметка на системот има поставена лозинка. Пакетот openssh-server на Alpine е компајлиран без PAM, а најавувањето со лозинка е стандардно овозможено.

Ранливоста произлегува од начинот на кој sshd функционира во комбинација со musl, C-библиотеката врз која е изграден Alpine. Не се засегнати системите што не се базирани на Linux, Linux-системите што користат glibc и системите кои ги проверуваат лозинките преку PAM, соопшти Damien Miller од проектот OpenSSH.

Тој ги повика сите што користат засегнати системи веднаш да ја применат следната мерка: „поставете PasswordAuthentication=no или ВЕДНАШ оневозможете го SSH-пристапот за овие системи“. Засега не се пријавени напади што ја искористуваат оваа ранливост.

Кој е изложен на ризик?

Во своето безбедносно известување, Alpine наведува четири услови. Серверот е изложен на ризик кога се исполнети сите четири:

• Користи пакет openssh-server, кој е компајлиран без PAM, или пакет openssh-server-pam со поставена вредност UsePAM no.
• Параметарот PasswordAuthentication е поставен на yes, што е стандардна поставка во OpenSSH.
• Во полето за лозинка на некоја корисничка сметка стои *, што значи дека не е поставена лозинка.
• Најмалку една друга локална корисничка сметка има хеш од лозинка што започнува со $5$ или $6$.

На напаѓачот дополнително му е потребно името на корисничка сметка која нема поставена лозинка. Само една сметка со лозинка е доволна за да бидат изложени сите сметки без лозинка. Според безбедносното известување, нападот успева при секој обид, со само една мрежна конекција.

На Alpine, сметките без поставена лозинка вклучуваат:

• Корисници кои користат исклучиво SSH-клучеви и се креирани со командата adduser без лозинка или со usermod -p '*'.
• Корисници кои доаѓаат од сервис за директориуми преку musl-nscd, бидејќи немаат запис во датотеката shadow.
• Корисничката сметка root, која од околу верзијата Alpine 3.16 се испорачува со вредност root:* во основната системска слика.
• Корисникот alpine во официјалните cloud-слики изградени со tiny-cloud.

Root-сметката е заштитена со стандардната поставка PermitRootLogin prohibit-password и може да биде директно достапна само ако е поставено PermitRootLogin yes. Сепак, оваа заштита не помага доколку напаѓачот успее да добие пристап до сметка преку која може да добие root-привилегии, на пример преку алатката doas.

Tiny-cloud сликите од верзиите 3.18.11 до 3.24.3 му овозможуваат на корисникот alpine да користи doas без лозинка. Тие се безбедни при првото подигнување на системот, но стануваат ранливи откако на машината ќе се појави кој било хеш што започнува со $6$, на пример откако администраторот ќе постави лозинка за конзолата. Напаѓачот потоа може да се најави како alpine и да ја искористи алатката doas за да добие root-пристап.

Не се засегнати контејнерите во кои не работи sshd, системите со поставено PasswordAuthentication no и cloud-сликите конфигурирани преку cloud-init, кој ја поставува наведената вредност. Не се засегнати ниту сметките заклучени со ! во датотеката /etc/shadow, како и машините на кои ниту една сметка нема хеш на лозинка во формат што започнува со $.

Ранливоста не е ограничена само на Alpine. Özgün Kültekin од Wakefield, кој ја пријавил ранливоста, во својата техничка анализа ги наведува OpenWrt, Buildroot и Yocto како други системи базирани на musl кои треба да се проверат.

OpenWrt стандардно го користи Dropbear за SSH-пристап, како што е наведено во неговата документација за Dropbear, а Kültekin потврдува дека Dropbear не е засегнат. Кај OpenWrt, ранливоста може да претставува проблем само доколку администраторот дополнително го инсталирал OpenSSH-серверот.

Како да се отстрани ранливоста?

Кај Alpine, решението се состои од ажурирање на пакетите и рестартирање на SSH-сервисот, бидејќи надградбата на пакетот сама по себе не го рестартира веќе активниот sshd.

1. Ажурирајте ги пакетите:

apk upgrade -U -a

2. Рестартирајте го серверот:

rc-service sshd restart

Верзиите 3.21.10, 3.22.8, 3.23.8 и 3.24.4 веќе го содржат поправениот пакет. Поправки се објавени и за гранките од 3.16 до 3.21, иако тие веќе се надвор од периодот на официјална поддршка.

Cloud-инстанците стартувани од tiny-cloud слики постари од наведените верзии сè уште треба да се ажурираат или да ја применат подолу наведената безбедносна поставка.

Доколку сами го компајлирате OpenSSH, верзијата 10.6p2 ја содржи потребната исправка, како што е наведено во белешките за изданието.

Доколку засега не можете да го ажурирате системот, оневозможувањето на најавувањето со лозинка исто така го спречува нападот. Прво проверете дали најавувањето преку SSH-клуч функционира и оставете ја тековната сесија отворена сè додека не потврдите дека новото најавување е успешно.

Потоа поставете PasswordAuthentication no, проверете ја конфигурацијата со командата sshd -t и рестартирајте го sshd.

Во безбедносното известување се наведени и команди за додавање на оваа поставка во посебна конфигурациска датотека во директориумот /etc/ssh/sshd_config.d, кој стандардната конфигурација на Alpine го вчитува почнувајќи од верзијата 3.19. Тие исто така ги менуваат сите линии со параметарот PasswordAuthentication во датотеката /etc/ssh/sshd_config од yes во no, вклучително и линиите во рамките на блокот Match.

По оваа постапка, командата:

sshd -T | grep -i passwordauthentication

треба да го прикаже следниот резултат:

passwordauthentication no

Во известувањето се препорачува и проверка на датотеката /var/log/messages за записи од sshd што содржат Accepted password for, а се однесуваат на сметки без поставена лозинка, како што се alpine, root или корисници кои користат исклучиво SSH-клучеви.

Кај изложените сервери, потребно е дополнително да се провери користењето на doas, неодамна креираните кориснички сметки, датотеките и овластените SSH-клучеви (authorized keys).

„Доколку не можете со сигурност да исклучите дека дошло до неовластено најавување, третирајте ја машината како компромитирана“, се наведува во известувањето.

Зошто функционираат долгите лозинки?

Кога не се користи PAM, sshd самостојно ја проверува лозинката. Тој ја обработува внесената лозинка со функцијата crypt() од C-библиотеката, која ја претвора лозинката во хеширан облик, а потоа го споредува резултатот со зачуваната вредност.

Корисничката сметка без лозинка во ова поле ја има само вредноста *. Таа е премногу кратка за да содржи salt – случаен префикс што се користи при создавањето на хешот. Поради тоа, sshd го презема salt-от од друга корисничка сметка која има вистински хеш на лозинка.

Кај типовите хешови $5$ и $6$, функцијата crypt() во musl одбива да обработува лозинки подолги од 256 бајти и враќа * за да означи дека настанала грешка. Таа вредност * се совпаѓа со зачуваната вредност *, поради што sshd ја прифаќа најавата. Горната граница на должината е 1.024 бајти, што е ограничување на самиот sshd.

Ова однесување потекнува од промена во musl од 9 август 2012 година, со која неуспешното повикување на crypt() започнало да враќа „хеш што не може да се совпадне, наместо NULL“, бидејќи многу програми не проверувале дали функцијата завршила со грешка. Ограничувањето од 256 бајти било воведено на 29 август 2012 година, со цел да се заштитат серверите од напади со одбивање на услугата (DoS).

Преземањето на salt од друга сметка потекнува од промена во OpenSSH од 15 јули 2016 година, со која се решавала ранливоста CVE-2016-6210. Таа ранливост им овозможувала на напаѓачите да откријат кои кориснички имиња постојат на системот. Во својата анализа, Kültekin наведува дека проблемот постои уште од тогаш.

Измената на кодот во верзијата 10.6p2 го спречува sshd да прифати совпаѓање доколку зачуваното поле е пократко од четири знаци. OpenSSH ја нарекува оваа мерка привремено решение (workaround) и наведува дека вистинската причина за проблемот се наоѓа надвор од sshd. Стабилните пакети на Alpine содржат исправка за истиот проблем.

Зошто исправката беше објавена уште следниот ден?

Тимот на Miller дознал за ранливоста претходно оваа недела и ја објавил исправката во најкус можен рок.

Во објавата за изданието, тој изјавил дека тимот сега смета оти долгите периоди на ембарго за објавување информации за ранливости се опасни и главно им помагаат на напаѓачите. Причината е што во последно време забележале дека AI-агенти ги откриваат истите пропусти повторно, понекогаш во рок од само неколку часа.

До денот на објавувањето на написот, за ранливоста сè уште не бил доделен CVE-идентификатор.

Извори:

• The Hacker News – OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux The Hacker News