Jak zenbox.pl z domen klientów korzystał

Niedawno na blogu sprawnymarketing.pl pojawił się wpis o tym, jak rzekomo Zenbox stosował black hat SEO. Sprawa okazała się znacznie głębsza, szersza i ciekawa, niż na pierwszy rzut oka wyglądał. W różnych wymiarach, od technicznych, po prawne.

Przede wszystkim, niezaprzeczalnym faktem jest, że niektóre strony (raczej: większość) hostowane na zenbox.pl, pokazywały co innego przy wejściu przez HTTP, a co innego przez HTTPS. Jak pokazują zamieszczone w ww. wpisie zrzuty ekranu, narzędzia do badania SEO zauważały te linki. Raczej słusznie, bo wbrew temu, co twierdzi zenbox.pl, strony te nie zostały zignorowane przez Google, lecz normalnie zaindeksowane, co pokazuje poniższy zrzut ekranu:

Zenbox.pl SEO HTTPS

Szybko okazało się, że zenbox.pl nie jest jedynym hostingiem, który działa w ten sposób, a winny jest prawdopodobnie panel DirectAdmin, którego domyślna konfiguracja powoduje pokazywanie „zaślepki” przy braku podpiętego certyfikatu SSL. Potem było już tylko weselej, bo w dyskusji na Wykopie niektórzy sugerowali, że w zaślepkach powinien być w linkach atrybut nofollow. Uważam, że akurat brak nofollow świadczy w tym przypadku na korzyść zenbox.pl i braku celowego działania – gdyby ktoś zawracał sobie głowę atrybutami czy anchor text (a są i tacy), to znaczy, że pomyślał o pozycjonowaniu.

Jeszcze bardziej dziwi mnie skupienie się na SEO i ominięcie sedna sprawy: nie chodzi o – celowe lub nie – wprowadzenie w błąd Google. Przede wszystkim mamy do czynienia z podmianą treści na stronie zamieszczonej w określonej domenie. Wątpię, by właściciele domen mieli wiedzę, że taka podmiana miała miejsce. Jeszcze bardziej wątpię w ich zgodę na takie działanie.

HTTPS zamiast HTTP niewiele tu zmienia – oczywiście jest możliwość serwowania różnych treści w zależności od protokołu, podobnie jak strona z przedrostkiem www (de facto subdomena) z technicznego punktu widzenia może kierować zupełnie gdzie indziej, niż domena bez takiego przedrostka, ale przyjęte jest, że kierują w to samo miejsca. W przypadku HTTPS jest to IMO wręcz oczywiste.

Pamiętajmy też, że strony WWW, zwłaszcza popularniejsze blogi, potrafią po prostu sprzedawać miejsce na reklamę na stronie. Wydaje mi się, że w przypadku takich blogów wykazanie szkody w sądzie byłoby trywialne. Dlatego podejście zenbox.pl do sprawy mnie dziwi. Jak widać w komentarzach na blogu, mamy kolejno:

  1. straszenie „na takie działania godzić się nie można i zrobimy wszystko aby takie akcje miały konsekwencje”
  2. negacja, najpierw problemu w ogóle (screenshot w ww. wpisie), potem wpływu „działania nie mają wpływu na pozycję stron klientów ani wpływu na pozycję witryny zenbox.pl”
  3. przyznanie istnienia problemu „wspomnianego problemu nie doświadczyli” i w końcu podjęcie działań (zmiana konfiguracji, mailingi)

Wydaje mi się, że znacznie bardziej na miejscu byłaby analiza sytuacji, podziękowanie za zwrócenie uwagi, naprawienie problemu (poprawa konfiguracji) i przeproszenie klientów.

Cała sprawa ma jeszcze jeden ciekawy aspekt. Wydaje mi się, że największy błąd popełniło… Google, które podmienioną treść na stronie jak widać łyka jak pelikan. Mimo ewidentnych błędów HTTPS (certyfikat nie pasuje do domeny), które m.in. przed taką podmianą miały chronić. W czasach, gdy każda domena może mieć rozpoznawany przez przeglądarki certyfikat SSL za darmo (oczywiście chodzi o projekt Let’s Encrypt) strony za niepasującymi, wygasłymi i self signed certyfikatami powinny po prostu być ignorowane.

Prawidłowa konfiguracja to IMHO ta sama treść dostępna po HTTP i HTTPS. Czy to za sprawą odpowiedniego przekierowania (to sensownie uda się tylko z HTTP na HTTPS…), czy też – zwł. na shared hostingu – pod certyfikatem hostingodawcy, jeśli domena nie ma własnego.

Jak zrobić kuku spamerowi?

Jak wielu innych ludzi, darzę spamerów czystym i płomiennym uczuciem. Jakiś czas temu popełniłem automat do wykrywania spamu na Blox. W zasadzie, to tych skryptów jest kilka i raczej dane zbierają się „na kiedyś”, niż działa to produkcyjnie, ale czasem coś tam podeślę do blokowania. Niemniej, nie jest to pełny automat.

Jeśli chodzi o pocztę, to nie jest u mnie ze spamem źle. Łącznie na wszystkie konta dostaję jakieś małe pojedyncze sztuki dziennie. Część odsiewają dostawcy poczty, przytłaczającą większość tych nielicznych, które przejdą oznacza Thunderbird.

Dodatkowo, jeśli już coś do mnie dotrze, to zwykle trafia na Spamcopa (polecam zarejestrowanie się). Roboty z tym tyle, co kliknięcie Forward i linka w mailu, więc niewiele, a powiadamiane są wszystkie powiązane abuse. Polecam rejestrację. Czasem nawet odpiszą, że zablokowali (i to niekoniecznie nadawcę, bo potrafią reagować także właściciele domen/hostingów na których znajduje się „reklamowana” strona. Tak czy inaczej, o ile nie zadziała to pewnie na spam o niebieskich pastylkach wysyłanych z botnetów (ale liczę, że to odpada na etapie dostawcy poczty, zresztą mało tego typu dociera do mnie), to działa[1] na byznesmenów wysyłających zapytania o możliwość wysłania oferty handlowej do adresatów z baz pozyskanych z ogólnodostępnych źródeł. Znaczy, tłumacząc na polski: na spamerów wysyłających spam, bo (polskie) prawo prawem, ale o tym, czy wiadomość była zamówiona decyduje jednak odbiorca.

Niedawno, podczas szukania rozwiązań antyspamowych trafiłem na ciekawą stronę Email Labirynth, która generuje losowe adresy email w celu zaśmiecenia baz danych harvesterom, a w konsekwencji spamerom. Czyli po pierwsze stracą czas zbierając te adresy, po drugie stracą czas wysyłając maile na nieistniejące adresy, a po trzecie jest spora szansa, że dzięki takim wysyłkom trafią na RBLe. Nie jestem przekonany o skuteczności, ale spróbować IMO nie zaszkodzi. Sceptykom twierdzącym, że spamerzy nie mogą być aż tak głupi od razu mówię, że nie tylko mogą, ale są. Może nie wszyscy, ale większość. No i zwykle mają słabe automaty, a nadzór ludzki kosztuje.

W każdym razie powyższe rozwiązanie ma IMO kilka wad:

  • Brak spamtrapa na każdej stronie. IMHO na każdej(?) stronie wśród generowanych maili powinien być także spamtrap w celu automatycznego zgłaszania IP korzystających z harvestowanych adresów email do abuse/RBLi.
  • Stały adres strony. Wystarczy szczątkowa inteligencja, by nie harvestować tam adresów email.
  • W pełni losowe loginy. Trochę wada, trochę zaleta. W każdym razie wyglądają mało naturalnie i przy odrobinie wysiłku można je odsiać.
  • Brak lokalizacji. Wiadomo, że spamerzy celują z niektórymi produktami raczej w określone grupy klientów, np. klientów z Polski. Dane z ww. strony zdecydowanie nie wyglądają na bazę polskich klientów email.

Koniec końców postanowiłem zrobić swoje rozwiązanie realizujące podobny cel (oczywiście Perl). Na razie mam opracowane częściowe rozwiązanie[2] dla dwóch ostatnich punktów. Punkt drugi też będzie rozwiązany, bo zamierzam opublikować gotowca, którego każdy będzie mógł podpiąć na swojej stronie.

Ponieważ pewnie trochę czasu będę miał dopiero w przyszły weekend, liczę do tego czasu na uwagi dot. sensowności i ew. innych funkcjonalności.

[1] Działa, znam trochę środowisko hostingowe. Przyzwoite hostingi nie przepadają za wysyłającymi spam do zaśmieconych baz adresów email, a z tego co wiem w polskich firmach hostingowych abuse raczej działa.

[2] Jak dam sobie na luz z perfekcjonizmem, to pewnie uznam je za docelowe, przynajmniej w pierwszej wersji.

UPDATE: No i uruchomiłem. Póki co wersja testowa karmnika z adresami email wisi tu.

Dziura w OpenSSL, o jakiej się nie śniło

No bo jak inaczej nazwać błąd, który pozwala na zdalny dostęp do pamięci podatnej maszyny? Co prawda „tylko” 64kB i „tylko” związanej z procesem korzystającym z biblioteki zawierającej błąd, ale biorąc pod uwagę, do czego OpenSSL służy… Wyciec mogą klucze (jeśli nie zostaną zmienione, to w przypadku ich przechwycenia będzie można podsłuchać transmisję nawet po aktualizacji biblioteki), loginy i hasła (jeśli użytkownicy nie zmienią haseł, to atakujący będzie mógł się dostać do serwisów nawet po zmianie certyfikatów i aktualizacji biblioteki).

Heartbleed

Źródło: http://heartbleed.com/

Błąd związany z OpenSSL w Debianie sprzed blisko 6 lat to przy tej dziurze pikuś – wtedy wystarczyło zaktualizować pakiet i zmienić klucze. Teraz na dobrą sprawę należałoby zmienić wszystkie certyfikaty SSL (o ile były używane na choć jednej podatnej maszynie) i skłonić wszystkich użytkowników do zmiany haseł. Niekoniecznie technicznych użytkowników, dodajmy.

Ważne jest to o tyle, że niektóre popularne polskie serwisy oferujące darmową (i nie tylko) pocztę były podatne. I to dość długo (nie wiem, czy nadal nie są). Jeśli atakujący uzyska dostęp do poczty, a używamy tej skrzynki do przypominania hasła w innych serwisach to zmiana w nich haseł nie rozwiązuje problemu.

Dodatkowo sprawdzanie podatności systemów było utrudnione. Popularny test sprawdzający podatność na atak z powodu obciążenia zgłaszał… false negatives. Czyli system był podatny, a narzędzie testujące twierdziło, że jest OK. I to w pewnym momencie, wg moich obserwacji, w jakichś 9x% prób… Problemu tego nie miało narzędzie CLI, ale dość szybko przestało ono być dostępne. Zapewne dlatego, że skutkiem ubocznym tego narzędzia był zrzut pamięci i dostęp do wrażliwych danych.

Na koniec mały paradoks. Systemy, w których logowanie było bez szyfrowania nie są podatne na dziurę (za to były i są podatne na podsłuchanie transmisji). Podobnie jak Debian Squeeze, czyli oldstable, któremu wkrótce skończy się support bezpieczeństwa. Użyta w nim wersja OpenSSL jest na tyle stara, że nie jest podatna.

Na razie status jest taki, że jest dostępna poprawka, załatana jest część systemów (wczoraj o ok. 17 było naprawdę sporo dziurawych). Widziałem tylko jedną firmę (polską), która poinformowała o błędzie użytkowników i zaleciła zmianę certyfikatów (ale już ani słowa o hasłach). Osobiście zalecam zwykłym użytkownikom w tej chwili zmianę ważniejszych haseł (zwł. pocztowych!) i obserwację sytuacji. Gdy opadnie kurz, tj. administratorzy załatają systemy i wymienią certyfikaty – ponowna zmiana haseł, tym razem wszystkich (ale naprawdę wszystkich wszystkich).

Błędowi poświęcona jest specjalna strona i tam odsyłam po szczegóły. Tak jeszcze patrzę na to, co napisałem parę lat temu i chyba tekst dane, niezależnie od tego jak zabezpieczane, nie są bezpieczne i prędzej czy później nastąpi ich ujawnienie łapie się na jakieś motto.

UPDATE: Ważna uwaga, o której zapomniałem. Jeśli aktualizujemy OpenSSL w systemie, to trzeba jeszcze zrestartować usługi. W Debianie można skorzystać z polecenia checkrestart (pakiet debian-goodies), ale na przynajmniej jednym systemie pokazywał, że nie ma nic do restartu, choć był apache i zabbix-server. Można zamiast tego użyć:

lsof -n | grep ssl | grep DEL