Уязвимост в Linux на Canonical snapd daemon дава Root достъп
Изследовател е открил нова уязвимост, наречена “Dirty_Sock” в REST API на Canonical snapd daemon , за да позволи на атакуващите да получат root достъп на Linux машини. За да илюстрира как тези уязвимости могат да бъдат използвани, изследователят пусна на PoC, които работят с различни методи за повишаване на привилегиите.
Оттогава тази уязвимост е била поправена от Canonical, създателя на Ubuntu и Snap framework, но освен ако администраторите не инсталират snapd update, локалните потребители ще могат да получат root ниво на достъп до сървърите, изпълняващи daemon.
Изследователят по сигурността Крис Моберли, който е открил този бъг, казва, че докато го е тествал само на Ubuntu, други Linux сървъри най-вероятно ще бъдат засегнати.
“Тази грешка ще повлияе на всеки Linux, използвайки snapd. Експлоатацията може да варира. Например, dirty_sockv1 използва API за създаване на потребител. Това API всъщност използва back-end Linux команда” adduser “, която не е включена във всички дистрибуции на Linux ( някои просто имат useradd, например). Това е една от причините, поради които работих много усилено, за да получа dirty_sockv2 работа – тази версия ми позволява да включвам всеки bash скрипт, който искам, така че може да бъде много преносим.
За тези, които не са запознати със Snaps, те са приложения, разпространявани в пакети, които съдържат всички файлове, библиотеки и програми, които са необходими за изпълнението на приложението. Това улеснява дистрибуторите да разпространяват своите приложения и не трябва да се притесняват, че потребителят няма инсталирани всички предпоставящи неща за тях.
За да улесни разпространението на снимки, Canonical е създал Snapcraft магазин за приложения, който разработчиците могат да качват нови Snaps и потребителите могат да ги инсталират. За да инсталирате локални снимки и да комуникирате с магазина, в Linux се инсталира snapd daemon.
Недостатъкът в REST API води до повишаване на привилегиите
Когато анализира инсталацията на snapd в Ubuntu, Мобърли откри, че daemon използва UNIX сокети, за да позволи на разработчиците да комуникират с него, използвайки REST API.
Тъй като този сокет се изпълнява в контекста на сигурността на главния потребител, той започва да търси API методи, които могат да се възползват от тези разрешения и да повишат привилегиите му на сървъра.
При разглеждане на API, Мобърли откри, че е възможно да се създаде локален потребителски акаунт, използвайки API “POST / v2 / create-user” на демона. Тази команда за API, обаче, изисква програмата да има root разрешение или uid от 0, за да създаде потребител.
Когато анализира как snapd определя дали потребителят има права за root, той вижда, че той изгражда низ, състоящ се от повикващия pid, uid на програмата, свързана със сокета, пътя на сокета и remoteAddr. Например, компилиран низ ще изглежда по следния начин:
PID = 5127; UID = 1000; socket = /serie / snapd.socket; ‘
Всяка част от този низ се разделя на точка и запетая и се присвоява на различни променливи. Използвайки горния пример, променливата uid ще бъде настроена на 1000, а не на 0 и по този начин няма да може да изпълни командата create-user.
Мобърли обаче научи, че @ частта от низа представлява RemoteAddr на сокета или името на сокета, което се използва за свързване към snapd сокета.
Това му позволява да създаде сокет, който съдържа: uid = 0; в името си, както е показано по-долу, което след това ще замени uid, когато низът се анализира.
Когато snapd анализира низа, като uid = 0 е последната част, той ще презапише предишния uid и trick snapd с мисълта, че той се извиква от root потребителя и позволява да бъде създаден локален потребител.
Тази атака беше събрана в PoC, наречен “dirty_sockv1”, но изискваше интернет връзка и създаването на Snapcraft SSO потребител със зададен SSH ключ.
“API за създаване на потребител не ви позволява да зададете парола – само за да дефинирате SSH ключ, който е разрешен за свързване”, каза изследователят. “Затова трябва да използваме SSH с публичния ключ, за да преминем към този потребител. Това е само изискване за dirty_sockv1.”
Dirty_Sock версия 2 го прави още по-лесно
За да се отървете от SSH изискванията на функциите на API „POST / v2 / create-user“, изследователят създаде нов PoC, който отклонява злонамерено прихващане с помощта на API „POST / v2 / snaps“.
Използвайки този API, Мобърли е в състояние да прехвърли злонамерена приставка, конфигурирана с флаг “devmode”. Когато инсталацията е инсталирана, тя ще стартира скрипт, който създава нов потребител с име “dirty_sock”, който след това се добавя като Sudoer. Това му позволява да изпълнява всяка команда на сървъра като root.
След това той комбинира специалния имейл сокет свързващ трик с този злонамерен модул, за да създаде локален потребител с root привилегии. Този PoC се нарича Dirty_Sock версия 2 и вече не изисква интернет връзка или използването на SSH ключ.
Мобърли твърди, че тази грешка е била отстранена два месеца по-късно в Snapd 2.37.1 чрез използването на по-строг анализ и премахването на низа RemoteAddr, който може да бъде манипулиран от потребителя.
“Тя е поправена в 2.37.1. Те са реализирали много по-строг анализ, както и напълно премахване на контролираната от потребителя променлива от низа, който се анализира.
Изследователят ни каза също, че неговият опит с Canonical е страхотен и с удоволствие е да работят с него.
Всички продукти на Panda Security предпазват и Linux машини. Вижда се, че докато разработчиците успеят да надхитрят хакерите, минава ценно време, в което можем да станем жертва на зложелатели. Именно затова е важно стартираните процеси в компютъра да бъдат мониторирани и класифицирани в реално време.
Източник: По материали от интернет
