Poważna luka bezpieczeństwa we wtyczce W3 Total Cache

W3 Total Cache

W serwisie SecuPress pojawiła się informacja o luce bezpieczeństwa w popularnej wtyczce W3 Total Cache. Luka ta umożliwia wykonanie ataku XSS (Cross-site scripting) w panelu administracyjnym. Problem jest o tyle poważny, że z rozszerzenia tego aktywnie korzysta grubo ponad milion stron (dokładnych danych oczywiście brak), a autor nie wydaje się być zainteresowany dalszym rozwojem wtyczki.

Mimo że luki tej nie należy lekceważyć, to szum, jaki został wokół niej wywołany, ma nieco kontrowersyjne podłoże.

Aktualizacja 26.09.2016: pojawiła się wersja 0.9.5 wtyczki, która poprawia między innymi opisywany we wpisie błąd.

Drobny błąd, którego poprawienie zajęłoby średnio rozgarniętemu programiście jakieś 2 minuty, został zgłoszony autorowi przez firmę Klikki Oy ponad 4 miesiące temu i do tej pory nie doczekał się łatki.

21 września na blogu Zerial pojawił się dość szczegółowy opis luki, a dwa dni później blog SecurePress opublikował wspomniany wcześniej wpis, napisany w dość przerażającym tonie i straszący użytkowników W3 Total Cache zagrożeniami związanymi z tą luką. Absolutnie nie lekceważąc powagi sytuacji trzeba wspomnieć, że właścicielem tego bloga jest firma WP Media, której głównym źródłem dochodu jest wtyczka WP Rocket, będąca bezpośrednią konkurencją dla W3 Total Cache. Może jestem przewrażliwiony, ale dla mnie nie wygląda to dobrze…

Jak atakujący może wykorzystać tę lukę?

Korzystając z tej luki można „wstrzyknąć” własny kod JavaScript, który może na przykład wykraść informacje, za pomocą których (teoretycznie) atakujący będzie mógł zalogować się na konto administratora.

„Problem” w tym, że aby wykorzystać tę lukę atakujący musi zmusić osobę zalogowaną do panelu administracyjnego z uprawnieniami administratora (a konkretnie z zezwoleniem manage_options) do użycia odpowiednio spreparowanego linku. Jest to trudne, ale nie niemożliwe.

Korzystam z W3 Total Cache – co mam zrobić?

W momencie pisania tego wpisu poprawka wspomnianego błędu nie była jeszcze dostępna.

Jeśli korzystamy z wtyczki W3 Total Cache i chcemy być pewni, że nikt nie podsunie nam linku ze złośliwym kodem, możemy zastosować jedno z następujących rozwiązań:

  • wyłączyć (a najlepiej całkowicie usunąć) wtyczkę z serwera i poczekać na wydanie wersji z poprawionym błędem uaktualnić wtyczkę do wersji 0.9.5, która jest pozbawiona opisywanego błędu,
  • samodzielnie poprawić błąd (odpowiednią poprawkę można znaleźć tutaj),
  • skorzystać z jednej z alternatywnych wtyczek (na przykład WP Super Cache),
  • skorzystać z alternatywnej wersji W3 Total Cache, nazwanej Fix W3TC, w której ten błąd został poprawiony; niestety, trzeba ją pobrać i zainstalować „ręcznie”, bo nie ma jej w oficjalnym repozytorium wtyczek,
  • po zakończeniu pracy w panelu administracyjnym zawsze wylogowywać się lub używać konta bez uprawnień administratora.
Bezpośredni link

  • Zawsze byłem przeciw tym cache-kombajnom. Masa z nimi problemów, przeciętny zjadacz chleba nie ma pojęcia jak je odpowiednio ustawić i nie trzeba daleko szukać na forach WP, żeby znaleźć dziesiątki postów, w których są problemy bezpośrednio związane właśnie ze starym cachem, który nie może się usunąć albo po prostu użytkownik nie wie, że powinien sam go wcześniej usunąć.

    Dwa – jeśli ktoś polega na tak dużych wtyczkach i pewnego dnia po prostu autor przestanie ją aktualizować, to użytkownik jest de facto w dupie. Owszem, może szukać alternatyw(których nie brakuje) ale alternatywy mają to do siebie, że nie zawsze posiadają wszystkie funkcje pierwowzoru.

    Osobiście jestem za korzystaniem z lżejszych zasad keszowania wpisywanych ręcznie bezpośrednio do .htaccess, tym samym mając bezpośrednią kontrolę i wykupieniu odpowiedniego serwera, bo jeśli płacimy za jakąś opcję 15zł/rok i myślimy, że resztę wyciągniemy stosując keszowanie w każdej możliwej funkcji, to możemy się grubo przejechać. Trochę skrajne podejście i właściwie odejście od tematu związanego z postem ale po ujrzeniu problemu na taką skalę związanego właśnie z jednym, z najpopularniejszych keszkombajnów nie mogłem się powstrzymać.

    Nie mniej dobrze, że informujesz ludzi co mogą zrobić, jeśli korzystają z tej wtyczki.

    • W3 Total Cache swoją siłę pokazuje tak naprawdę dopiero na VPSach i serwerach dedykowanych. Używanie go na hostingu współdzielonym mija się z celem, a czasem nawet spowalnia stronę.

      Nagrania z WordCampa zawsze pojawiają się z dużym opóźnieniem – zapytaj organizatorów kiedy mają w planach ich udostępnienie.

      • W3 Total Cache swoją siłę pokazuje tak naprawdę dopiero na VPSach i serwerach dedykowanych. Używanie go na hostingu współdzielonym mija się z celem, a czasem nawet spowalnia stronę.

        Temu akurat nie zaprzeczę. Miałem niedawno okazję spojrzeć na serwis postawiony na naprawdę mocnym VPSie, który był całkiem nieźle zoptymalizowany i w zasadzie miał opcję albo właśnie jechać na takim kombajnie albo przejść na dedyka, ponieważ ruch był naprawdę ogromny i spora część wejść to były UV. Finansowo pomiędzy VPSem(nawet dobrym), a dedykiem różnica jest ogromna, więc wybór był oczywisty.

        Przeciwko jestem właśnie dlatego, że często wciska się tę wtyczkę użytkownikom serwerów współdzielonych, którzy nie mają pojęcia jak ją prawidłowo ustawić. Wtedy taki właściciel bloga z max. 100 unikalnymi wejściami dziennie dzierży dumnie keszowy kombajn i zalewa forum wp zapytaniami czemu nie widzi zmian na stronie, które wprowadza(to oczywiście tylko jeden z przykładów). Problemem często jest to, że support hostingów zaleca korzystanie z tych wtyczek, podczas gdy najczęściej wystarczy zwykła optymalizacja.

        • Paweł Knapek

          Ale to nie wina wtyczki, tylko nierozgarniętych użytkowników, czy januszy internetu.
          W3TC jest dobrą wtyczka gdy jest w dobrych rękach tj. kogoś, kto wie jak ją skonfigurować i wie czy można i czy warto jej użyć. Czasem po prostu nie można/nie warto, bo środowisko nie pozwala i efekt będzie mizerny albo nawet odwrotny do zamierzonego …są jednak dużo lżejsze alternatywy z których można skorzystać – ale zasady pozostają te same.
          Tak, najważniejsza jest optymalizacja, a cache dopiero na samym końcu. Niektórzy zapominają o optymalizacji, inni próbują jej brak maskować użyciem cache. No i ci „ignoranci”, którzy po prostu tylko coś instalują bo podobno jest dobre i inni polecają.
          Tyle, że do przeprowadzenia optymalizacji potrzebna jest znowu wiedza i umiejętności ;p
          Nie, samym tylko .htaccess’em wszystkiego nie załatwisz – trochę czym innym jest kesz przeglądarki, a czym innym po stronie serwera.

          • Nie, samym tylko .htaccess’em wszystkiego nie załatwisz – trochę czym innym jest kesz przeglądarki, a czym innym po stronie serwera.

            Zgadza się, natomiast do prostych stron wystarczy dopisanie tych kilku zasad keszowania dla przeglądarki, opcjonalnie gzip itd. – przynajmniej z takiego założenia wychodzę. Instalacja tak potężnych wtyczek dla pomniejszych stron to gaszenie świecy gaśnicą.

            Co do reszty – pewnie masz i rację ale sami autorzy mogliby również okazjonalnie wyjść z inicjatywą doinformowania użytkowników w pierwszych akapitach opisu przykładowo na stronie W3 Total Cache nie ma ani słowa o tym, że nie zawsze jest to rozwiązanie(oczywiście należałoby to jakoś zgrabniej ubrać w słowa). Nie wszyscy to czytają ale może powoli zwiększałoby to świadomość wśród samouków i osobników zainteresowanych tym, co faktycznie oferuje dana wtyczka(poza opiniami osób trzecich).

            Nie będę się spierać, że moja ideologia jest prawidłowa – po prostu przez lata wyrobiłem sobie niechęć do tych kombajnów z różnych powodów i tak mi zostało :)

    • @Nikodemsky:disqus
      Jednego nie jestem pewien, czy ty jesteś w ogóle przeciw korzystaniu z cache na współdzielonych hostingach. Czy tylko przeciw kombajnom cache typu W3TC?

      Bo z tego co mi się wydaje, to nawet dla tych 100 UU/dziennie opłaca się serwować treść statyczną, jeśli faktycznie na stronie treść nie zmienia się co chwilę. Oczywiście, w takim przypadku, nie ma sensu wyciągać armaty pokroju W3TC, ale spokojnie jakiego CKM’a.

      • Napisałem poniżej w odpowiedzi na komentarz Bartka.

        Ponadto nie jestem ogólnie przeciwko serwowaniu treści statycznej, tylko wpychaniu keszkombajnów, kiedy nie są one w ogóle potrzebne, ani nawet opcjonalne w danym przypadku. To tyczy się wielu innych wtyczek z różnych kategorii użytkowania ale chyba z tymi, które zarządzają cache’m problem jest największy.

  • Paweł Knapek

    No i wyszła poprawiona wersja 0.9.5 z pokaźną liczbą zmian w changelogu https://wordpress.org/plugins/w3-total-cache/changelog/. Na minus – coś chyba poszło nie tak, bo potrafi uwalić stronę.

  • Tomasz Kurzydłowski

    Witam, Nie znam się na konfiguracji wtyczki W3 Total Cache. Używam jej od kilku lat, skonfigurowałem zgodnie z jakimś tutorialem. I przez ten okres czasu wszystko było dobrze. Dzisiaj zainstalowałem nową wersję i spowodowało to kilka błędów z moim motywem Avada:
    – zniknęły na bocznym pasku komentarze i najpopularniejsze posty
    – pod wpisami zniknęły propozycje podobnych postów
    – menu w wersji mobilnej przestało działać (!)

    Wtyczkę wyłączyłem i to, co zniknęło, już działa. Poczekam, może pojawi się kolejna wersja i ponownie uruchomię wtyczkę.

    Nie znam się na kwestiach technicznych i wtyczki do optymalizacji na Wordpressie instaluję jak gdzieś przeczytam, że przydatna. Mam kilka i najchętniej bym je wszystkie wyłączył:
    – W3 Total Cache
    – cbnet Ping Optimizer
    – WP Debugger
    – WP Super Minify
    – WP-Optimize (ta akurat bardzo pomocna w usuwaniu kolejnych wersji wpisów a może jest inny sposób?)

    Czy szanowni koledzy mogliby podpowiedzieć co jest niepotrzebne?
    Pozdrawiam,

    • Podałeś trochę za mało informacji. Przede wszystkim nie napisałeś, na jakim serwerze stoi Twoja strona (hosting współdzielony, VPS, serwer dedykowany) i z których funcji W3TC korzystasz. Może się okazać, że tak naprawdę nie potrzebujesz W3TC.

      WP Debugger – nie wiem po co Ci ta wtyczka; ja bym ją usunął, szczególnie, że nie jest aktualizowana od ponad 2 lat
      WP Super Minify – analogiczną funkcję ma W3TC
      cbnet Ping Optimizer – kolejny staroć sprzed grubo ponad 3 lat; do wywalenia
      WP-Optimize – jeśli używasz, to zostaw

      • Tomasz Kurzydłowski

        Bardzo dziękuję za podpowiedzi! Z ochotą usunę te niepotrzebne wtyczki.

        Serwer mam na Zenboxie – współdzielony.
        Aby odpowiedzieć na Twoje pytanie dotyczące mojej konfiguracji wtyczki W3TC próbowałem ją ponownie włączyć, ale pojawił się błąd „Wtyczka nie mogła zostać włączona, ponieważ spowodowała wystąpienie krytycznego błędu”. Wywaliłem ją i może lepiej skorzystać z WP Super Cache o której kiedyś pisałeś, że lepsza dla serwerów współdzielonych?

        • Moim zdaniem korzystanie z W3TC na serwerach współdzielonych nie ma sensu. WP Super Cache będzie OK.

          • Tomasz Kurzydłowski

            Dziękuję i serdecznie pozdrawiam

  • Heh, po lekturze tytułu chciałem hejtować za sianie paniki, bo w ciągu ostatniego roku mamy prawdziwy wysyp ludzi, którzy nie czytają/rozumieją informacji o podatności, a roztaczają wizje katastrof, jeśli się nie wykona szybkiej aktualizacji. Fajnie, że są wyjątki :)

    Rzeczywiście to info o XSS wyglądało na mocno rozdmuchane i trochę podejrzane.

    Ale… Tu chyba mogło chodzić o coś innego. Otóż wczoraj, wyszły informacje o kolejnych podatnościach, które miały poprzednie wersje i one już takie drobne nie są… Może więc chodziło o to, żeby nagonką mocno ludzi postraszyć, a jednocześnie nie zdradzać tych poważnych podatności od razu.

    Cóż więc czeka użytkowników starszych wersji? Lista imponująca:
    – Arbitrary PHP Code Execution,
    – Arbitrary File Download,
    – Arbitrary File Upload,
    – Security Token Bypass.

    PS. Autorom wtyczki naprawdę gratuluję wykonywania eval na importowanym (czyli wgrywanym przez użytkownika) pliku… ;)

    • Może rzeczywiście o to chodziło. Ale szczerze mówiąc nie jestem przekonany. ;)

      A co do nowych podatności – no cóż, teraz będziemy świadkami nowej fali ataków na strony z W3TC. ;)

      • Z pewnością będziemy, bo jak sobie poprzeglądałem kod powiązany z tymi podatnościami, to naprawdę śliczne są to przykłady, jak pisać się nie powinno :)

  • Szybko odreagowali na błąd :) O – operatywność :)

    • Paweł Knapek

      …a popatrz na forum ile zgłoszeń problemów z tą „poprawioną” wersją :)

  • Dziękujemy za informację czas chyba pożegnać się z W3TC