Microsoft podrzucał dziurawe oprogramowanie do Linuksów w Azure
Wśród dziur naprawianych w ramach wrześniowego Łatkowego Wtorku, poza podatnością 0-day w Office, znajduje się także błąd w składniku Microsoft OMI. To mało znane narzędzie o otwartym kodzie źródłowym jest uniksową implementacją protokołu CIM oraz standardu WBEM. W praktyce oznacza to wprowadzenie do Linuksa mechanizmów zarządzania o specyfice znanej z Windows. Okazało się to groźne.
Powodem problemu nie jest sama obecność WBEM na Linuksie. Wbrew pozorom binarne interfejsy konfiguracyjne, podstawa zarządzania nowoczesnymi Windowsami, nie są z założenia złym pomysłem, który nie ma prawa się udać. Przeszczepianie ich do Linuksa nie musi kończyć się poważnymi problmemami z bezpieczeństwem. Kłopot z OMI polega na czymś innym: to obowiązkowe narzędzie do zarządzania maszynami wirtualnymi pracującymi w wielu usługach Azure.
Tajny agent
Klienci mogli zatem nie wiedzieć, że OMI znajduje się na ich platformach, a narzędzie to nie zawiera mechanizmu aktualizacji automatycznych. Przy wycenie 9.8 CVSS, podatność w OMI czyni narzędzie niezwykle niepożądanym prezentem. OMI ma otwarte źródła, ale jest słabo udokumentowane. Użytkownicy często nie wiedzą, do czego służy to narzędzie, a wydaje się ono ułatwiać pracę głównie w Redmond, a nie u klientów Azure. Ponieważ jednak kod jest otwarty, a narzędzie napisano w C, możemy podejrzeć, co tak naprawdę zostało naprawione i jaka była skala problemu.
Commit zatytułowany "Enhanced Security" dodaje szereg nowych pól do mechanizmu komunikacji, rzetelniej inicjalizuje zmienne i zmienia niektóre porównania. Poza implementacją powyższych dobrych praktyk, których brak rzadko w bezpośredni sposób wywołuje luki w bezpieczeństwie o wycenie 9.8, w commicie znajduje się tylko kilka pomniejszych zmian.
Podręcznikowy błąd
Ale za to jakich! Do kodu dodano jawne sprawdzenie tożsamości serwera, opatrzone warunkiem stopu dla niepoprawnego uwierzytelnienia. Poprawka tego typu zazwyczaj oznacza, że da się ominąć uwierzytelnianie: jeżeli nie jest jawnie sprawdzane i po prostu się nie odbędzie, nie będzie "nieprawidłowe", więc klient uwierzytelni się. To dość podstawowy błąd. Na pewno o to chodzi?
Zobacz także
Okazuje się, że... tak. Istotnie usunięcie nagłówka uwierzytelniania prowadziło do dostępu bez poświadczeń. Tak twierdzi Wiz, odkrywca dziury. To ta sama firma, która niedawno znalazła inny poważny problem w Azure.
W dobie ataków na łańcuch dostaw, polityka cichego wprowadzania agentów na maszyny wirtualne i popełnianie tak książkowych błędów w mechanizmach uwierzytelniania to nonszalancja, na którą raczej nie należy sobie pozwalać.
