Badacze uważnie obserwują nowe krytyczne podatności w tekście Apache Commons

Badacze uważnie śledzą krytyczną, nowo ujawnioną lukę w Apache Commons Text, która umożliwia nieuwierzytelnionym atakującym zdalne wykonanie kodu na serwerach, na których działają aplikacje z zaatakowanym komponentem.

Wada (CVE-2022-42889) został przypisany do rankingu ważności 9.8 z możliwych 10.0 w skali CVSS i istnieje w wersjach 1.5 do 1.9 tekstu Apache Commons. Kod dowodowy dotyczący luki jest już dostępny, chociaż jak dotąd nie ma śladów aktywności exploita.

Dostępna zaktualizowana wersja

Fundacja oprogramowania Apache (ASF) wydał zaktualizowaną wersję oprogramowania (Apache Commons Text 1.10.0) w dniu 24 września, ale wydano doradztwo w sprawie wady dopiero w ostatni czwartek. W nim Fundacja opisała błąd jako wynikający z niepewnych wartości domyślnych, gdy tekst Apache Commons wykonuje zmienną interpolację, co w zasadzie jest procesem wyszukiwania i ocenianie wartości ciągów w kodzie które zawierają symbole zastępcze. „Począwszy od wersji 1.5 i kontynuując do 1.9, zestaw domyślnych instancji Lookup zawierał interpolatory, które mogły skutkować wykonaniem dowolnego kodu lub kontaktem ze zdalnymi serwerami” – czytamy w poradniku.

Tymczasem NIST wezwał użytkowników do uaktualnienia do Apache Commons Text 1.10.0, który powiedział: „wyłącza problematyczne interpolatory domyślnie."

ASF Apache opisuje bibliotekę Commons Text jako dodatek do standardowej obsługi tekstu Java Development Kit (JDK). Niektóre projekty 2,588 obecnie korzystają z tej biblioteki, w tym niektórych głównych, takich jak Apache Hadoop Common, Spark Project Core, Apache Velocity i Apache Commons Configuration, zgodnie z danymi w repozytorium Java Maven Central.

W dzisiejszym zaleceniu GitHub Security Lab powiedział, że tak: jeden z testerów pióra który odkrył błąd i zgłosił go zespołowi ds. bezpieczeństwa w ASF w marcu.

Badacze śledzący błąd do tej pory ostrożnie oceniali jego potencjalny wpływ. Znany badacz bezpieczeństwa Kevin Beaumont zastanawiał się w poniedziałkowym tweecie, czy luka może spowodować potencjalną sytuację w Log4shell, powołując się na niesławną lukę Log4j z końca zeszłego roku.

„Tekst Apache Commons obsługuje funkcje umożliwiające wykonanie kodu, w potencjalnie dostarczonych przez użytkownika ciągach tekstowych” — powiedział Beaumont. Ale aby go wykorzystać, atakujący musiałby znaleźć aplikacje internetowe korzystające z tej funkcji, które również akceptują dane wprowadzane przez użytkownika, powiedział. „Jeszcze nie otwieram MSPaint, chyba że ktoś może znaleźć aplikacje internetowe które korzystają z tej funkcji i pozwalają na dotarcie do niej danych wejściowych użytkownika” – napisał na Twitterze.

Dowód koncepcji pogłębia obawy

Naukowcy z firmy GreyNoise zajmującej się wywiadem zagrożeń powiedzieli Dark Reading, że firma była świadoma dostępności PoC dla CVE-2022-42889. Według nich nowa luka jest prawie identyczna z tą ogłoszoną przez ASF w lipcu 2022 r., która również była związana ze zmienną interpolacją w Commons Text. Ta luka (CVE-2022-33980) został znaleziony w konfiguracji Apache Commons i miał ten sam wskaźnik ważności, co nowa usterka.

„Jesteśmy świadomi istnienia kodu Proof-Of-Concept dla CVE-2022-42889, który może wywołać lukę w celowo podatnym i kontrolowanym środowisku” – mówią badacze GreyNoise. „Nie znamy żadnych przykładów szeroko wdrożonych rzeczywistych aplikacji wykorzystujących bibliotekę Apache Commons Text w podatnej konfiguracji, która pozwoliłaby atakującym wykorzystać tę lukę za pomocą danych kontrolowanych przez użytkownika”.

GreyNoise nadal monitoruje wszelkie dowody aktywności exploitów „w praktyce” – dodali.

Jfrog Security powiedział, że monitoruje błąd i jak dotąd wydaje się prawdopodobne, że wpływ na to będzie mniej rozpowszechniony niż Log4j. „Nowy CVE-2022-42889 w tekście Apache Commons wygląda niebezpiecznie” – powiedział JFrog w tweecie. „Wydaje się, że dotyczy to tylko aplikacji, które przekazują ciągi kontrolowane przez atakującego do-StringLookupFactory.INSTANCE.interpolatorStringLookup().lookup()”, powiedział.

Dostawca zabezpieczeń powiedział, że ludzie używający Javy w wersji 15 i nowszych powinni być bezpieczni przed wykonaniem kodu, ponieważ interpolacja skryptów nie będzie działać. Zauważono jednak, że inne potencjalne wektory wykorzystania luki — za pośrednictwem DNS i adresu URL — nadal będą działać.