9:46
10/12/2013

W weekend opisaliśmy eksperyment w Swedbanku, gdzie ktoś próbował logować się na kolejne identyfikatory użytkowników z hasłem 123456. Ponieważ wyniki były przerażające, a dodatkowo często podczas wykonywania testów penetracyjnych widzimy, że mało który serwis poprawnie reaguje na próby zgadywania haseł, warto poświęcić trochę uwagi na to jak chronić swoją webaplikację przed tymi, jednymi z prostszych do przeprowadzenia atakami.

Mądrze wybierz dane użytkownika na login

Już na etapie projektowania serwisu, powinniśmy odrzucić pomysł loginu użytkownika pod postacią liczbowego identyfikatora, zwłaszcza takiego inkrementowanego o 1 dla kolejnej rejestracji (jest to zbyt przewidywalne — atakujący od razu zbuduje listę loginów, przydatną w procesie łamania haseł, a także ma ma dużą szansę na określenie liczby użytkowników w serwisie).

Pozwolenie na wybranie dowolnej nazwy użytkownikowi także może nie być dobrym pomysłem, jeśli nazwa ta będzie następnie występowała w webaplikacji np. jako podpis komentarzy umieszczanych przez użytkownika w serwisie. Dlaczego? Bo atakujący znów może łatwo zcrawlować nazwy użytkowników, budując listę poprawnych loginów.

Przykład scrapingu danych użytkownika

Przykład scrapingu nazw użytkownika

Zdecydowanie najlepszą opcją na login będzie wybór adresu e-mail użytkownika. (Fakt, w przypadku niektórych “nazw użytkowników” wystarczy dopisać @gmail.com i atakujący ma login — ale takie podejście przynajmniej daje tym bardziej świadomym internautom możliwość rejestracji na unikatowy e-mail (typu kazio+xxx@gmail.com dla serwisu XXX i kazio+YYY@gmail.com dla serwisu YYY). W dodatku użyteczność: internauci zdają się częściej pamiętać jaki mają adres e-mail, niż jaką nazwę użytkownika wybrali w danym serwisie (bo ich podstawowa mogła być już zajęta).

Powyższe porady zminimalizują ryzyko masowego ataku słownikowego na użytkowników waszej webaplikacji, ale nie wyeliminują ryzyka ukierunkowanego ataku słownikowego na konkretną ofiarę lub grupę ofiar, których dane zna atakujący

Jak wykrywać ataki zgadywania hasła?

Dobre podejście do loginu to nie wszystko. Warto wiedzieć jak atakujący podchodzą do “łamania” haseł online. Atakujący (ci bardziej rozsądni) nie biorą na cel jednego loginu i nie próbują do niego dopasowywać wielu haseł pod rząd. To mogłoby ich narazić na wywołanie blokady konta (lub wyświetlenie CAPTCHA) po kilku nieudanych próbach logowania.

Captcha na GMailu po 3 błędnej próbie wpisania hasła

Captcha na GMailu po 3 błędnej próbie wpisania hasła


Z tego powodu, atakujący zazwyczaj obierają jedno hasło (np. qwerty) i enumerują listę użytkowników serwisu, próbując logować się na każdego z nich tym jednym hasłem. Dzięki temu podejściu, liczą na to, że po przejściu całej listy loginów, zaczynając drugą iterację ataku, ewentualny “timer” zliczający błędne logowania dla pierwszego konta zdążył się już wyzerować.

Do automatyzacji ataków można wykorzystać swoje skrypty pisane z użyciem curla lub gotowe narzędzia, od najprostszych w użyciu dodatków do Firefoksa (FireForce) przez dedykowane programy jak webslayer, czy hydra, aż do kombajnów local proxy, typu Burp Suite (konkretnie: moduł Intruder).

Listy popularnych haseł można wziąć stąd — w przypadku Polski najlepiej sprawdzą się jednak wykradzione i opublikowane w internecie bazy danych “zhackowanych” serwisów, do dyspozycji macie: Filmweb (2010), serwisy erotyczne (2012) i Wykop (2009) [aktualizacja: Skontaktował się z nami przedstawiciel Grupy Allegro, który wyjaśnił iż o ile miało miejsce włamanie na serwery Wykopu w 2009 roku, to baza opublikowana przez włamywaczy w internecie była spreparowana, tj. nie zawierała prawdziwych hashy z hasłami]

Jak chronić webaplikację przed atakami zgadywana haseł?

 

  1. Nie blokujemy IP atakującego, który wygenerował n nieudanych prób logowania globalnie w serwisie — jeśli jego IP jest NAT-em sieci osiedlowej, odetniecie kilka (set? tysięcy?) użytkowników (a zmotywowany atakujący i tak zmieni IP, łącząc się przez kolejne proxy, zwłaszcza, że większość automatów do łamania haseł wspiera ich obsługę)
  2. Zliczamy nieudane próby logowania w kontekście konta każdego z użytkowników z osobna. I jeśli jest ich więcej niż np. 5, to dodatkowo wyświetlamy CAPTCHE, co skutecznie utrudni ataki automatyczne.
  3. Nie blokujemy dostępu do konta po X nieudanych próbach logowania! Jeśli obejmiecie taką strategię, to ktoś kto zna login “ofiary” w Waszym serwisie może celowo i długotrwale wzbudzać blokadę konta raz za razem, robiąc tzw. atak DoS, odcinający ofiarę od możliwości korzystania z serwisu. I może powtórzyć ten atak już sekundę po odblokowaniu konta przez administratora.
  4. Warto rozważyć wprowadzenie dwuskładnikowego uwierzytelnienia. Wcale nie trzeba rozsyłać użytkownikom drogich tokenów RSA czy też SMS-ów z kodami jednorazywymi. Istnieją prostsze i darmowe metody.
  5. Można wykrywać i uniemożliwiać/utrudniać np. CAPTCH-ą próby logowania przez TOR-a, o ile nasz serwis nie jest kierowany do chińskich dysydentów. Ale powiedzmy sobie szczerze: w Polsce korzystanie z TOR-a z reguły wiąże się z nadużyciami, a nie chęcią ominięcia cenzury (nie zrozumcie nas źle, jesteśmy fanami idei TOR-a, ale niestety nie wszystkich jego użytkowników). Jeśli chcesz wiedzieć jak wykryć, czy IP łączącego się z Twoim serwerem to węzeł tora, przeczytaj ten artykuł i skorzystaj z tej listy.
  6. Warto sprawdzić jak działa w Waszym serwisie opcja “zapomniałem hasła“. Jeśli od razu generuje nowe hasło, wysyła je na e-mail użytkownika i automatycznie ustawia je w serwisie, to znów macie taki problem, jak opisany pod numerem 3.

 
Na koniec zweryfikujcie czy mechanizmami ochrony przed atakami słownikowymi na pewno objęliście każdy punkt logowania, a nie tylko formularz logowania na stronie głównej. Co z API? Co z interfejsem dla urządzeń mobilnych? Często zapomina się o objęciu tych punktów wejścia taką samą ochroną jak podstawowy formularz logowania, a przecież atakujący również może je wykorzystać do ataków zgadywania haseł…

PS. Może dobrym pomysłem byłoby, abyście podczas rejestracji nowego konta sprawdzali nie tylko to, czy użytkownik nie podał za krótkiego hasła, ale również to, czy przypadkiem nie podał hasła, które znajduje się na TOP10 (TOP100?) najpopularniejszych polskich haseł. Twitter robi to od 2009 roku…

PPS. To tylko jedna z porad, jak podnieść bezpieczeństwo swojej webaplikacji. O innych dyskutujemy na naszych szkoleniach z bezpieczeństwa i na Niebezpieczniku, pod tagami ochrona i web.

Jeśli spodobał Ci się ten tekst i dzięki niemu dowiedziałeś się czegoś nowego, prześlij go proszę swoim kolegom-programistom. Niech tworzą bezpieczniejsze webaplikacje! Dzięki!

Przeczytaj także:

25 komentarzy

Dodaj komentarz
  1. Niby podstawy podstaw, a jednak nie każdy stosuje się do tego credo. Zachęciliście mnie do wdrożenia do systemu listy popularnych haseł, wcześniej to rozważałem, ale jakoś nigdy nie było mi to po drodze, a tak profilaktycznie się dzisiaj tym zajmę :-)

    • Mogę się założyć, że dobre 99% stron nie stosuje tych standardów.
      Ba! Nawet niektóre wielkie projekty open source nie stosują wszystkiego (np. WordPress nie ma listy najpopularniejszych haseł).
      Także ja do końca nie nazywał bym tej listy “podstawami”. ;)

    • Od poprzedniej wersji (3.7) WordPress ma listę najpopularniejszych haseł.

  2. Ciekawy artykuł. Ja od jakiegoś czasu stosuję taki mechanizm (wyczytany na którymś forum): w formularzu ukryty input z godziną wygenerowania strony. Wysłanie formularza w czasie krótszym niż 3 sekundy wywala captcha. Nie mój pomysł ale generalnie sprawdza się znakomicie

  3. Nie zgadzam się że “Zdecydowanie najlepszą opcją na login będzie wybór adresu e-mail użytkownika.” W takiej opcji nazwa użytkownika jest przewidywalna i bardzo łatwa do pozyskania przy ukierunkowanym na konkretna osobę ataku, może też przyczynić się do większej skuteczności masowych ataków phishingowych.

    • Tak naprawdę najlepszym scenariuszem jest proszenie użytkowników o unikatowe loginy – takie, które nie są wyświetlane nigdzie na stronie ani nie są adresami e-mail. Tylko… znam zaledwie 2 strony www które stosują taką praktykę.

    • Z ciekawości: jakie?

    • @piko Robi tak np. Steam, który generalnie ma dobrze poimplementowane zabezpieczenia.

    • @Maciek

      Apropos steama, właśnie leży i nie można się zalogować ani do klienta ani dostać na stronę :)

    • @Piotr np. https://robertsspaceindustries.com/connect

    • @Piotr Konieczny – RSI oraz Steam :) Widzę, że już linki poszły :)

  4. Swoją drogą – to zamierzone, że z waszej stopki wycieka kod? “echo date(“Y”);”

  5. Np serwisy mbanku i inteligo.

    • Serwis mbanku dbający o bezpieczeństwo który nie pozwala na używanie znaków specjalnych ;-)

    • SRSLY, przy trzech próbach na zalogowanie i tajnym identyfikatorze do konta, naprawdę hasło jest dostatcznie bezpieczne w mbanku…

    • @mm: http://xkcd.com/936/

  6. Naprawdę przydatne! Chciałem blokować dostęp po X próbach niezgadniętego hasła ,ale przedstawiliście mi czemu to założenie jest błędne! Naprawdę ,wielkie dzięki.

    Swoją drogą czy tylko captcha jest wystarczająco dobra? Pytam się ,gdyż w internecie czasem spotkam się z takim fajnym zabezpieczeniem jak “ułóż obrazek” czyli coś w rodzaju mini puzzli :).

  7. Fajną opcją jest wymuszone wyświetlanie komunikatu “błędne hasło” po 5 błędnych próbach zalogowania na różne konta z tego samego ip. Reset po kilku h. Rozwiązuje kwestie banowania ip dla całego bloku/osiedla

  8. No właśnie, nie wszyscy korzystający z Tora to pedofile i crackerzy. Użytkownicy przydają się do robienia tłumu tym naprawdę potrzebującym anonimowości. Jeśli właściciel strony np. boi się komentarzy naruszających prawo, może pomyśleć o włączeniu CAPTCHa zamiast całkowicie blokować dostęp. Albo ustawić moderację dla komentarzy “Torowych”…

  9. uzywam tor-a do wszystkiego. totalnie przeszedlem do sieci tor. uzywam go na wykopie, portalach itp. jest ciezko, ale nie beznadziejnie.

    stwierdzam, ze jesli nie zalezy nam na flashu i yutubowych filmikach da sie funkcjonowac. Sam zyje od roku w ten sposob.

    P.S. Nie blokujcie torowców

  10. A po co w ogóle zawracać sobie tym bajzlem głowę? Nie lepiej zezwolić użytkownikom na logowanie za pomocą konta google/yahoo/live/itd i niech oni się tym męczą? (openid/oauth, jak np. na stackoverflow.com).

  11. […] razem nie zawiniła dziura w webaplikacji. Nie było żadnego exploita ani 0day’a, żadnych złych Chińczyków wykradających dane, […]

  12. […] klienta, którego w bazie forum raczej włamywacz nie znajdzie. I to kolejny argument za tym, że warto mieć nie tylko unikatowe hasło, ale i unikatowy login (adres […]

Twój komentarz

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