21.11.2014 | 10:40

Adam Haertle

Aktualizujcie WordPressa. Teraz

Jeśli ciągle korzystacie z WordPressa 4.0, to albo włączcie automatyczne aktualizacje, albo szybko aktualizujcie do wersji 4.0.1. A jeśli macie wersję 3.x, to aktualizujcie jeszcze szybciej – błąd XSS w niej istniejący można dość łatwo zamienić w wykonanie kodu po stronie serwera i jest najpoważniejszą dziurą wykrytą w ostatnich latach.

WordPress 4.0.1 usuwa liczne błędy, w tym możliwość ataku DDoS poprzez próby logowania z bardzo długim hasłem, doprowadzające do wyczerpania zasobów maszyny (wiele miesięcy temu prawie identyczny błąd wykryto w innych CMSach – ktoś pamięta jakich? w Django). Oprócz tego załatane zostało kilka błędów typu XSS oraz ciekawa potencjalna kolizja funkcji skrótu hasła, mogąca wystąpić pod warunkiem że użytkownik nie logował się od… 2008 roku.

Dużo ważniejszy i ciekawszy jest jednak błąd XSS występujący we wszystkich starszych wersjach (3.x), który pozwala atakującemu na wstrzyknięcie kodu JavaScript do komentarza (poprzez umiejętne ominięcie błędnie skonfigurowanego filtra kodu HTML) a w konsekwencji na przejęcie kontroli nad blogiem w momencie, gdy administrator zaloguje się do swojej konsoli. Atak można przeprowadzić w sposób niewidoczny dla administratora, usuwając zmodyfikowany komentarz w momencie rozpoczęcia ataku. Na stronie autora tego odkrycia znajdziecie bardzo szczegółowe wyjaśnienie błędu.

wp

Powrót

Komentarze

    • 2014.11.21 10:50 Adam

      Dzięki! Nawet o tym pisałem, tylko nie mogłem sobie przypomnieć :)

      Odpowiedz
      • 2014.11.21 13:24 DMati

        co do tego ataku z d haslem to Drupal wczoraj też „się załatał” na tą podatność

        Odpowiedz
  • 2014.11.21 11:27 Andrzej

    4.0.1 usuwa liczne błędy, ale za chwilę dowiemy się że posiada kolejne, i tak w kółko. Najważniejszym jak dla mnie jest posiadanie aktualnych wtyczek w WordPress, to one są głównie narażone na ataki i dziurawe jak ser szwajcarski, i tu cyberprzestępcy głównie poszukują luk. Ważnym jest też ukrycie wersji WordPressa.

    Odpowiedz
    • 2014.11.21 21:39 Marcin

      Możesz ukrywać wersję w kodzie HTML do woli, jak są metody na jej wyciągnięcie analizując JS/CSS plików WP. Sam w ten sposób sprawdzam wersję WP bo daje to lepsze wyniki i pozwala wykryć np. na stałe wpisaną wersję w kodzie HTML która nie zgadza się z rzeczywistą.

      A na wp-login i xmlrpc każdy WP instalowany na moich serwerach ma standardowo fail2ban dodany i 2-3 próby logowania już blokują IP.

      Odpowiedz
  • 2014.11.21 11:56 Marcin

    Ponad rok temu opisałem jak w bardzo prosty sposób uniknąć ataku na wp-login: http://iworks.pl/2013/09/25/atak-na-wp-login-rozwiazanie/

    @Andrzej: zawsze tak jest, że przy zmianach w kodzie pojawiają się nowe podatności, albo wracają stare.

    Odpowiedz
    • 2014.11.21 23:52 Andrzej

      Marcin – zgadza się, zmieniłem stronę logowania, zmniejsza ryzyko brute force, prócz tego prefix bazy zmieniony ze standardowego wp_ na mój, 5G Blacklist włączone, następnie blokuję różne nędzne sieroty próbujące zrobić mi „kuku”,korzystając z bazy Stop Forum Spam, Project Honeypot i BotScout, i blokuje kraje które chcę – czyli standard Chiny, Indie, Turcja, Ukraina,Pakistan, Syria, Litwa i podobne zagrażające mojej witrynie, a także anonimowe proxy, i jeszcze mam dodatkowo kilka ciekawostek dla chcących zrobić mi „krzywdę”.

      Ukrywanie poszczególnych wersji plików w js & css, krótka funkcja :

      function remove_versions( $src ){
      $parts = explode( ’?ver’, $src );
      return $parts[0];
      }
      add_filter( 'script_loader_src’, 'remove_versions’, 15, 1 );
      add_filter( 'style_loader_src’, 'remove_versions’, 15, 1 );

      Jakieś pytania?

      Odpowiedz

Zostaw odpowiedź do Marcin

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Aktualizujcie WordPressa. Teraz

Komentarze