Podatności w Sitecore – badacze obnażają poziom bezpieczeństwa CMS dla biznesu

Po raz kolejny na naszych łamach gości watchTowr oraz znakomity Piotr Bazydło. Musimy przyznać, że w redakcji bardzo cenimy sobie techniczne writeupy okraszone uszczypliwym dowcipem. Tym razem przytaczamy bardzo dobry opis podatności w systemie zarządzania treścią (ang. content management system – CMS) Sitecore, który wykorzystywany jest głównie przez duże firmy do budowania stron internetowych. 

TLDR:

• WatchTowr po raz kolejny przedstawia analizę wybranych podatności w znanych produktach – tym razem w CMS Sitecore – systemie zarządzania treścią, wykorzystywanym przez duże korporacje. 
• Domyślne poświadczenia są proste do złamania, ponieważ składają się z pojedynczej litery b.
• W aplikacji istnieje możliwość zdalnego wykonania kodu za pomocą dobrze znanej podatności Zip Slip, która pozwala zapisać webshella w odpowiedniej lokalizacji.

Badacze odkryli, że w wersjach 10.1 – 10.4 Sitecore konfiguruje domyślne konta – np. sitecore\servicesAPI z bardzo prostymi hasłami. 

b6ba921570c83ff0fc9d51bf36e544bbfa5fafb3:9062da4353088a5dd2be1419ae310eb8:b

Poświadczenia zawierają hasło – pojedynczą literę “b”, co powoduje, że jego odzyskanie przy pomocy np. hashcata trwa ułamki sekund. Skąd tak proste hasła? Jest to zaszłość historyczna:

Historically, the default password of the default Sitecore admin user was set to b. It’s not a thing anymore, as nowadays you define your own password during the product installation.

Niestety to nie koniec złych wiadomości. Okazuje się, że korzystając z endpointu /sitecore/admin możliwe jest uzyskanie poprawnej sesji (zalogowanie się) na domyślnie skonfigurowane konto. Ponadto dokumentacja techniczna produktu, odradza wprowadzanie zmian w przypadku użytkowników tworzonych automatycznie, ponieważ mogą one rzutować na poprawne działanie CMSa. To powoduje, że trudno jest walczyć z tak powstałymi błędami w konfiguracji. 

Jak nietrudno się domyślić, posiadanie poprawnych poświadczeń do systemu znacznie poszerza możliwości ataków. Zalogowani użytkownicy mają dostęp do bogatej funkcjonalności systemu, która jest niedostępna bez poprawnej sesji. 

W przypadku Sitecore, domyślny użytkownik może wrzucać pliki na serwer. Chociaż metody sanityzacji i kontroli umieszczanych w systemie plików są całkiem rozbudowane, to jednak w bogatej liście wspieranych formatów znajdują się między innymi archiwa ZIP. Ponieważ brak jest odpowiedniej kontroli nad wypakowaną zawartością, atakujący może skorzystać z podatności ZIP Slip i zapisać pliki pod wskazaną ścieżką (jeśli dysponuje odpowiednimi uprawnieniami zapisu). W szczególności może doprowadzić do zapisu pliku do webroota aplikacji a to w efekcie (w przypadku przesłania pliku .asp) pozwoli na wykonanie kodu na serwerze aplikacji. Podatność ta otrzymała oznaczenie WT-2025-0032 (CVE-2025-34510). 

Łącząc CVE-2025-34510 z domyślnymi poświadczeniami, otrzymujemy łańcuch pozwalający na zdalne wykonanie kodu. 

W przytoczonym blogpoście opisywana jest jeszcze podatność CVE-2025-34511, która pozwala na przesłanie dowolnego typu pliku, efektywnie doprowadzając do zdalnego wykonania kodu trochę inną ścieżką. Prawda, że piękne?

Serdecznie zapraszamy do zapoznania się ze szczegółami technicznymi podatności, które zostały przybliżone na blogu WatchTowr. Chudemu gratulujemy ciekawego znaleziska i czekamy na kolejną odsłonę researchu. 

~Black Hat Logan