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.

Powtarzalne budowanie pakietów w Debianie

Dyskusji nt. zgodności pakietów binarnych z dostarczanymi źródłami teraz nie znajdę (podrzucenie mile widziane), ale Półtora roku temu pisałem o braku weryfikacji, czy kod źródłowy jest zgodny z wersją binarną. Pamiętam, że w różnych dystrybucjach wyglądało to różnie, a chyba w żadnej dobrze. IIRC na testowanym pakiecie różnice w Debianie były minimalne, bo dotyczyły tylko timestampu ale… były. W praktyce dla użytkownika końcowego oznacza to brak możliwości łatwego zweryfikowania, czy dostarczony (bardziej: deklarowany) kod źródłowy odpowiada dostarczonej wersji binarnej pakietu[1].

Implikacje są oczywiste: możemy uruchamiać co innego, niż sądzimy, że uruchamiamy. Z jednej strony może dojść do naruszenia licencji (zwł. GPL) i użytkownik może mieć problemy z modyfikacją oprogramowania, z drugiej, bardziej praktycznej: mogą pojawić się problemy z bezpieczeństwem. Nie tylko developer może dołożyć coś od siebie (developerom ufamy),. Także atakujący może w wyniku włamania przejąć klucze jakiegoś developera i wprowadzić zmodyfikowaną wersję binarną pakietu do repozytorium.

Wiadomo, że dokładna i systematyczna kontrola podstawą zaufania, w związku z tym w Debianie ogłoszono projekt Reproducible Builds. Ma on na celu dostarczenie narzędzi i środowisk do kontroli. Oraz poprawę pakietów tak, aby można było w prosty sposób sprawdzić zgodność pakietu binarnego ze źródłem. Czyli każdy będzie mógł łatwo odpowiedzieć na pytanie: czy dany pakiet powstał z deklarowanego źródła?

Projekt dotyczy raczej przyszłych wersji Debiana, ale na pewno jest krokiem w kierunku zwiększenia wolności użytkowników i bezpieczeństwa.

Wg danych projektu Reproducible Builds w chwili obecnej udało się potwierdzić powtarzalność budowy ponad 83% pakietów z repozytorium main dla Debiana unstable.

[1] Nie miejsce na dyskusję nad wyższością dystrybucji pakietów w źródłach nad wersją binarną i odwrotnie.

All your GSM numbers are belong to us!

Zaczęło się od wpisu Montera o skopanej wysyłce MMS do wielu osób. Long story short: jeśli wiadomość MMS jest wysyłana do kilku osób, to odbiorcy widzą wszystkie numery, na które została wysłana. Analogicznie jak przy wielu odbiorcach w polu To lub Cc w przypadku email (zamiast Bcc).

Telefon komórkowy

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

Moja teza jest jednak taka, że zjawisko, choć złe, nie jest aż tak tragiczne, na jakie wygląda. Odbiorca dostaje co prawda listę numerów z książki adresowej, ale nie wie do kogo należą i czy w ogóle działają. Może jedynie porównać tę listę ze znanymi sobie numerami i ustalić, jakich mają wspólnych znajomych. Albo zrobić brute force i dzwonić wszędzie (hell yeah, automaty tak robią podobno…).

Całe zdarzenie jest dla mnie porównywalne z listą PINów wszystkich ludzi na świecie (tak, wasz też tam jest, mój zresztą też), jeśli chodzi o naruszenie prywatności czy bezpieczeństwa. Postanowiłem więc zrobić listę wszystkich polskich numerów komórkowych. W trakcie tworzenia, już po pierwszym prefiksie zwątpiłem – plik miał około 100 MB surowych danych, do tego tagi HTML…

Zatem zamiast ryby – wędka i zestaw DIY do stworzenia listy wszystkich polskich numerów GSM. Na podstawie listy polskich prefiksów GSM przypisanych operatorom i odrobiny magii w Perlu, każdy może sobie wygenerować taką listę.

Blox nie lubi nawiasów ostrych, więc wklejka na zewnętrznym serwisie:

Całość działa tak długo, dopóki Wikipedia nie zmieni formatu publikowania artykułów. Klepnięte na kolanie, nieoptymalizowane w żaden sposób. U mnie wygenerowanie wszystkich numerów ww. skryptem trwa od dwóch do czterech minut. Have fun!

PS Wygląda, że w Polsce może być 110300000 numerów telefonów komórkowych. Nie odliczam niewykorzystanych prefiksów itp.