Najbardziej niebezpieczne oprogramowanie na świecie
2011-02-24
|
Źródło: wp.pl
Błędy w programowaniu sprawiają, że zwykła aplikacja może stać się naprawdę niebezpieczna. Efekty błędów są różne: począwszy od banalnego zawieszenia systemu, kończąc na utracie danych. Jednak zazwyczaj można się przed tym obronić.
(fot. via chip.pl)
W żadnym wypadku nie odpowiadam za to, że użytkownik jest tak głupi, aby kliknąć odsyłacz w emailu – oświadczył Daniel Kerr, szef projektu OpenCart (pakietu do tworzenia e-sklepów). Niewielu programistów pozwala sobie na tak szczere wypowiedzi, ale większość tak właśnie myśli. W tym środowisku uważa się, że największym niebezpieczeństwem dla oprogramowania jest… użytkownik. To się nawet zgadza – wiele ataków nie miałoby miejsca bez aktywnej kooperacji obsługującego aplikację, ale nie zapominajmy, że to dopiero ostatnie ogniwo w łańcuchu – pierwszym jest zawsze błąd programisty.
Potentaci tacy jak Microsoft, Oracle i Symantec oraz czterdzieści innych firm zajmujących się bezpieczeństwem komputerów, sporządzili zestawienie najgorszych błędów programistycznych (patrz tabela). Jeśli porówna się je z listą aktualnych luk w oprogramowaniu, okaże się że mnóstwo błędów czai się w znanych aplikacjach. Użytkownik może się przygotować na takie ukryte niespodzianki jedynie częściowo albo używać tych programów (patrz infografika obok) z rozsądkiem. Za każdym razem, gdy inteligencja programistów zawodzi, musi bowiem skorzystać z własnej.
Więcej >>
Zainfekowane witryny
Na czele rankingu największych luk znajduje się oprogramowanie, który nie pracuje lokalnie na komputerze użytkownika, lecz w Sieci. A to za sprawą dwóch hakerskich technik: cross-site scripting (XSS) oraz SQL Injection. Problem bierze się stąd, że użytkownik musi założyć prawidłowe działanie zdalnej aplikacji – przecież jej kod jest wykonywany w środowisku, które powinno go nadzorować. I tak się dzieje. Ale nie w obu wspomnianych scenariuszach. Przy SQL Injection złośliwym kodem jest wartość pola w bazie danych, w które za pomocą skryptu CGI zostaje wpisany wykonywalny rozkaz SQL. Z kolei w wypadku XSS zainfekowane odsyłacze wstawiają polecenia skryptowe w pola formularza atakowanej witryny.
Tę sztuczkę odczuł na własnej skórze nawet Google – w czerwcu tego roku okazało się, że na XSS jest podatny Gmail. Google stosował jako wskaźnik pobierania filmik we fleszu »uploaderapi2.swf«, a sterować daje się nie tylko formularzami, ale również filmami. W tym przypadku Google zezwalał na wykonanie nieautoryzowanego skryptu do momentu, gdy użytkownik klikał zainfekowany odsyłacz. W czasie tej akcji użytkownik był zalogowany do swego konta Gmail – często zresztą po raz ostatni, ponieważ haker uzyskiwał wtedy dostęp nie tylko do emaili ofiary, ale także mógł wykraść wszystkie dane dostępowe, a więc w praktyce przejąć całe jego konto.
Technologia XSS wykorzystująca flash to niedocenianie zagrożenie. Na początku roku haker MustLive zwrócił uwagę na podatność na ataki pliku »tagcloud.swf«, używanego w aplikacji blogowej WordPressa. Po wpisaniu nazwy zasobu w Google haker otrzymał dziesięć milionów trafień, a każde z nich to luka bezpieczeństwa.
Ryzyko związane z XSS rośnie, gdy zawodzą mechanizmy ochronne przeglądarki. Tak się działo np. z Internet Explorerem, którego filtr XSS był podatny na ataki tego typu. Haker, który wykorzystał lukę w filtrze, mógł stosować XSS w bezpiecznych serwisach, takich jak Bing, Google czy Wikipedia. Obecnie trwa dyskusja ekspertów, czy nie lepiej w ogóle ten filtr wyłączyć.
To możemy zrobić
Nie wierzmy w to, że programiści zabezpieczyli swoje serwisy przeciwko XSS. Dlatego zanim wejdziemy na podejrzaną witrynę, powinniśmy wyłączyć w przeglądarce obsługę skryptów. W Firefoksie efektywnie chroni rozszerzenie NoScript. Pamiętajmy też, żeby na nowe strony wchodzić przez pasek adresowy przeglądarki, a nie przez zewnętrzne odsyłacze.
Zhakowane konta sieciowe
Zdecydowanie wysoko na skali zagrożeń są umieszczone też ataki, które nieznacznie modyfikują formułę XSS, takie jak akceptacja zmanipulowanych zapytań, czyli crosssite request forgery (CSRF). Podobnie jak przy XSS użytkownik jest tu nakłaniany do kliknięcia niebezpiecznego odsyłacza, np. skróconej wersji adresu URL. W ten sposób do przeglądarki przemyca się kod wykonywalny. Jednak inaczej niż w przypadku XSS, ujawnia się on dopiero później, gdy użytkownik jest zalogowany do strony, którą haker chce zaatakować.
W wielu serwisach wymagających logowania konieczna jest tylko pierwsza autoryzacja. Gdy użytkownik zaznaczy przełącznik, że chce być trwale zalogowany, np. »nie wylogowuj mnie« w Faceboooku, jego dane zostaną zapamiętane przez identyfikator sesji w pliku cookie. Za pomocą CSRF haker może odczytać te informacje, zalogować się jako zarejestrowany użytkownik i w jego imieniu przeprowadzać różne działania.
Za pomocą CSRF zostało przechwyconych mnóstwo kont w największej na świecie wypożyczalni płyt DVD – Netflix. Później na koszt ich właścicieli zamawiano płyty, które serwis wysyłał pod podane adresy. W ten sposób są również regularnie czyszczone konta finansowe instytucji naukowych i charytatywnych w krajach takich jak Senegal czy Wybrzeże Kości Słoniowej – pieniądze pochodzą z dotacji ONZ, a dostęp do nich nie wymaga numeru PIN. Przed trzema miesiącami ofi arą CSRF stał się też znany portal z filmami wideo – Video.com. Konsekwencje były relatywnie mniejsze: w imieniu przejętych kont hakerzy wysyłali do serwisu kontrowersyjne filmy, dodawali obsceniczne komentarze, a czasami zmieniali dane personalne i dostępowe.
To możemy zrobić
Użytkowników Firefoksa zabezpieczy rozszerzenie CsFire. Kto nie surfuje z ognistym listem, powinien regularnie usuwać pliki cookie, aby unikać automatycznego logowania.
Odstrzelone programy
Ekspert od zabezpieczeń komputerowych, Peter van Eeckhoutte, opisuje odkrytą przez siebie lukę bezpieczeństwa jednym słowem: „Boom!”. Chodzi o błąd przepełnienia bufora, który ujawnia się w popularnym narzędziu Easy RM to MP3 Converter, gdy obsługiwana przez niego playlista w formacie M3U zbliża się do 30 000 wpisów.
Luka bezpieczeństwa przy ataku typu przepełnienie bufora otwiera się, gdy informacje stanowiące dane programu zostają przez system potraktowane jak kod wykonywalny. W omawianym przypadku, gdy liczba wpisów na playliście osiągała 26 090, van Eeckhoutte mógł zapisać w pamięci operacyjnej instrukcje, które określały, co konwerter ma zrobić po przeczytaniu pliku M3U. Bazując na tym, ekspert uruchamiał usługę Windows Telnet, aby połączyć się ze zdalnym komputerem.
Na takie ataki podatne jest oprogramowanie tworzone w językach C albo C++, które sięgają bezpośrednio do hardware’u. Taki soft ware musi polegać wyłącznie na zarządzaniu pamięci, którą zaimplementowano w CPU. W taki schemat działania wpisują się wszystkie tradycyjne programy: od Firefoksa przez Nero aż po Photoshopa. Programista może wprawdzie nadzorować od strony software’owej obszary pamięci, do których aplikacja wpisuje dane. Jednak potrzebny do tego kod trzeba tworzyć oddzielnie dla każdej funkcji i procedury, co dla małych narzędzi oznacza wzrost nakładów pracy i spadek wydajności działającej aplikacji.
Relatywnie odporne na przepełnienie bufora są natomiast narzędzia działające na platformach Runtime takich jak Java czy .NET, ponieważ wtedy przydział zasobów pamięci jest dodatkowo monitorowany przez środowisko uruchomieniowe. Ale nie za darmo – dodatkowy nadzór oznacza zawsze spadek wydajności. Co gorsza, takie podejście też nie jest do końca bezpieczne – haker ma spore możliwości, gdy błędy ujawnią się w Runtimie. A to zdarza się nierzadko – w 2010 r. tylko dla Javy odkryto aż 20 nowych luk w zabezpieczeniach.
To możemy zrobić
Uaktualniajmy na bieżąco nasze oprogramowanie, aby pozamykać odkryte luki. Windows XP, niestety, ułatwia życie hakerom – uruchomiony w tym systemie program z prawami administratora, w którym wystąpi przepełnienie bufora, przekazuje te prawa wrogiemu kodowi. To zaś oznacza poważne zagrożenie. Gdy natomiast używamy Visty albo „Siódemki” i aktywujemy w nich Kontrolę Konta Użytkownika, jesteśmy chronieni dodatkowo.
Przepełniona przeglądarka
Wiele przeglądarek ma wbudowaną ochronę określonych typów przepełnienia bufora. Kontroluje ona poprawność skoków powrotnych z procedur, których manipulowanie stanowi jądro techniki Buffer Overflow. Ale przepełnienie pamięci powstaje także w wyniku wielu innych błędów programistycznych, które mają związek z niekompletnym zarządzeniem zasobami pamięci.
W ten sposób w Operze do wersji 10.50 można było wywołać przepełnienie zakresu liczb całkowitych, czyli błąd typu Integer Overflow (patrz nr 17 w tabeli). Haker osiągał to przez ustawienie w nagłówku dokumentu HTML bardzo dużej liczby dla wartości »Content Length«. Mówi on przeglądarce, jak wielki jest przetwarzany obecnie dokument, i gdy liczba ta miała więcej niż 20 pozycji, Opera zawieszała się. Powód? Nie zgadzało się wyliczenie koniecznego do jej wyświetlenia obszaru pamięci – błąd 18.
Jednak według opinii programistów Opery taki skutek powodowało jedynie użycie liczb większych niż 263-1. A to za sprawą błędnie napisanej procedury konwersji, która dawała na wyjściu niemożliwą, a tym samym nieuwzględnioną przez resztę kodu wartość ujemną. To zaś powodowało zawieszenie się Opery i pozwalało hakerowi na kopiowanie w inne miejsca dowolnych części zajętej przez nią pamięci operacyjnej.
Niedawne odkrycie błędu typu Integer Overflow w Chromie kosztowało Google 1300 dolarów. Była to najwyższa kwota, jaką koncern wydał do tej pory w ramach programu „Chromium Security”. W przeglądarce tej do błędu przepełnienia bufora prowadził źle napisany silnik WebGL – standardu obsługującego operacje 3D – który używa do skomplikowanych obliczeń numerycznych zasobów karty graficznej.
(fot. via chip.pl)
To możemy zrobić
Możliwości użytkownika są ograniczone – wyłączenie określonych funkcji przeglądarki na nic się zda, jeśli błędy dotyczą podstawowego przetwarzania kodu HTML. Najrozsądniej byłoby przesiąść się na przeglądarkę najmniej podatną na błędy związane z przepełnieniem pamięci. Najwięcej luk w ostatnich trzech miesiącach, bo aż dziesięć, wykryto w Firefoksie; najmniej w Operze – tylko jedną, którą szybko załatano. Dobrym wyborem może też być Chrome – tylko trzy otwarte luki.
Zrujnowany przez skaner AV
Wraz z zainstalowaniem skanera antywirusowego na pecetach z Windows zaczyna się automatyczna aktualizacja sygnatur i programów. Niby wszystko gra, ale tylko „niby”, ponieważ procedura ta, aby prawidłowo funkcjonować, musi być uruchomiona z prawami administratora. A wtedy, gdy pojawia się błąd, dochodzi do najgorszego: system nie tyle się zawiesza, ile zostaje dosłownie zrujnowany – co mimowolnie zademonstrował w kwietniu tego roku specjalista od spraw bezpieczeństwa z firmy McAfee.
Wadliwe dane sygnatur siały wtedy spustoszenie w szeregach komputerów z systemem Windows, ponieważ kwalifikowały popularny proces systemowy »svchost.exe« jako kod wirusa i „dezynfekowały” go. Przyczyna błędu leżała według McAfee w braku kontroli jakości: ani nie przeprowadzono standardowego sprawdzania kodu sygnatur, ani nie przetestowano ich pod Windows XP z Service Packiem 3. Skonfundowani użytkownicy musieli więc uruchamiać Windows w trybie awaryjnym i ręcznie wgrywać poprawione sygnatury z klucza USB. Ta katastrofa dosłownie rozsadza ramy 25 najgorszych przewin programistycznych. McAfee przyznał się do błędów numer 7, 8, 9, 16 i 22, ale nawet to nie pozwoliło objaśnić łańcucha przyczyn, który wtedy wystąpił.
Ale McAfee nie jest osamotniony na polu tworzenia nowych atrakcji dla użytkowników antywirusów: poważne błędy zawierają również moduły aktualizacyjne innych wytwórców. W dużej mierze dlatego, że wielu z nich buduje swoje interfejsy na bazie podatnej na ataki technologii ActiveX, która w ostatnich miesiącach dzięki 13 lukom bezpieczeństwa stoi wysoko na liście niebezpiecznego software’u. Przykładowo moduł ActiveX skanera Pandy chce ściągać aktualizacje programu, nie weryfikując ich źródła. Podobnie jest z antywirusem firmy Symantec – jeden z jego elementów – także technologia ActiveX – w lutym tego roku był podatny na atak przepełnienia bufora.
To możemy zrobić
Nic, ponieważ na tego typu błędy w antywirusach pomaga albo ich całkowite nieużywanie, albo wyłączenie automatycznej aktualizacji sygnatur. Tyle że w ten sposób jeszcze bardziej narażamy peceta. Nie pozostaje zatem nic innego jak wierzyć w to, że programiści nie będą popełniać krytycznych błędów, ale jeśli takowe się pojawią, szybko je wykryją i usuną.
Te narzędzia pomogą przy oprogramowaniu z błędami
Za pomocą wybranych środków możemy się obronić przed najczęstszymi błędami programistycznymi.
Rozbudowa przeglądarki
Popularny Firefox ma wiele niezałatanych luk, ale żadna inna przeglądarka nie daje się tak dobrze zabezpieczyć przez plug-iny: NoScript chroni przed XSS i atakami bazującymi na skryptach, CsFire zabezpiecza przed techniką cross-site request forgery (CSRF).
Aktualizacja software'u
Po odkryciu luki programiści starają się ją zamknąć tak szybko, jak to możliwe. To użyteczne, ale tylko wtedy, gdy nowa wersja Za pomocą wybranych środków możemy się obronić przed najczęstszymi błędami programistycznymi. Prawie wszystkie narzędzia zamieściliśmy na naszej płycie. szybko dociera do użytkownika. Secunia Personal Software Inspector automatycznie informuje, gdy nowe, poprawione wydanie programu jest do pobrania.
Izolacja programów
Niekiedy upływa wiele dni, zanim powstanie nowa łatka. Do tego czasu dziurawe programy nie są dostatecznie chronione. Pomoże Sandboxie, który uruchamia niepewne aplikacje we własnym, izolowanym od systemu środowisku.
|
|
