Ostatnie kilka lat to okres wzmożonej aktywności przestępców, w zakresie kradzieży informacji z baz danych. Powód jest dość oczywisty – proceder ten stał się bardzo intratnym zajęciem, przy jednoczesnym niewielkim nakładzie kosztów. Dodatkowo rosnąca popularność wszelakich usług opartych o dane osobowe oraz rozwój technologii przepływu informacji sprawiły, że żyjemy w świecie, w którym to informacja jest najcenniejszą walutą. Niejednokrotnie byłem świadkiem wypowiadanych zdań typu: „ile bym dał za informacje o klientach konkurencji”, „moja baza klientów to najcenniejsza rzecz w całej firmie” – w branżach daleko odbiegających od sektora IT. Informacje o kradzieżach czy „zagubieniach” laptopów i innych nośników danych, przemycanie danych przez pracowników firm czy wreszcie bezpośrednie ataki wykorzystujące słabości samych baz danych lub interfejsów dostępu do danych (SQL injection), doprowadzić mają do jednego – do przejęcia cennych informacji. Media karmią nas wybranymi przypadkami, gdzie ilość utraconych danych sięga setek tysięcy czy milionów rekordów lub sama specyfika danych (jak choćby szczegółowe informacje o świadkach koronnych, dane tajnych służb itp.) sprawia, że notka o wycieku jest warta publikacji. Jednak statystyki dowodzą, że ataków tego typu jest coraz więcej i odbywają się na coraz większą skalę. Przestępcy poznali wartość „informacji” i będą starali się zdobyć ich jak najwięcej.
Interesująca tabelka znajdująca się pod adresem: http://www.privacyrights.org/ar/ChronDataBreaches.htm skłania do przemyśleń. Zawiera ona ponad 850 aktualizowanych na bieżąco wpisów, dotyczących utraty cennych danych, od początku 2005 roku. Łączna ilość skradzionych rekordów oscyluje w okolicach 223 mln [na dzień 13.04.2008], z czego wynika jasno (po uproszczonym uśrednieniu), że co około 1.5 dnia ma miejsce wyciek ważnych informacji, a na jedną „wpadkę” przypada około 250 000 rekordów. Zapomniałem dodać, że tabelka obejmuje jedynie terytorium Stanów Zjednoczonych Ameryki :]
Lecz jaka w tym wszystkim „zasługa” botnetów? W pierwszej kolejności wszelkiego rodzaju oprogramowanie malwarowe, zabierało się za dyski zainfekowanych klientów w poszukiwaniu informacji, które mogłyby następnie zostać radośnie wykorzystane. Jakby tego było mało specjaliści z McAfee na swoim blogu: http://www.avertlabs.com/research/blog/… poinformowali o odkryciu trojana Fribet, który w swojej funkcjonalności oprócz standardowych i popularnych opcji, posiada także zaimplementowanego klienta SQL poprzez biblioteki ODBC. Podłączanie się bezpośrednio z zainfekowanej maszyny do lokalnych i zdalnych baz danych, wykonywanie zapytań w celu kradzieży danych, dodawanie informacji do już istniejących zawartości to elementy bezpośrednio wykorzystywane przez owego klienta SQL. Bardzo możliwe, że za pomocą tego oprogramowania około miesiąca temu, miało miejsce zarażenie ponad 10 000 stron, dodatkowym IFRAMEm, który starał się wykorzystać jedną z podatności systemu operacyjnego. Więcej na ten temat znów na blogu McAfee: Blog .
W zasadzie doszło do tego, że boty wykorzystując luki typu SQL injection, infekują inne komputery, aby te następne znów umożliwiały kradzież danych za pomocą SQLa, a także wykorzystywały luki SQL injection w celu zarażania innych aby znów tamte… i tak w kółko…
Warto zdawać sobię sprawę z wartości naszych newralgicznych danych i zadbać o ich bezpieczeństwo.
Aktualizacja i hardening, przede wszystkim serwera bazodanowego oraz systemu operacyjnego, a następnie komponentów takich jak choćby serwery WWW współdziałające z bazami danych. Analiza i audyt kodów źródłowych wykorzystywanych aplikacji. Polityka częstej zmiany haseł (na trudne) oraz próby złamania dostępu do bazy za pomocą popularnych i prostych haseł. System IDS/ISP czy nawet HoneyPot bazodanowy. Szyfrowanie danych na dyskach, w bazach danych i wszedzie tam gdzie jest to tylko możliwe. Odpowiednie polityki fizycznego dostępu do danych. Monitoring i śledzenie logów systemowych. Systematyczne przeszukiwanie uprawnień użytkowników pod kątem anomalii i słabych punktów. Edukacja pracowników i użytkowników, to tylko część przydatnych informacji mogących uchronić nas przed sytuacją (zreszta z życia wziętą), w której to otrzymamy tradycyjną pocztą list, z informacją o poleceniu wpłaty 250 000 dolarów na określone konto bankowe, gdyż w przeciwnym wypadku wszystkie dane naszych klientów zostaną sprzedane na czarnym rynku. Postarajmy się, nie oddać im swoich baz bez walki :]
7 komentarzy do
16 kwietnia, 2008 o godzinie 13:13
Artykuł dość ciekawy, ale idź na jakiś kurs angielskiego, jeżeli chcesz pisać tytuły w tym języku albo chociaż poproś kogoś o sprawdzenie
16 kwietnia, 2008 o godzinie 13:32
jesteś bucem i słuchasz komy, pheop
16 kwietnia, 2008 o godzinie 14:00
Jeśli nie znasz tego powiedzenia zapraszam do:
http://en.wikipedia.org/wiki/All_your_base_are_belong_to_us
lub do google.com. Tytuł do czegoś nawiązuje i ma nawiązywać słowo w słowo…
16 kwietnia, 2008 o godzinie 15:43
No dobra, jestem bucem, ale komy nie słucham.
Dziękuję za link. Braki nadrobiłem i przepraszam za komentarz powyżej
17 kwietnia, 2008 o godzinie 15:00
No ba, nie wszyscy grają w ogame ;)
21 kwietnia, 2008 o godzinie 13:27
Szyfrowanie danych w bazach danych? Niby po co? Na wypadek kradzieży fizycznych nośników? Przerost formy nad treścią oraz niepotrzebna utrata wydajności podsystemu bazodanowego. Lepiej zadbać o odpowiedni dostęp fizyczny do serwerów – trzymanie systemów w monitorowanym 24/7/365 data center z prawdziwego zdarzenia, z wdrożoną polityką bezpieczeństwa.
Szyfrowanie danych w bazie nie uchroni nas przed wyciekiem danych w przypadku babola w aplikacji (no chyba, że aplikację obudujemy dodatkowymi warstwami logiki, co znowu będzie sprzyjać błędom).
Z całą resztą zgadzam, ale też nie do końca. IDS/IPS tak, różnego rodzaju logwatche również, regularne audyty też. Ale tak naprawdę nie spowoduje to, że nowo powstająca aplikacja/baza danych itd. będzie bezpieczna. Podstawa to szkolenia i uświadamianie pracownikom zagrożeń (szczególnie z prezentacją sytuacji z życia wziętych). W innym wypadku będziemy kręcić się w kółko, poprawiając za każdym razem te same błędy popełnione przez tych samych, niewyedukowanych użytkowników. Aż chce się rzecz „i tak do zaje…”. ;-)
25 kwietnia, 2008 o godzinie 01:30
Poprzez szyfrowanie miałem na myśli przechowywanie, na przykład haseł w postaci niejawnej – co niestety nadal ma miejsce w dużych serwisach.
O dostępie fizycznym pisałem jak i o szkoleniach, które masz rację najtrafniej uderzają, gdy są poparte przykładami z życia :]
Na pewno IPS nie sprawi, że baza będzie bezpieczna, ALE „może” sprawić, że będzie bezpieczeniejsza, będąc kolejnym małym klocuszkiem układanki.
Dziękuje za uwagi i podkreślam, że jest to jedynie kilka skrótowych uwag, które mogą pomóc, a nie jedyne i słuszne, najlepsze rozwiązania…