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.
Komentarze
Django
https://www.djangoproject.com/weblog/2013/sep/15/security/
Dzięki! Nawet o tym pisałem, tylko nie mogłem sobie przypomnieć :)
co do tego ataku z d haslem to Drupal wczoraj też „się załatał” na tą podatność
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.
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.
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.
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?