Veturilo, czyli nowy warszawski rower miejski “straszy” klientów brakiem HTTPS przy podawaniu danych karty kredytowej Autor: redakcja | Tagi: atak, fail, kryptografia, MITM, SSL, SSL strip, Veturilo, Warszawa, web
Ruszył Veturilo (trudna nazwa) — projekt umożliwiający mieszkańcom Warszawy wypożyczenie roweru miejskiego. Aby skorzystać z roweru trzeba założyć (i doładować) swoje konto na stronie WWW. Stronę niestety zbudowano tak, że …odstrasza klientów. Już kilku czytelników zgłosiło nam w panice, że podczas rejestracji podawane przez nich dane karty kredytowej “nie są szyfrowane” (brak HTTPS). Czy kradzież danych karty z Veturilo jest możliwa? O tym poniżej.
Veturilo (Warszawa)
Na formularzu widać odznakę Secured by Tawthe (dlaczego to nas bawi?), ale w pasku adresowym jest tylko HTTP, a nie HTTPS jak moglibyśmy się spodziewać, kiedy w grę wchodzi przesyłanie danych karty kredytowej…
Veturilo – sama płatność kartą wygląda jeszcze bardziej przerażająco
Cieszy nas, że nasi czytelnicy są na tyle wyczuleni, że “szukają HTTPS-a” podczas wprowadzania danych swojej karty, ale uspokajamy — dane przesyłane przez forumularz rejestracyjny Veturilo są mimo wszystko przesyłane w sposób zaszyfrowany (co nie oznacza, że bezpieczny, ale o tym niżej).
W skrócie:
Tak, na Veturilo jest HTTPS. Formularz rejestracyjny osadzono bowiem na stronie poprzez iframe (via HTTPS). Bezpośredni, “bezpieczny”, link do formularza można zobaczyć klikając tutaj.
Nie, Veturilo nie zaimplementowało tego formularza poprawnie — tak nie powinno się robić. Dlaczego? O tym poniżej.
Nie, błąd nie jest krytyczny, a ryzyko ataku jest stosunkowo niskie. Co nie znaczy, że geneza błędu nie jest ciekawa, a potencjalne ataki interesujące (ale o tym poniżej)
Ale jednak wpadka Veturilo: ryzyka na jakie naraża Veturilo swoich klientów
Zaprezentowany na Veturilo sposób osadzania formularza jest zdecydowanie odradzany z 2 powodów.
Pierwszy — oczywisty błąd — to odstraszanie od swojej usługi “świadomych” klientów. O ile z podawaniem imienia i nazwiska po HTTP raczej nikt nie ma problemu, to już przy formularzach, gdzie w grę wchodzi płatność ludzie (na szczęście!) zwracają uwagę czy połączenie jest bezpieczne (obecność HTTPS:// na początku adresu) i jeśli nie jest, opuszczają stronę (a firma traci).
Celowo nie polecamy szukać “kłódki” — bo to może być bardzo zwodniczym działaniem. Cześć atakujących serwuje stronę po HTTP, a jako faviconę ustawia …obrazek kłódki. Większość klientów nie widzi różnicy, bo nie pamięta gdzie ich przeglądarka ma pokazać symbol kłódki, a w wielu instrukcjach bezpieczeństwa, np. na stronach banków, jest napisane “znajdź kłódkę” …i tyle.
Drugi popełniany przez programistów Veturilo błąd to podatność na atak SSL Strip. O co chodzi? Jeśli atakujący jest w tej samej sieci co ofiara (otwarta lub chroniona WEP-em sieć Wi-Fi albo dowolna sieć LAN umożliwiająca ataki ARP spoofingu), to może on co do zasady, przekierować połączenie ofiary do internetu przez swój komputer. Ofiara pobiera stronę Veturilo po HTTP, a więc jawnym tekstem, który widzi i może modyfikować atakujący. W kodzie jest instrukcja ładująca ramkę z formularzem rejestracyjnym po HTTPS, ale atakujący (ponieważ dane przechodzą przez jego komputer) ucina “S” z HTTPS, a więc przeglądarka ofiary nie będzie negocjowała szyfrowanego połączenia, a dane, które powinny być przesyłane jako zaszyfrowane, będą przesyłane otwartym tekstem.
Dodatkowo, Veturilo ma jeszcze jeden błąd implementacyjny, wykorzystywany przez nich “bezpieczny” formularz logowania daje się bez najmniejszych przeszkód załadować również po protokole HTTP (popatrzcie sami) a nie tylko po HTTPS. Gdyby serwer Veturilo nie pozwalał załadować formularza się po protokole HTTP, a udostępniał jedynie HTTPS (i nie dało się na niego wejść inaczej niż wpisując z palca
https://veturilo.waw.pl), to atakujący zamiast ataku SSL Strip, czyli cichego ucięcia “s” z HTTPS, musiałby zespoofować certyfikaty — a to zawsze wiąże się z pokazaniem przez przeglądarkę ofierze alertu “Strona z którą próbujesz się połączyć ma błędny certyfikat“. (Ile osób ignoruje takie ostrzeżenia, to zupełnie inna sprawa i materiał na kolejny post…

. Niestety takie podejście nie jest realne. Zawsze inna strona załadowana po HTTP może podlinkować/przekierować na serwer HTTPS i jeśli wtedy ktoś na drodze pakietów wykona atak SSL Strip, to ofiara nie będzie niczego świadoma. Dlatego na pewno warto dodatkowo wykorzystać protokoł HSTS (i DNSSEC) (to po stronie serwera) oraz rozszerzenia HTTPS Everywhere (to w przeglądarce klienta) — to pomoże ograniczyć ryzyko ataku SSL Strip.
Veturilo ratuje jednak to, że kolejny krok rejestracji, czyli obsługę kart, wykonuje zewnętrzny serwis w innej domenie, która pozwala załadować się jedynie po HTTPS. Niestety, nie znaczy to, że sprytniejszy atakujący nie pokusi się o podmianę linku do bezpiecznego formularza na inny, kontrolowany przez siebie — ale na tego typu ataki phishingowe narażony jest każdy serwis nie obsługujący całej sesji po HTTPS, nie tylko Veturilo.
Werdykt
Podsumowując, strona Veturilo, w obecnym kształcie, pod kątem bezpieczeństwa nie jest zaprojektowane najlepiej, mimo, że popełnione błędy nie są krytyczne. Implementacja formularza rejestracji danych uniemożliwia klientom weryfikację, czy znajdują się w bezpiecznym połączeniu (URL iframe jest niewidoczny). Co gorsza, da się także wymusić ładowanie podstawianych przez Veturilo formularzy bez szyfrowania, czyli po HTTP, a nie HTTPS (a nawet gdyby się nie dało, to pozostaje atak SSL Strip, na który podatne jest większość stron osadzających zasoby HTTPS via HTTP).
Na szczęście, dane kart kredytowych wprowadza się dopiero na formularzach hostowanym poza serwerami Veturilo — czyli na dużo bezpieczniejszym, zewnętrzny systemie Worldpay (aczkolwiek należy on do niezbyt stabilnego ostatnio Royal Bank of Scotland i kiedyś wyciekło z niego 15 milionów numerów kart kredytowych…).
Twierdzenie, że dane kart na Veturilo przesyłane są bez szyfrowania, nie jest więc prawdziwe ale do najwyższego poziomu bezpieczeństwa trochę jeszcze brakuje — np. cała obsługa konta na Veturilo — w tym zmiana PIN-u — jest po HTTP i może zostać podsłuchana w otwartych sieciach Wi-Fi, i w tych z WEP-em, i w sieciach LAN po ataku ARP spoofing — jeśli więc jesteś w Starbucksie, nie korzystaj z Veturilo

.
Porada
Na koniec, sprawdźcie czy w swoich serwisach nie ładujecie ramek HTTPS z HTTP lub nie posiadacie na stronach serwowanych po HTTP formularzy z action ustawionym na HTTPS (to ten sam “błąd”). Rozważcie użycie HSTS i DNSSEC jako ochronę przed atakami SSL Strip.
A jeśli jesteście zainteresowani zagadnieniami bezpieczeństwa serwisów internetowych, to zapraszamy na nasze szkolenia — zostały jeszcze 2 ostatnie miejsca termin 30-31 sierpnia w Warszawie — uczestnikami naszych szkoleń w ciągu ostatnich 2 lat byli specjaliści z największych i zagranicznych polskich firm (Intel, Nokia, mBank, Inteligo, MSZ, Nasza-Klasa, Netia, Orange, Play, Allegro) i wystawili nam bardzo pozytywne oceny (na żądanie udostępniamy wybrane rekomendacje).