Wpadka AdTaily z logowaniem.

W piątek, 23.10.2009 część użytkowników AdTaily nie mogła zalogować się do portalu (np. w celu zmiany ustawień) – otrzymywali komunikat o błędym haśle. Co więcej, przy próbie przypomnienia hasła, otrzymywali informację, że ich email nie istnieje w bazie danych. Sprawa jest wyjaśniona, ale stanowisko AdTaily nie do końca mi się podoba, stąd moje stanowisko w tej sprawie.

Na początek fakty. Po pierwsze, uruchomiony został osobny, angielski serwer AdTaily (adtaily.eu – dead link). Po drugie, w piątek ludzie z AdTaily byli na prezentacji w UK, dlatego ustawili przekierowanie na jeden dzień (link). Po trzecie, przekierowanie było robione przy pomocy JS, wyłącznie na podstawie obecności języka angielskiego w ustawieniach przeglądarki (link). Po czwarte, część ludzi miała problem z zalogowaniem się do serwisu (czyli awarię). Po piąte, AdTaily nie pofatygowało się, by zamieścić jakąkolwiek informację na swoim blogu czy blipie.

Ponieważ temat jest – przynajmniej dla mnie – za długi na flakera, gdzie wywiązała się dyskusja na ten temat (dead link), przedstawię moje zdanie. Po pierwsze, stawianie osobnych serwerów dla wersji językowych jest złe. Rozumiem argument o problemach z przeliczaniem (o tyle, że trzeba to dorobić i przetestować, z drugiej strony wiele serwisów sobie z tym radzi bez problemu), ale osobny serwer dla każdej wersji językowej to nieporozumienie. Wystarczy pomyśleć o dwóch wersjach: zdublowane maszyny dla 4 języków w wersji z osobnymi serwerami (8 maszyn) i bez niej (2 maszyny). Oczywiście, koszt maszyn to nie wszystko, dochodzą kwestie load balancingu (no właśnie…), i skończonej wydajności pojedynczych maszyn (no właśnie…) ale i tak zapowiadane jest merge’owanie kont – przynajmniej tych występujących na obu serwisach – więc logikę i tak trzeba będzie opracować i zaimplementować.

Konferencja – się zdarza (i bardzo dobrze, trzeba się rozwijać, także na nowe rynki). Podejrzewam, że AdTaily nie było zbytnio do niej przygotowane, jeśli chodzi o np. materiały reklamowe, więc często (tylko?) pojawiało się na nich .com zamiast .eu, stąd pomysł jednodniowego przekierowania. Niegłupie (jedyne w tamtej sytuacji?) rozwiązanie, z kategorii tymczasowych.

Wykonanie przekierowania. Totalnie nieprzemyślany dramat, jak dla mnie:

function redirect_to_english_version() {  if (navigator.language.match(/en/) && (parent.document.URL == 'http://adtaily.com/' || \parent.document.URL == 'http://www.adtaily.com/')) {    window.location = 'http://adtaily.eu'  }}redirect_to_english_version();

Całkowicie pominięty fakt, że angielski jest językiem międzynarodowym, że sporo polskich użytkowników akceptuje także treści angielskie (TBH, chyba więcej angielskich czytam, niż polskich – polska to zaścianek jeśli chodzi o wiedzę, a jeśli chodzi o newsy, to jest 24-72h za resztą świata) i że polscy użytkownicy (na szybko: 1, 2, 3, 4) nie mają czego szukać na osobnym, angielskim serwisie. Inna sprawa, wiedzenie lepiej, czego user chce i podstawianie innego serwisu na podstawie wersji językowej to bzdura. Rozumiem, podstawić przetłumaczoną treść czy serwować z innej lokalizacji geograficznej…

Śmiem twierdzić, że skutki przekierowania nie zostały (dokładnie) przemyślane. Gdyby zostały, to – mam nadzieję – pojawiła by się choćby krótka wzmianka na blogu i/lub blipie. O takiej perwersji jak ingerencja w kod i dodanie jednej linii tekstu przy komunikacie z błędem logowania nie wspominam.

Wyszło jak wyszło (dla mnie brak możliwości logowania to awaria, a podejście „przekierowanie tylko na dziś” jest nieprofesjonalne), szkoda tylko, że niektórzy AFAIK dość blisko związani z AdTaily, będący w kraju, znający sytuację i rozwiazanie, nie mogli jakiegoś oficjalnego info wrzucić.

Ze swojej strony mam nadzieję, że było warto (i dla twórców i dla userów) i że na przyszłość będzie to bardziej przemyślane i przyjaźnie dla userów zrobione.

Bo takie akcje IMHO nie wpływają dobrze na – i tak nienajlepszy (to akurat zdanie osoby, której poleciłem serwis; nie chciałbym się publicznie na ten temat rozpisywać) – wizerunek serwisu. Brak „skopaliśmy, przepraszamy” też nie.

Niebawem koniec wysyłki maili na port 25.

Jeden z bardziej burzliwych tematów trzeciego spotkania PLNOG to planowane zablokowanie ruchu na porcie 25 przez TPSA. Dotyczyć będzie jedynie użytkowników Neostrady (oraz pakietów zawierających tę usługę – w skrócie – usługa dla klienta indywidualnego o zmiennym IP) i wysyłających pocztę z klientów pocztowych w stylu Thunderbirda czy Outlook Express (dla korzystających z webmaila nic się nie zmieni). Podobnie jak przy portach netbiosowych będzie istniała możliwość wyłączenia blokady poprzez zmianę loginu. Wprowadzone ma być całkiem niedługo, bo z dniem 1 grudnia.

Oczywiście było trochę ataków na TPSA podczas dyskusji, że czemu np. nie robią recenta (niby na czym?), czemu nie skanują poczty pod kątem spamu (ingerencja w treść) itp., ale akurat moim zdaniem jest to świetna decyzja (i jedyna wykonalna technicznie przy tej skali usług), tym bardziej, że i RFC pozwala na takie działanie, i – dla bardzo chcących wysyłać przez port 25 użytkowników – będzie prosta możliwość zdjęcia blokady (nie polecam). Poza tym, już teraz serwery mail na świecie mogą nie przyjmować poczty wysyłanej z portu 25 z klas IP oznaczonych jako przeznaczone do wysyłki po autoryzacji, przez serwer ISP lub webmail (zobacz PBL advisory), a takie powinny być klasy przeznaczone dla neostrady.

Nowość żadna, bo duże portale opiniowały to już parę miesięcy temu i są przygotowane, a większość dostawców została powiadomiona, ale pewnie sporo użytkowników i zupełnie małych dostawców kont pocztowych jeszcze o tym nie wie, dlatego informuję i polecam zapoznanie się z RFC 4409.

Jak już pisałem, decyzję uważam za dobrą, co więcej, mam nadzieję, że mniejsi i całkiem mali ISP pójdą tą samą drogą, i to wkrótce (pewnie poczekają nieco na efekty w TPSA). W tym przypadku inicjatywa TPSA jest naprawdę przemyślana, słuszna i dobrze wykonana (no dobrze, chwalę dzień przed zachodem słońca, ale wiem, co już zrobili i jak niewiele zostało – tylko poinformowanie użytkowników, które jest zaplanowane). W końcu jest szansa, że Polska nie będzie jednym z czołowych spamerów na świecie, a dostawcy poczty powinni odczuć spadek ilości nadchodzącego spamu, co przełoży się na spadek obciążenia serwerów poczty i maszyn skanujących.

Dla tych leniwych użytkowników, którzy nie chcą czytać – szybkie info jak włączyć nową wysyłkę poczty. Do nieszyfrowanego wysyłania poczty wystarczy zmienić port serwera pocztowego z 25 na 587.

Oficjalny komunikat TPSA dotyczący blokady portu 25, zawiera namiary na dokładne konfiguracje u większych darmowych dostawców poczty.

Masz DD-WRT? Masz problem.

A raczej, możesz mieć problem, jeśli skonfigurowałeś router tak, by serwer WWW (zarządzania przez WWW) słuchał na zewnętrznym interfejsie. Jakiego typu problem? Zdalne wykonanie kodu z prawami roota. Bez konieczności jakiegokolwiek uwierzytelniania.

Niestety, nawet ci, którzy skonfigurowali swój router tak, by serwer WWW nie słuchał na zewnętrznym interfejsie nie mogą spać spokojnie. Powodem jest niezałatana możliwość ataku przez CSRF.

Co robić? Jeśli nie chcemy/możemy zmienić softu na Tomato czy OpenWrt – co byłoby najlepszym rozwiązaniem, bo brak doniesień o podobnych problemach w tych firmware’ach – to na pewno wyłączyć zarządzanie przez WWW na zewnętrznym interfejsie i unikać podejrzanych stron (mogących być źródłem ataku CSRF). Przynajmniej do czasu opublikowania poprawionej wersji firmware’u przez DD-WRT. Jeśli to możliwe, należy wyłączyć serwer WWW całkowicie, wtedy i CSRF nie będzie groźny.

Źródło: DD-WRT (httpd service) Remote Command Execution Vulnerability

UPDATE: Jeszcze link do wątku na forum DD-WRT nt. tej luki oraz link do poprawionego firmware’u.