W

szystkie firmy wydające własną dystrybucję (tj. zestaw programów rozpowszechnianych łącznie i dający po zainstalowaniu gotowy do użycia system) walczą o to, aby ich produkt był bezpieczny. Można stwierdzić, że każdy system jest na tyle bezpieczny, na ile odpowiednie środki zastosuje jego użytkownik. Wiele osób nie korzysta z dostarczonych im wraz z systemem metod zabezpieczania swoich danych. Największym problemem jest wyuczenie tej dyscypliny u użytkowników systemu. Kiedy istnieje przypadek, gdy obdarzamy swoim powszechnym zaufaniem wybraną dystrybucję, a ona zawodzi – rozpoczyna się przysłowiowe “polowanie na czarownice”. Wówczas twórcy, instytucje, programiści, autorzy oraz inne osoby odpowiedzialne za stworzenie samej funkcjonalności systemu stają się obiektem krytyki, zarzutów i ataków ze strony sfrustrowanej grupy użytkowników. Wykrycie luk w mechanizmach zabezpieczeń wywołuje dokładnie te same reakcje. Czy uzasadnione?
czytaj całość »

I

kto powiedział, że technika ułatwia życie? Dziś rano mój podręczny b-ticino otworzył okna sypialni i zapalił światło już o piątej rano. Jeden błąd w gadżecie i tracę pełną godzinę snu! (…)
czytaj całość »

Artykuł ten został opublikowany w numerze 2/2003 (2) magazynu hakin9.

Dnia 16 lipca 2003 polska grupa Last Stage of Delirium (w składzie: Michał Chmielewski, Sergiusz Fornrobert, Adam Gowdiak i Tomasz Ostwald) ogłosiła odkrycie groźnej dziury w systemach z rodziny Windows NT. W numerze 2/2003 ukazał się wywiad z członkami grupy.

Hakin9: W jaki sposób powstała Wasza grupa? Skąd się znacie, jak (i kiedy) wpadliście na pomysł założenia grupy? Kim jesteście, czym się zajmujecie poza działalnością hakerską?

Last Stage of Delirium: Nasza grupa powstała w roku 1996, kiedy wszyscy studiowaliśmy na pierwszych latach informatyki na Politechnice Poznańskiej. Wtedy tez pojawiły się pierwsze wspólne zainteresowania związane z szeroko pojętym bezpieczeństwem systemów informatycznych. Pomysł założenia nieformalnej grupy pojawił się niejako automatycznie, gdy zaczęliśmy coraz więcej pracować wspólnie nad rozwiązywaniem określonych problemów technicznych. Dzisiaj wszyscy pracujemy w zespole bezpieczeństwa tego samego centrum superkomputerowo-sieciowego (siedzimy w jednym pokoju :), gdzie zajmujemy się bezpieczeństwem infrastruktury informatycznej nauki oraz tworzymy rożnego rodzaju rozwiązania techniczne. W dalszym ciągu jednak działamy także jako grupa LSD, co staramy się oddzielać bezpośrednio od naszej aktywności zawodowej.

H9: Parę słów o samej dziurze Co to za dziura, jak się ją wykorzystuje, czym grozi? Czy rzeczywiście sprawa jest aż tak groźna? Co to oznacza dla przeciętnego użytkownika Windowsów? To znaczy: jeśli mam Windowsy zainstalowane prosto z CD i stałe łącze, to czy coś mi grozi?

LSD: Błąd ten jest naprawdę poważny, chociaż reakcja polskich mediów jest dla nas pewnym zaskoczeniem, na przykład w porównaniu chociażby do sprawy Argusa, która w Polsce była prawie całkowicie nieznana.

Znaczenie znalezionego przez nas błędu w Windows RPC oceniać można co najmniej w dwóch wymiarach, przy czym oba są dla nas równie istotne. Z czysto technicznego punktu widzenia, błąd ten jest pierwszym błędem umożliwiającym przeprowadzenie pełnego zdalnego ataku na system Windows 2003 Server. Jest to istotne zwłaszcza w kontekście inicjatywy Trustworthy Computing firmy Microsoft oraz dodatkowych mechanizmów zabezpieczeń, które zostały wprowadzone właśnie aby przeciwdziałać atakom związanym z przepełnieniem bufora.

Drugą istotną kwestią jest skala zagrożeń związanych z tym błędem. Dotyczy on systemów od Windows NT 4.0, przez 2000 i XP, aż po Windows 2003 Server. Podatne na ten błąd są więc nie tylko systemy typu server, ale także systemy typu workstation. W praktyce zwiększa to liczba podatnych systemów w Internecie z kilkuset tysięcy do kilkudziesięciu milionów.

Zagrożenia te są przy tym bardzo realne dla końcowego użytkownika. Błąd jest możliwy do praktycznego wykorzystania, co udowodniliśmy w naszych laboratoriach. Odpowiadając więc na pytanie: instalując dowolna wersje systemu Windows (z podatnych) na komputerze podłączonym do Internetu, natychmiast narażamy się na zdalny atak – użytkownik może przejąć pełna kontrolę nad nowym systemem.

H9: Jak znaleźliście tę dziurę? Czy mieliście dostęp do źródeł? Ile czasu Wam to zajęło? Czy pomógł wam przypadek, czy też szukaliście w konkretnym miejscu?

LSD: Błąd ten został znaleziony w ramach naszych prac nad systemami firmy Microsoft, które zaczęliśmy mniej więcej dwa lata temu. Oczywiście nie dysponowaliśmy źródłami, lecz wykorzystywaliśmy techniki inżynierii zwrotnej (ang. reverse engineering), w których mamy dość duże doświadczenie.

Naturalnie znalezienie każdego tego typu błędu wymaga odrobiny szczęścia, nie jest to jednak przypadek. Szukając błędów krytycznych z punktu widzenia bezpieczeństwa, analizowane są określone komponenty, w których z dużym znaczeniem błąd może okazać się możliwy do wykorzystania. Przykładem takiego komponentu jest właśnie interfejs RPC.

Podczas poszukiwania błędu znajduje się setki punktów, które potencjalnie mogą mieć takie znaczenie. Tylko niewielki procent tych błędów ma znaczenie w kontekście bezpieczeństwa, jeszcze mniejszą ich liczbę można wykorzystać w praktyce. Bardzo żmudna praca polega więc na weryfikacji tego typu potencjalnych punktów i określaniu, czy dany błąd stanowi zagrożenie praktyczne.

W tym przypadku okazało się, że błąd jest obecny we wszystkich kluczowych wersjach systemów Windows oraz jest możliwy do wykorzystania w każdym przypadku.

H9: Jak wygląda Wasza współpraca z Microsoftem? Jak firma zareagowała na informację o dziurze? Czy teraz otrzymacie od nich jakieś wsparcie – pieniądze, pomoc w dalszych badaniach?

LSD: Współpraca pomiędzy naszym zespołem i firmą Microsoft przebiegała bez większych problemów. Zespoły działające w ramach MSRC od samego początku zdawały sobie sprawę ze znaczenia i skali zagrożeń związanych z tym błędem. Przez mniej więcej tydzień pracowaliśmy nad szczegółami technicznymi błędu oraz technika jego wykorzystania. W ciągu kolejnego tygodnia inżynierowie Microsoftu opracowali poprawkę systemowa, która przetestowaliśmy.

Nie otrzymaliśmy żadnego wynagrodzenia od firmy Microsoft — tego typu pomysły zostały dopisane przez dziennikarzy. W ramach aktualnych praktyk współpracy pomiędzy odkrywca błędu i producentem oprogramowania nie przewiduje się żadnego rodzaju gratyfikacji finansowych.

H9: Jakiego systemu (jakich systemów) używacie sami — na co dzień?

LSD: Rożnych systemów. Na co dzień zajmujemy się systemami z rodziny Unix (takimi jak Solaris, Irix, Aix, HP-UX, SCO), open source (Linux, *BSD), ale także oczywiście systemami Windows.

H9: Kiedy ogłosicie szczegóły dotyczące znalezionej dziury?

LSD: Obecnie zaczynamy pracować nad szczegółowa analizę techniczna błędu oraz metod jego wykorzystania. Wyniki naszej pracy chcielibyśmy zaprezentować na konferencjach bezpieczeństwa jesienią i zimą tego roku, w tym samym mniej więcej czasie planujemy opublikować materiały.

H9: Czy działalność jako LSD przynosi wam dochody? Jak wygląda sprawa pieniędzy od Argus Systems?

LSD: Nie, działalność jako LSD nie przynosi żadnych dochodów, co jest pewnym ograniczeniem — z tego względu nie jesteśmy na przykład w stanie w wielu przypadkach uczestniczyć w konferencjach, jeżeli organizatorzy nie zapewniają dofinansowania podroży.

Firma Argus w dalszym ciągu nie wypłaciła nam blisko 45 000 USD, a póki co, wszelkie próby odzyskania pozostałej części nagrody na drodze prawnej zakończyły się niepowodzeniem.

K

ażdy szanujący się serwer powinien zawsze posiadać, dokładny czas charakterystyczny dla jego strefy czasowej. Dlaczego? Ponieważ korekcja zdarzeń zachodzących w serwerach może być czynnością żmudną, jeżeli występują różnice w czasie wskazywanym przez ich zegary. Synchronizacja zegarów może zaoszczędzić nam wiele cennego czasu podczas analizowania dzienników zdarzeń (mamy pewność, że zdarzenia zdarzyły się dokładnie o tej godzinie i minucie) po wykryciu próby włamania lub nawet podczas rozwiązywania codziennych problemów sieciowych.
czytaj całość »

(root@osiris ~)# uname -srmp
Linux 2.4.26 i586 Pentium_MMX
(root@osiris ~)# gcc --version
2.95.4

czytaj całość »

B

łędy typu buffer overlow (b0f) należą do błędów implementacyjnych – ponieważ są one nieuchronne. Wynika to z faktu, że żadna aplikacja z reguły nie może zostać przetestowana w sposób wyczerpujący. Błędy b0f były wykorzystywane od 1988 roku, kiedy pojawił się pierwszy internetowy robak Morris Worm, atakujący na całym świecie serwery Uniksowe na platformie VAX i Sun, działające pod kontrolą systemu BSD. Robak wykorzystywał m.in. błąd w usłudze finger w celu nadpisania bufora, zawierającego nazwę pliku lokalnego klienta finger. Autorem owego robaka był wówczas 23 letni Robert Tappan Morris uczęszczający na studia doktoranckie na wydziale informatyki Uniwersytetu Cornell (posiadał stopień magistra Uniwersytetu Harward). Lubił on wykrywać błędy w systemach operacyjnych, dlatego na jesieni 1988 roku zaczął pracę nad programem mającym na celu ukazanie wykrytych błędów w zabezpieczeniach systemu 4 BSD Unix.
czytaj całość »

Z

awsze są dwie strony medalu. Skanery to bardzo przydatne narzędzia bezpieczeństwa, ale mogą zostać użyte w złym zamiarze – pozwalają na szybką ocenę słabości systemu. Dlatego przedmiotem tego artykułu jest program PortSentry autorstwa Craiga H. Rowlanda z dawnej firmy Psionic Software. Był on częścią pakietu oprogramowania Abacus do ochrony systemu przed włamaniami (aktualnie jest on rozwijany wyłącznie przez jego autora). PortSentry jest to zaawansowane narzędzie, do monitorowania, którego działanie nie mieści się w wąskiej definicji skanera portów, lecz wykrywania skanowania portów systemów i odpowiednie reagowanie.
czytaj całość »