14:59
3/8/2012

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)

Oto jak wygląda strona rejestracji:

Veturilo

Veturilo – rejestracja

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 platnosc

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 :).

Aktualizacja 7.8.2012
Firma Nextbike (nie wiemy dokładnie jak mająca się do Veturilo) przysłała nam takie oświadczenie.

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).

Przeczytaj także:

41 komentarzy

Dodaj komentarz
  1. Od tego właśnie są ładowane karty do zakupów internetowych :)

  2. no strony dostepne po http to niezly fail… zwlaszcza ten formularz z danymi karty.

    • Akurat formularz z danymi karty (hostowany przez WorldPay) nie jest dostępny po http — przeczytałeś cały artykuł, zanim dodałeś komentarz? :)

  3. >atakujący zamiast ataku SSL Strip, czyli cichego ucięcia “s” z HTTPS, musiałby zespoofować certyfikaty.

    A jak już przekierowuje przez swój komputer i użytkownik nie widzi, jakim protokołem to idzie to nie łatwiej Man in the Middle?

    • Możesz zrobić phishing (via MITM) ale czasem łatwiej po prostu obciąć “s” i słuchać transakcji klienta (podejscie dla bardziej leniwych, nie trzeba tworzyć strony do phishingu ;) Poza tym phishing często jest trudniejszy w obsłudze (jak wrócić użytkownika na kolejne kroki tego systemu, który atakujemy). Tutaj i tak tylko phishing wchodzi w grę, ponieważ formularze serwowane z RBS nie są podatne na sslstripa.

  4. I Veturilo dostało gratis mały test bezpieczeństwa :)

    • A my musimy płacić :<
      Może też załapię się na darmowy audyt bezpieczeństwa? Zrobię byle jak stronę z płatnościami i podeślę do Niebezpiecznika kilka anonimów :)

  5. Nextbike xD <- I tyle powinno wystarczyć za komentarz

    W wersji dłuższej, jeśli chodzi o realizowany przez tą firmę rower miejski we Wrocławiu
    – wiecznie zepsute rowery których nikt nie naprawia (albo zbyt mało ekip serwisujących)
    – Mało stacji, a jeśli już są to trzeba mieć DUŻO szczęścia żeby akurat stacja działała bo:
    albo "connecting…" albo słońce przygrzało i klawiatura nie działa, albo nie działa identyfikacja kartą, albo w ogóle stacja wisi – nie wiem co oni tam ładują. Windows me?
    Do tego mało czytelne w miejskim szumie nagrania w ich p o w o l i m ó w i ą c y m s y s t e m i e. (a na połączenie się z konsultantem czeka się średnio 20 minut)
    – koszt 2zł za godzinę po pierwszych 20 minutach (jak się człowiek spręży to i całe miasto przejedzie "podbijając" rower co stację.

    i najbardziej bolesne "sukcesywne uruchamianie kolejnych stacji"
    postawią 6 stacji w całym mieście i uruchamiają system, następnie stawiają kompletną stację w ciągu 1 dnia i kolejny miesiac stoi niepodłączone i bez rowerów.

    Tyle z punktu widzenia mieszkańca Wrocławia.

    • tiaa, mialem przyjemnosc, jakas masakra – niech sobie podpatrza jak to dziala gdzie indziej
      np, dublin

    • Dzisiaj TVNWarszawa zaczął straszyć, iż za kradzież rowera z nextbike, płaci się karę 2 tys. złotych, na Bemowie nic.

  6. Moim zdaniem szukanie SSL-a w pewnych okolicznościach to podejście paranoiczne. HTTPS zapobiega jedynie atakom MiTM czy sniffowaniu pakietów. W Polsce ze względu na szeroki dostęp (a czasem z racji, że to jedyna opcja w danej lokacji) bardzo popularne są łącza ADSL, gdzie jeszcze parę lat temu operatorzy dostarczali modemy do podłączenia do komputera przez USB. Obecnie od paru takie Liveboksy filtrują adresy MAC, więc teoretycznie o ile tutaj już jest możliwość nieautoryzowanego podłączenia do sieci, to nie jest to zadanie łatwe. Zmierzam do tego, że w sieci domowej, jeśli ktoś jest świadomy istnienia szyfrowanych połączeń, to potrafi zabezpieczyć swoją sieć domową na tyle, żeby zapewniła mu wystarczające bezpieczeństwo, żeby nie obawiał się intruzów w LAN-ie. No chyba, że Wy się nawet obawiacie podsłuchiwania przez operatora.

    • Ech nie każdy cały czas działa w sieci domowej. Co do filtrowania po MAC, to pomińmy ten argument wymownym milczeniem ;)

    • Tutaj chodzi głównie o zasadę i przyzwyczajenie, niż o ten konkretny przypadek. Dobrze, że chociaż nie którzy po prostu nauczyli się zwracać na to uwagę i są czujni cały czas, a pamiętaj też, że nie zawsze możesz być i będziesz w swoim komputerze i na swoim łączu i wtedy górę mogą wsiąść “twoje” przyzwyczajenia, wtedy też możesz się przejechać ;)…

    • Dokladnie. Niech uzytkownicy krzycza – slusznie – maja powod, na prawo i lewo sie trabi patrz czy jest https, a patrzenie nie jest trudne – wystarczy spojrzec na pasek adresu. I to nie wazne ze mimo wszystki https jest, tylko niewidoczny – progrsmisci nie moga wymagac, zeby zwykly internauta weryfikowal bezpieczenstwo poprzez patrzenie w zrodlo strony.

    • @steppe: oczywiście zgodzę się, że HTTPS to jest must-be na stronie, na której podajemy wrażliwe dane przez jakiegoś hotspota czy inne niezaufane połączenie.

      @Tylon, Piotr Konieczny: właśnie do tej kwestii się odnoszę. Trąbi się o HTTPS-ie, podczas, gdy tak naprawdę wzmacnia on bezpieczeństwo tylko w nielicznych przypadkach. Cały ten ból o SSL jest mocno przesadzony. Zakładam, że większość wycieków danych następuje dzięki malware’owi na systemach ofiar czy też błędach programistów, a ataki wykorzystujące nieszyfrowane połączenie to margines. Oczywiście jestem zwolennikiem stosowania szyfrowanych połączeń, bo skoro można zabezpieczyć ten, powiedzmy, jeden procent przypadków, to czemu nie, ale nie ma z tego co robić takiej afery. Artykuł rozumiem za sensowny, jak to określiłeś Piotrze w innym komentarzu, jako case study reakcji użytkowników, którym wpaja się pewne zasady.

    • Coś jeszcze mi przyszło do głowy w kwestii “widoczności” httpsa. Gdy jego używanie nie jest dla nas widoczne, choć jest obecne, to pewnego dnia może się zdarzyć, że ktoś je wyłączy. A my nie będziemy za każdym razem śledzić czy tam coś jest szyfrowanie czy nie. Tak tak, można, ale ja bym tam za każdym razem nie analizował ;)

  7. Ale po “utworzeniu konta i wklepaniu danych mamy takie oto sobie info: “Aby zakończyć rejestrację dane z Twojej karty zostaną pobrane i sprawdzone przez naszego partnera WorldPay. Odpisaną przy rejestracji kwotę możesz wykorzystać przy pierwszym odpłatnym wypożyczeniu. Kiedy konto zostanie wyczerpane, z Twojej karty kredytowej zostanie automatycznie potrącona kwota za każdy odpłatny przejazd.” Ja aż się boję dawać dostę jakiejś tam firemce do pobierania kasy z mojej karty bezposrednio!

    • Po zakończeniu płatności dostajesz link i dane, którymi możesz nią zarządzać – w tym i wycofać. Nie sprawdzałem jeszcze, jak to ma działać.

  8. A dlaczego nie mozna płacić gotówką? to dyskrminacja!

  9. Tawthe? Wut.

  10. Ech, przecież tam nawet xssy są w nexbike, pewnie i inne błędy się znajdzie. A tu jakiś art o tym, że w iframe https schowany… SSLSTRIPa czy MITM przeprowadzisz w sieciach lokalnych. Mi się wydaje, że użytkownicy korzystający np. z internetu mobilnego nie mają się czego obawiać przy tym błędzie. [tak, przeczytałem całość]

    • Ja artykul odbieram raczej jak case study tego jak na blad inplementacyjny, niekrytyczny (powiedzmy ze nawet nie zagrazajacy danym karty) reaguja uzytkownicy (i ze w ogole reaguja): “omg nie ma https, co za fail, napiszecie o tym, kradna dane” itp.
      Bo prawda jest ze jak zrobie wymagany MITM to mam wiecej ciekawszych mozliwosci niz atak na Veturilo ;)

  11. “Gdyby serwer Veturilo nie pozwalał załadować formularza się po protokole HTTP, a udostępniał jedynie HTTPS (jak np. robi to mbank), to atakujący zamiast ataku SSL Strip, czyli cichego ucięcia “s” z HTTPS, musiałby zespoofować certyfikaty” Nie do końca, przecież wtedy jedynie ruch atakujący Veturilo idzie po HTTPS, a SSL strip wykonuje się na drodze ofiara atakujący. Ofiara nadal komunikuje sie po HTTP i żadnych bledów certyfikatów nie uswiadczy.

    • Oczywiście masz rację. Zacytowany fragment odnosi się do sytuacji w której użytkownik wpisuje https://strona.pl ,,z palca”. Ale nie oszukujmy się, prawie nikt tak nie robi. Przy jakimkolwiek przekierowaniu http->https jeśli w sieci jest aktywny sslstrip to po ptakach. Doprecyzowałem ten akapit i dodałem informację o HSTS oraz HTTPS Everywhere jako sposób na zwiększenie bezpieczeństwa. Pozdrawiam
      –igh

  12. a ja tylko powiem coś o nazwie: “Veturilo” to słowo pochodzenia esperanckiego, choć w tym kraju nikt(pomijając kilka tysięcy mądrzejszych) nie mówi w tym języku, więc kto przegłosował taką nazwę? *nie tylko Polacy, lecz i grupa zapaleńców z całego świata.. PS. pamiętacie chyba listę TOP100, gdzie wygrał założyciel 4chan’a, więc i tu też, ale bez oszukiwania ;p

  13. Jeżeli pierwsza strona na jaką wejdzie użytkownik jest po http to pozamiatane – odpowiednio usytuowany napastnik może zaserwować dowolny kontent (np. przekierować formularz na swój serwer). Fakt, że prawdziwy formularz jest tylko po https nie ma znaczenia, trochę utrudnia atak.

  14. Bardzo ładny mini audyt im zafundowałeś Piotrze.

    • @dscdsc: A to nie bardziej igH?

  15. Jeszcze zepomnieliście napomknąć o możliwości “ustawienia” podobnej do veturilo strony a znajdującej się np w domenie vteurilo.waw.pl z tym samym iframe, ale z dodanym w kodzie strony “matki” keyloggerem w JS. Co jakiś czas sprawdzamy wszystkie pola w iframe (można “dostać się” przez DOM do zawartości iframe’a) i po AJAX-ie przesyłamy dane do bazki.

  16. “kiedyś wyciekło z niego 15 milionów numerów kart kredytowych…).”
    Kropka robi różnicę.

  17. Thanks for the tip with the non-https iframe. We fixed it and we will implement full HTTPS shortly.

  18. to ja jeszcze się poznęcam nad nazwą. która z poniższych domen należy do sieci rowerów miejskich, a która do phishera? ile kosztowało phishera wykupienie tych domen na 14 dni (DNT)?

    http://veturiro.waw.pl/
    http://vetrilo.waw.pl/
    http://veturilo.waw.pl/
    http://vartoilo.waw.pl/
    http://verutilo.waw.pl/
    http://vetorilo.waw.pl/
    http://vertilo.waw.pl/
    http://wartilo.waw.pl/
    http://wertilo.waw.pl/
    http://vetuliro.waw.pl/
    http://vetoliro.waw.pl/

  19. Thanks for your inspiring post.

    We moved registration and login over to nextbike.net.

    Though the key attack vector of sslstrip is not resolved this way, it’s now up to the user to check his adress bar, if he finds a “https nextbike.net” there.

    • you’re welcome – damn, you’re quick. keep up a good job.

    • Glad we could help make your project more secure. Cheers!

  20. Mnie od początku kusi żeby Veturilo pisać przez dwa “l”. I co? I dzisiaj o 14 ktoś zarejestrował taką domenę. Na szczęście nie podszywa się – po prostu przekierowuje do… kapitalisty ;)

  21. […] dni temu opisaliśmy niedociągnięcia projektu Veturilo pod kątem bezpieczeństwa. Przypomnijmy, że Veturilo to strona internetowa przez którą Warszawiacy mogą wynajmować […]

  22. […] ile serwer, do którego łączy się podsłuchiwany telefon jest źle skonfigurowany — taki atak, z wykorzystaniem sslstripa opisaliśmy na przykładzie warszawskiego […]

  23. […] lub otwartej sieci Wi-Fi w McDonaldzie i zamiast — jak do tej pory, wykorzystywać sslstripa, który posiada pewne ograniczenia — zmodyfikować sesję ofiary tak, aby wykorzystać […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.