Wpisy

Opublikowane w

Kto zarabia na premium?

Wczoraj na portalu niebezpiecznik.pl pojawił się wpis o kolejnej metodzie nadużyć w usługach GSM. Tym razem nie jest wymagana żadna ingerencja ze strony ofiary, usługa jest włączana bez jakiegokolwiek potwierdzenia, wysyłana jest jedynie informacja o włączeniu usługi, ale tę łatwo przeoczyć, szczególnie, jeśli usługa nie jest wykorzystywana w telefonie, tylko urządzeniu służącym wyłącznie do połączenia z internetem.

Telefon komórkowy

Źródło: http://www.publicdomainpictures.net/view-image.php?image=692

Obserwuję sytuację z usługami premium od jakiegoś czasu i zastanawiam się, kto tak naprawdę za tym stoi[1]. W przypadku SMS premium państwo na dzień dobry dostaje 23% podatku VAT, około połowy pozostałej kwoty trafia do kieszeni operatora GSM. Przypuszczam, że w przypadku pozostałych usług GSM jest podobnie. Kto płaci? Końcowy użytkownik, oczywiście.

Dlatego średnio wierzę w złych scamerów i wyłudzaczy, rejestrujących numer, tworzących usługę i wyprowadzających pieniądze. Nadużycia, podobnie jak zwykłe korzystanie[2] na usługach premium GSM są na rękę i państwu, i – przede wszystkim – operatorom GSM. Parafrazując: gdyby scamerzy nie istnieli, należałoby ich wymyślić.

Bo przecież zabezpieczenie przed nadużyciami na kontach premium jest proste. Wystarczyłoby, żeby były domyślnie wyłączone, każdorazowe włączenie wymagało potwierdzenia i dodatkowo była wysyłana informacja (na wskazany numer/email) o włączeniu usługi premium.

Tymczasem UOKiK śpi, a operatorzy GSM implementują mechanizmy przyjazne nadużyciom, jak ten opisany w linku wyżej. Myślę, że poszkodowani w ten sposób powinni złożyć pozew zbiorowy. Z opisu wynika, że zabezpieczenia po stronie operatora są po prostu żadne. A możliwość wyłączenia usług tego typu przez wysłanie tajemniczego kodu na tajemniczy numer, oferowana przez niektórych(sic!) operatorów, to IMO jedynie iluzja możliwości zabezpieczenia – mało kto w ogóle się o tym dowie.

[1] Sformułowanie, które powinno zapalić lampkę ostrzegawczą o teoriach spiskowych. I słusznie. 😉

[2] Kolejny temat to jaki procent zwykłego korzystania (wróżki, idiotele) ociera się o wykorzystywanie naiwności ludzi, ale nie o tym miało być.

Opublikowane w

IPv6, where are you?

Przypadkiem wpadłem na pomysł sprawdzenia statystyk dotyczących programu certyfikacji IPv6 prowadzonego przez Hurricane Electric. Okazało się, że od ostatniego sprawdzenia minęły prawie równo trzy lata. Dla przypomnienia, tamtego wpisu:

Szczerze mówiąc, myślałem, że Sage jest więcej, szczególnie, że sporo spotkałem na IRCu. Tymczasem na PLNOG dowiedziałem się, że jest raptem 87 osób w Polsce i ok. 4600 na całym świecie.

A po trzech latach? 10600 sages na świecie, 224 w Polsce. Szału nie ma, delikatnie mówiąc, biorąc pod uwagę okoliczności. Firmy radzą sobie bez IPv6, np. niektórzy ISP w Polsce zaczęli po cichu ładować klientów za NAT. Praktyka, co do której mam mieszane uczucia – z jednej strony typowy klient indywidualny niby nie potrzebuje publicznego IP, z drugiej strony pewne rzeczy działają lepiej z publicznym IP, więc powinien mieć możliwość uzyskania go, jeśli ma takie życzenie.

Oczywiście, pytanie na ile można traktować program certyfikacji HE za miarodajny. Jakiś miernik zainteresowania tematem to jest. Zresztą, postanowiłem sprawdzić „do drugiej strony”, czyli ile stron z najpopularniejszych w Polsce wg rankingu Alexa dostępnych jest po IPv6. Popularne w Polsce nie oznacza stron polskich, ale mniejsza z tym. Z pierwszej setki najpopularniejszych adres IPv6 posiada (zakładam, że jak adres jest, to serwis na nim działa) 14 sztuk, konkretnie są to, wg popularności:

  • Google.pl
  • Facebook.com
  • Google.com
  • Youtube.com
  • Wikipedia.org
  • Blogspot.com
  • O2.pl
  • Pudelek.pl
  • Kwejk.pl
  • Home.pl
  • Bezuzyteczna.pl
  • Xhamster.com
  • Gratka.pl
  • Naszemiasto.pl

Ale portale takie jak allegro.pl, onet.pl, wp.pl, gazeta.pl czy interia.pl są dostępne tylko po IPv4.

Opublikowane w

Jakość niektórych narzędzi security Linuksie

Był sobie ciekawy wpis dotyczący siły haseł i narzędzi do automatycznego jej sprawdzania. Szykowałem się do dokładniejszej zabawy i testów, ale jakoś się rozeszło po kościach, więc krótko o tym, co zauważyłem.

Wnioski na temat jakości narzędzi do generowania haseł i automatycznego sprawdzania nie są zbyt optymistyczne. Narzędzia do haseł mają błędy. Smutne błędy. Spójrzmy na następujące wynik dotyczące haseł wygenerowanych przez pwgen i sprawdzanych cracklib-checki. Za każdym razem generowane było 100 tys. haseł, o zadanej długości (poczynając do 10 i kończąc na 20). Liczba podaje, ile nie było OK wg cracklib-check.

LANG=C pwgen -s -1 10 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
79LANG=C pwgen -s -1 11 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
122LANG=C pwgen -s -1 12 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
16LANG=C pwgen -s -1 13 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
27LANG=C pwgen -s -1 15 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
59LANG=C pwgen -s -1 16 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
98LANG=C pwgen -s -1 17 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
141LANG=C pwgen -s -1 18 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
215LANG=C pwgen -s -1 19 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
275LANG=C pwgen -s -1 20 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
373

Jak widać, ilość słabych haseł spada, osiągając minimum w okolicy dwunastoznakowych, by następnie systematycznie rosnąć. Rzut oka na generowane hasła i… wszystko jasne:

HiGFYedy6gHG: it is too simplistic/systematicnowuTUtOon4W: it is too simplistic/systematicO4rstUX43Bef: it is too simplistic/systematic1mMTsIHZyHIH: it is too simplistic/systematicSeVw3MnMnOpp: it is too simplistic/systematic

Domyślnie(?) cracklib-check uznaje powtórzenie znaków za oznakę słabego hasła. Kurtyna.

Kolejne narzędzie, które znam, lubię i którego używam często (zwykle modyfikując wynik, jednakowoż) to gpw. Okazuje się, że posiada ono brzydki błąd, który powoduje, że czasami hasło nim wygenerowane jest krótsze, niż planowaliśmy, tj. niż podane w stosownym parametrze. Przykład: 100 tys. haseł szesnastoznakowych (niby!):

gpw 100000 16 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -v ': OK' | grep -i shortaqs: it is WAY too short

I hasło typu aqs. Jest nawet zgłoszony błąd w Debianie w tej sprawie. Też mam mieszane uczucia co do poziomu istotności błędu, ale… sprawdzanie długości otrzymanego wyniku to przecież trywialna sprawa, więc jakie inne błędy może mieć soft?

Ogólnie: mam wrażenie, że nie warto zbytnio ufać gotowym narzędziom. Może nawet nie to, żeby od razu pisać coś własnego, ale warto sprawdzić gotowce (bezpieczne! wolnoźródłowe!), nim się z nich skorzysta.