Niebo zawaliło się na głowę! SHA-1 zostało złamane! Bezpieczeństwo internetu na krawędzi!

Takich nagłówków spodziewałem się w telewizji i gazetach po ostatnim ogłoszeniu z laboratoriów Google o praktycznym wykazaniu możliwości kolizji w ramach funkcji skrótu SHA-1. Jako, że teraz każdy poważny błąd musi mieć swoje logo i nazwę, mamy ją i tym razem – https://shattered.io/.

O tym, że to się stanie, wiedzieliśmy już od jakiegoś czasu. Pisał o tym chociażby Bruce Schneier w 2005 roku. Jak widać, przez te 12 lat dużo nie zrobiliśmy, a moc obliczeniowa wzrosła na tyle, że przeprowadzenie tego typu ataku stało się możliwe.

Tak na marginesie – przy takich okazjach społeczność #infosec naprawdę wykazuje się poczuciem humoru :).

Czy internet faktycznie spadnie nam na głowę jak niebo u Asterixa?

Co to ten SHA-1 i do czego jest potrzebny?

Zacznijmy od tego, czym są te funkcje skrótu i do czego ich używamy. Chociaż użycie ich jest powszechne, w kościach czuję, że niezbyt wiele osób wie lub choćby zastanawia się, co to jest.

O funkcjach skrótu pisałem ostatnio przy okazji haseł i forum CD Projekt RED. Upraszczając – funkcja skrótu (hash function) to funkcja matematyczna, która przetwarza wejście (pre-image) na wartość wyjściową (image). Pożądaną właściwością takiej funkcji jest to, że dane wejście (plik, łańcuch znaków itp.) zawsze generuje takie samo wyjście (skrót).

Proste.

Jakie może być zastosowanie takiej funkcji? Wiele.

Unikalność generowanej wartości hash powoduje, że jest on szybkim i prostym sposobem potwierdzenia, że dana informacja nie została zmodyfikowana w trakcie jej przesyłania. W ten sposób funkcje skrótu używane są w certyfikatach, czy też w przypadku podpisu dokumentów. Hash stanowi w tym przypadku element zaufania. Jeżeli zgadza się z oczekiwaną wartością, oznacza to, że informacja na którą patrzymy jest wiarygodna.

Inne zastosowanie to po prostu generowanie hash, który będzie stanowił indywidualny wyróżnik dla każdego pliku lub innego rodzaj informacji. W ten sposób z hash korzysta chociażby git, w którym funkcja skrótu (zresztą SHA1) jest używana do identyfikowania poszczególnych zmian.

Gdzie spotkacie się z SHA1? W tej chwili w zasadzie wszędzie. Gdzie się rozejrzycie, tam znajdziecie zastosowanie tej technologii:

  • Certyfikaty używane do zabezpieczenia komunikacji w sieci (SSL/TLS), podpisu, szyfrowania czy logowania mogą być wygenerowane z użyciem SHA1. Celowo użyłem “mogą”, gdyż od dłuższego czasu publiczne urzędy certyfikacji rozpoczęły eliminowanie SHA-1 z użycia.
  • Podpis cyfrowy w różnego rodzaju formach z dużą dozą prawdopodobieństwa będzie korzytał z SHA1
  • Wspomniany już git i podobne rozwiązania używają funkcji skrótu do identyfikacji kolejnych zmian.Itp. Itd. Listę można wydłużyć.

 

Co się “roztrzaskało”?

Dlaczego to ogłoszenie Google jest istotne? Ciekawe, prawda? Użycie SHA-1 jest powszechne, więc czy to niebo wali się na głowę?

O tym, że kolizje w SHA-1 są możliwe, pisano już od dawna. A Google… praktycznie taką kolizję “wyprodukowało”.

“Wyprodukowało” to dobre określenie, bo wytworzenie tej techniki nie było proste. Cytując Google:

Here are some numbers that give a sense of how large scale this computation was:

  • Nine quintillion (9,223,372,036,854,775,808) SHA1 computations in total
  • 6,500 years of CPU computation to complete the attack first phase
  • 110 years of GPU computation to complete the second phase

Pomimo dużych liczb, jest to o wiele szybsze niż byłoby wyprodukowanie takiej kolizji przy pomocy zwykłego bruteforce (ponownie obrazując to danymi z Google).

 

Ale co to za kolizja, którą wyprodukowano? To proste – właściwością SHA1 jest to, że dana informacja generuje wynikową wartość funkcji skrótu. Jeżeli zmienimy plik wejściowy to zmieni, się też wynikowy hash.

W przypadku kolizji, dwa różne pliki dają taki sam wynik funkcji skrótu. OMG! Wszystko legło w gruzach.

Dzięki temu, że Google wykonało pracę nad tym zagadnieniem i opublikowało jego wyniki, teraz każdy z was może wyprodukować swoją kolizję SHA1.

Niebo spadnie nam na głowę!

Nie do końca. W zasadzie możemy spać spokojnie – Internet wciąż będzie działał. Co nie oznacza, że nie będzie to miało żadnych efektów, albo że nie powinniśmy podejmować jakichś akcji.

Po pierwsze wykazanie kolizji SHA1 i danie praktycznego narzędzia jego generowania nie oznacza jeszcze, że ktoś zastosuje to do fałszowania informacji albo do podsunięcia nam do podpisania fałszywego dokumentu.

Jeżeli jesteśmy w stanie wyprodukować dwa dokumenty, które generują tą samą funkcję skrótu, nie oznacza to jeszcze, że możemy na przykład wziąć istniejący dokument i stworzyć jego zmodyfikowaną wersję mającą taką samą funkcję skrótu. Do tego jeszcze nie doszliśmy.

Dla zainteresowanych szczegółami polecam artykuł Lessons From The History Of Attacks On Secure Hash Functions, w którym ładnie opisane są poszczególne problemy związane z atakami na funkcję skrótu i aktualny stan bezpieczeństwa poszczególnych funkcji.

Dlatego w zależności od modelu użycia funkcji skrótu, w danym zastosowaniu jest to problem mniej lub bardziej krytyczny.

Certyfikaty

Zacznijmy od certyfikatów. Jako podstawa bezpieczeństwa w sieci w tej chwili są dosyć ważne.

Certyfikaty wydawane przez CA posiadają swój “fingerprint” czyli właśnie hash. Hash ten może być wyliczony przy pomocy SHA1. Hash służy zweryfikowaniu całego certyfikatu.

Jeżeli możemy doprowadzić do kolizji w SHA1, to teoretycznie możemy wystawić fałszywy certyfikat, który odpowiada prawidłowemu.

Jeżeli utrzymujecie stronę lub blog i używacie SSL, warto sprawdzić, czy wasz certyfikat nie nadaje się do wymiany. Przydatny może być do tego https://shachecker.com – proste narzędzie sprawdzające wasz certyfikat.

Kolizja powoduje ryzyko, że taki problem wystąpi w przyszłości i dlatego publiczne urzędy certyfikacyjne wydające certyfikaty wycofują SHA1 z użycia już od dłuższego czasu. Możliwość wygenerowania certyfikatu, który posiada taki sam skrót, jak inny certyfikat – jest już mocno niepokojąca.

 

Przeglądarki

Z drugiej strony, przeglądarki internetowe również przystąpiły do tego samego procesu. Chrome zostało uaktualnione już jakiś czas temu. W tej chwili, jeżeli strona jest zabezpieczona przez certyfikat używający SHA1, który wygasa w 2017 lub później, Chrome zaraportuje tą stronę jako niebezpieczną.

To samo planuje Firefox, a Microsoft już uaktualnił Edge i ma plan co do Windowsa.

 

Urzędy certyfikatów

Wewnątrz firm zajmie to więcej czasu i problemów będzie więcej. Najbardziej oczywisty, to przejście istniejących urzędów CA korzystających z funkcji skrótu SHA1 na SHA256. Informacja na ten temat od dawna wisi na stronach Microsoftu, ale jak to zwykle bywa – “coś by trzeba zrobić, działa, nie ruszajmy, kiedyś się zrobi”.

Właśnie nadeszło to “TERAZ” – jeżeli używacie tych cerfytikatów do zabezpieczenia strony interentowych lub logowania do systemów – za jakiś czas może się okazać, że powoduje to problemy. Warto o tym pomyśleć szybciej, niż później.

Weryfikacja tokenów w aplikacjach.

Kolejna rzecz, na którą warto zwrócić uwagę, to wszelkiego rodzaju aplikacje oparte o wymianę wiadomości popisanych cyfrowo. Szczególnym przypadkiem są wszelkie aplikacje korzystające z protokołów federacji / SSO.

Każdy z tych protokołów opiera się na wymianie wiadomości, które są cyfrowo podpisane. Wiele aplikacji do weryfikacji tych wiadomości używa właśnie SHA1.

Jeżeli korzystacie z usług dostarczających SSO do aplikacji, to powinniście zweryfikować, czy dana aplikacja pozwala na przejście na SHA2 i jeżeli to możliwe – przekonfigurować ją, aby takiego używała. Przykładem takiej aplikacji jest chociażby Office 365.

Jeżeli nie – spytajcie się dostawcy lub developera, kiedy planuje się do tego dostosować.

To akurat bardzo praktyczny przykład. Dwa tygodnie temu mieliśmy problem z jedną z aplikacji SaaS, których używamy. Problem wynikał z tego, że po stronie Azure AD aplikacja skonfigurowana była do użycia SHA256 jako funkcji do podpisu, a aplikacja obsługiwała tylko SHA1. Niestety, musieliśmy obniżyć poziom po stronie Azure AD, żeby aplikacja znowu zaczęła działać.

 

A git? Czy git będzie git?

Git jako rozwiązanie pojawia się często przy dyskusji po ogłoszeniu Google. Głównie dlatego, że git używa SHA1 jako funkcji skrótu zapewniającej unikalność i kontrolę konfliktów przy zmianach.

Jaki problem może wywołać konflikt SHA1 w przypadku git? W prosty sposób obrazuje to poniższy tweet, w którym ktoś próbował wrzucić do repozytorium test weryfikujący …podatność na shattered.

W sprawie git głos zabrał sam Linus i mówi, że git będzie git!

(…) The reason for using a cryptographic hash in a project like git is because it pretty much guarantees that there is no accidental clashes, and it’s also a really really good error detection thing.

So in git, the hash is used for de-duplication and error detection, and the “cryptographic” nature is mainly because a cryptographic hash is really good at those things. (…)

 

Ale za chwilę sam dodaje też:

(…) I say “mainly”, because yes, in git we also end up using the SHA1 when we use “real” cryptography for signing the resulting trees, so the hash does end up being part of a certain chain of trust. So we do take advantage of some of the actual security features of a good cryptographic hash, and so breaking SHA1 does have real downsides for us.

And finally, the “yes, git will eventually transition away from SHA1”. There’s a plan, it doesn’t look all that nasty, and you don’t even have to convert your repository. (…)

Ciekawostką jest, że jeden z kontrybutorów próbował przekonać Linusa do tego, że użycie SHA1 nie jest dobrym pomysłem już w 2005 roku.

I tried to fix this when git was young, when it would’ve been easy.
Linus rejected the suggestion and didn’t seem to understand the
threat. He wired assumptions about SHA1 deeply into git. In the next
few years, nasty people will teach him the threat model, with ungentle
manipulations of his and many other peoples’ source trees.

Nauka dla was, koledzy developerzy: jeżeli ktoś doradza wam w kwestii bezpieczeństwa i kryptografii, warto go posłuchać!

I tak zapewne będzie w przypadku wielu aplikacji, wpływ oparcia się w nich o funkcję SHA1 będzie dopiero badany, a wszyscy zapewne zaplanują w kolejnych wersjach przejście na nowsze funkcje skrótu. Do czasu, aż i tych ktoś nie złamie :).

 

Podsumowując

Praktyczne wykazanie kolizji w SHA1 jest wydarzeniem. Ciekawe jest to, że zdarzyło się około czasu na jaki zostało przewidziane, patrząc na rozwój mocy obliczeniowej i technologii.

Jak będzie z pozbyciem się SHA1  – zobaczymy. Zapewne skrót ten dołączy do galerii takich sław jak IE6, SMB1 i NTLM. Wszyscy wiemy, że powinniśmy się ich pozbyć, wszyscy w tą stronę pchają, ale zawsze znajdzie się dobry powód, żeby z jakiejś części aplikacji i infrastruktury ich nie usunąć i aby dalej tam istniały.

Nauka dla nas tworzących systemy i piszących oprogramowanie jest taka, żeby w tych rozwiązaniach nie przywiązywać się do aktualnego stanu rzeczy i obecnych rozwiązań. Jeżeli korzystamy z funkcji skrótu, zróbmy to tak, aby jej zmiana była prosta i nie wpływała na działanie całego systemu. To samo dotyczy obsługi certyfikatów, algorytmów szyfrowania i podobnych elementów.

W tym wypadku powinien nam zawsze w tyle głowy brzmieć fragment artykułu Bruce Schneiera , który linkowałem na początku:

“Attacks always get better; they never get worse.”

 

Zdjęcie główne: Jon_Callow_Images via VisualHunt / CC BY

 

About Author

1 Comment

  1. Pingback: Dziury i wycieki tygodnia – SHA1 i Cloudbleed | 100 słów z Azurów

Leave A Reply

Share This

Share This

Share this post with your friends!