WWW.ehaker.pl
Łamanie haseł w Windows XP.
1. Wstęp
Przede wszystkim chciałbym zaznaczyć, Ŝe ani ja ani Random
Intruders nie ponosi odpowiedzialności za sposób w jaki wiedza
zawarta w tym tekście zostanie wykorzystana. Wszystkie
informacje z tego tutorialu maja słuŜyć jedynie celom
edukacyjnym.
2. Przedmiot Tutorialu
Głównym celem tego tekstu jest omówienie lokalnych sposobów
na zdobycie hasła administratora (i kaŜdego innego) posiadając
jedynie uprawnienia uŜytkownika lokalnego np. gościa lub nawet
Ŝadne. Tym optymistycznym akcentem rozpoczynam
opowiadanie bajki pt. "Jak to Microsoft radzi sobie z hasłami?".
3. Sposób przechowywania haseł
W systemach Windows95/98/Me hasła przechowywane są w
plikach .pwl, ale poniewaŜ nie są one w Ŝaden sposób chronione
a programów do ich łamania jest cale mnóstwo (choćby słynny
cain) to w tym tekście skupie się tylko na systemach z serii NT
czyli Windows NT/2k/XP/Server 2003. OtóŜ w tych systemach
hasła przechowywane są w pliku SAM znajdującym się (pod
warunkiem, Ŝe windows został zainstalowany w C:\WINNT) w
katalogu C:\WINNT\system32\config. Plik ten jest swego rodzaju
plikiem rejestru (cos jak plik system.dat w Win95/98/Me),
moŜna go zresztą przeglądać za pomocą edytora rejestru, ale
wymaga to uŜycia kilku sztuczek i jest całkowicie bezcelowe.
Podczas bootowania windowsa zanim uŜytkownik moŜe w ogóle
się zalogować do systemu główny watek programu Smss.exe
(Session Manager - MenedŜer Sesji) uruchamia proces
Winlogon.exe, gdyŜ jest on potrzebny by załadować Lsass.exe
(Local Security Subsystem - Lokalny Podsystem
Bezpieczeństwa), który następnie ładuje usługę SAM (Security
Accounts Manager - MenedŜer Kont Bezpieczeństwa), który jest
po prosu interfejsem dającym nam dostęp do bazy danych SAM.
Plik SAM nie przechowuje jednak samych haseł a jedynie ich
hashe, czyli wyniki działania jednostronnego (czyli
nieodwracalnego) algorytmu szyfrującego na hasłach. Kiedy ktoś
loguje się na komputer hasło, które wpisał zostaje zaszyfrowane
w ten sam sposób, a wynik (czyli hash) jest porównywany z
hashem z pliku SAM i jeśli są takie same uŜytkownik uzyskuje
dostęp do systemu. KaŜde hasło jest przechowywane na dwa
sposoby jako LM hash i jako NT hash, podczas gdy, NT hash jest
hashem naszego hasła to LM hash jest hashem naszego hasła
pisanego duŜymi literami. Oznacza to, ze dla haseł:
"Haselko","hAsElko", HaSeLkO",itp NT hash będzie inny, ale LM
hash będzie taki sam!!! Nie musze chyba tłumaczyć, jak
uŜyteczne jest to dla nas. MoŜliwe jest jednak wyłączenie przez
admina LM hashy i konieczne w takim wypadku jest łamanie NT
hashy, co znacznie utrudnia sprawę. Na szczęście zdarza się to
rzadko, a poza tym jeśli juŜ się zdarzy, to łamanie hashy nie jest
wtedy najlepszym pomysłem, wiec w tym tutorialu takiej sytuacji
nie zamierzam rozwaŜać. Oczywiście nie zalogujemy się do
systemu uŜywając hasła zdobytego łamaniem LM hash (chyba,
Ŝe hasło oryginalne tez nie składało się z małych liter). Jeśli
jednak dowiedzielibyśmy się, Ŝe nasz LM hash odpowiada np.
hasłu "HASELKO", to sprawdzenie kombinacji małych i duŜych
liter będzie juŜ tylko formalnością (i tak właśnie robią programy
łamiące LM hashe). Hasła w systemach WinNT nie mogą być
dłuŜsze niŜeli 14 znaków, juŜ Win2k dopuszcza dłuŜsze hasła (do
128 znaków), ale spójrzmy prawdzie w oczy, chyba nikt nie
uŜywa takich haseł;) Dlatego w tym tekście omówię jedynie
sytuacje gdy, hasło ma długość mniejszą lub równą 14 znaków.
Nie testowałem jeszcze Windowsa Server 2003, ale o ile mi
wiadomo jeśli chodzi o hasła to działa on na tej samej zasadzie
wiadomo jeśli chodzi o hasła to działa on na tej samej zasadzie
co XP. Zarówno LM hash jak NT hash zajmują 16 bajtów ja
jednak skupie się tylko na LM hashu, (dlaczego? Patrz wyŜej;))
OtóŜ jego pierwsze osiem bajtów odpowiada pierwszym siedmiu
znakom hasła, a drugie osiem bajtów drugim siedmiu znakom
hasła. Jeśli hasło jest krótsze niŜ 14 znaków, np. 10, to znowu
pierwsze osiem bajtów hashu odpowiada pierwszym siedmiu
literom naszego hasła, a pozostałe osiem bajtów odpowiada
pozostałym literom naszego hasła. Jeśli jednak hasło ma długość
krótszą lub równą 7 znaków, to po raz trzeci pierwsze osiem
bajtów hashu odpowiada literom hasła, a drugie osiem bajtów
będzie w tym przypadku zawsze równe 0xAAD3B435B51404EE.
Jeśli dane konto w ogóle nie posiada hasła, czy raczej posiada
hasło zerowej długości, to obie części hashu przyjmują tą
wartość. Czyli hash wygląda
tak:0xAAD3B435B51404EEAAD3B435B51404EE.
4. Zdobywanie hashy
Hashe moŜna zdobyć (lokalnie) na dwa sposoby. Pierwszy polega
na uŜyciu programu pwdump. Włączamy jedynie program, a on
wyświetla nam w oknie konsoli hashe. Jeśli wywołamy go Ŝe
znakiem przekierowania, czyli '>', np. "pwdump.exe >hash.txt".
To nasze hashe zostaną zapisane do pliku hash.txt. Jeśli uŜyjemy
jako parametr adres jakiegoś komputera np. "pwdump.exe
127.0.0.1", "pwdump.exe \\127.0.0.1" lub "pwdump
www.microsoft.com")) To pwdump spróbuje się połączyć z tym
komputerem i jeśli udostępnia on zdalnie swój rejestr, to
pwdump ściągnie z niego hashe. Niestety duŜym minusem tego
programu jest to, iŜ jest on z góry ustawiony na wyciąganie
hashy z systemów anglojęzycznych. Dzieje się tak, gdyŜ zakłada
on, iŜ grupa Administratorów ma angielska nazwę
"Administrators", na szczęście program nie jest ani szyfrowany,
ani spakowany (np. aspackiem, no przynajmniej wersja, która ja
posiadam). Dodatkowo za tekstem "Administrators" znajdują się
dwa bajty zerowe, podczas, gdy w operacjach na tablicach
znaków (tzn. tekstach) wymagany jest tylko jeden. MoŜemy wiec
śmiało zmienić 's' na 'z', a pierwsze zero na 'y' i juŜ mamy tekst
"Administratorzy", a pwdump działa:))) Jest to bardzo prosta
operacja edytorem szesnastkowym, wiec nie będę wdawał się w
szczegóły. Drugi sposób polega na wykorzystaniu programu
samdump. Program jest w stanie wydobyć hasła bezpośrednio z
pliku SAM. Wystarczy wiec skopiować ten plik z jakiegoś
komputera na dyskietkę i spokojnie w domciu uŜyć samdumpa z
tym plikiem jako parametrem np. "sampdump.exe a:\SAM". Jest
tylko jeden mały problem. Plik SAM jest chroniony przez system i
Ŝaden uŜytkownik nie ma do niego bezpośredniego dostępu
takŜe wszelkie próby jego odczytu, lub kopiowania zakończą się
niepowodzeniem. Na szczęście Windows w wielu sytuacjach (np.
przy instalacji) tworzy kopie tego pliku i znajduje się ona (pod
warunkiem Ŝe windows został zainstalowany w C:\WINNT) w
katalogu C:\WINNT\repair. Co więcej nie tylko członkowie grupy
Administratorzy (zazwyczaj), ale wszyscy uŜytkownicy maja
prawo do odczytu i kopiowania tego pliku. MoŜe się jednak
zdarzyć (a bardzo często tak właśnie jest), Ŝe dane zawarte w
tym pliku są nieaktualne. W takim wypadku pozostają nam dwa
wyjścia. Po pierwsze moŜemy uruchomić linucha jeśli taki jest w
komputerze lub skorzystać z jakiejś mini dystrybucji
dyskietkowej bądź pełnej płytowej np. KNOPPIX. To rozwiązanie
ma jeszcze jeden plus. Linux bez problemu czyta zarówno
partycje FAT32 jak i NTFS, ale zdaje sobie sprawę, Ŝe wielu ludzi
jest z linuchem na bakier wiec dla nich wytłumaczę inny sposób.
Uruchamiamy komputer w trybie MS-DOS (np. korzystając z
dysku startowego Win98). Jeśli system, z którego chcemy
wyciągnąć hashe został zainstalowany na partycji FAT32 to bez
problemu odnajdujemy katalog C:\WINNT\system32\config i
równie bezproblemowo kopiujemy z niego plik SAM. Jeśli
równie bezproblemowo kopiujemy z niego plik SAM. Jeśli
natomiast dany system został zainstalowany na partycji NTFS,
no to mamy problem, gdyŜ MS-DOS nie rozpoznaje tego
systemu plików (NTFS), wiec nie będziemy mieli dostępu do tej
partycji. W takim przypadku najlepszym rozwiązaniem jest
uŜycie programu ntfsdos. Postępujemy tak jak w przypadku
partycji FAT32, jednakŜe pierwsza rzeczą jaką robimy po
uruchomieniu MS-DOS'a jest uruchomienie programu ntfsdos
poprzez wpisanie po prostu "ntfsdos.exe", no jak ktoś się uprze
to moŜe sobie darować końcówkę ".exe". Następnie ntfsdos
poszuka wszystkich partycji NTFS i po kolei zamontuje je nam
jako normalne dyski MS-DOS. Wersja publicznie dostępna
pozwala jedynie na odczyt partycji NTFS, ale akurat nam to w
stu procentach wystarcza. Niestety zarówno program pwdump
jak i samdump nie dadzą nam poprawnych hashy jeśli system
ma SYSKEY'a.
5. Co to jest SYSKEY
OtóŜ Microsoft zrozumiał, Ŝe jak zwykle strzelił babola i poszedł
po rozum do głowy. Bardzo szybko wprowadził na rynek
poprawki sprawiające, iŜ tylko członkowie grupy
"Administratorzy" maja prawo odczytu całości rejestru, a wiec
równieŜ hashy. Program pwdump stal się wiec bezuŜyteczny. A
co gorsza dodatek Service Pack 3 (a co za tym idzie kaŜdy
następny (było ich w sumie 6)) do Windows NT wprowadził
aplikacje SYSKEY, potem juŜ Windows 2000, Windows XP i
Windows Server 2003 miały ta aplikacje instalowana domyślnie.
SYSKEY jest to skrót od System Key, czyli klucz systemu zwany
równieŜ Bootkey'em. Aplikacja ta tworzy podczas instalacji
unikalny dla kaŜdego systemu klucz, którym dla dodatkowego
bezpieczeństwa szyfrowane są hashe. Nie chce się wdawać w
szczegóły, gdyŜ myślę, Ŝe są one zbędne, ale dla ciekawskich
podam Ŝe jest to robione za pomocą algorytmów MD5 i RC4.
śeby było jeszcze ciekawiej klucz ten jest wybierany losowo i
nawet ten sam Windows instalowany na tym samym komputerze
będzie miał za kaŜdym razem inny klucz. CzyŜby to miał być juŜ
koniec?
6. Jak poradzić sobie z SYSKEY'em
Fakt faktem, ale ta zniewaga krwi wymaga:) A moŜe raczej
powinienem powiedzieć wymagała, gdyŜ na stworzeniu przez
Microsoft SYSKEY'a ta bajka się nie kończy. OtóŜ hakerzy z
całego świata postanowili go rozwalić powstawały roŜne pomysły,
miedzy innymi słynna juŜ linuxowska dyskietka, która potrafiła
nawet wyłączyć SYSKEY'a. Jednak kaŜdy kto ja przetestuje
szybko zauwaŜy, Ŝe do doskonałości "trochę" jej brakuje, wiec w
tym tekście nie będę jej omawiał. Pierwszym prawdziwym
zwycięstwem było stworzenie programu pwdump2. Działa on
analogicznie do swojej poprzedniej wersji, ale tylko na lokalnym
komputerze. Wykorzystuje on fakt iŜ SYSKEY'a moŜna obejść, a
co za tym idzie zdobyć czyste hashe za pomocą pewnych
wywołań API ale tylko jeśli jest się aplikacja lsass.exe, która to
właśnie zarządza hasłami, kontami itp. pwdump2 tworzy wiec
"zdalny" watek w lsass.exe, a ten watek ładuje bibliotekę
samdump.dll (dostarczana wraz z pwdump2), która to właśnie
omija (jako lsass.exe) SYSKEY'a i odczytuje nasze upragnione
hashe. Program pwdump2 ma tylko jedna wadę. PoniewaŜ
manipuluje on pamięcią (nie chce się wdawać w szczegóły;))
lsass.exe musi wiec posiadać przywilej debugowania tzw.
SeDebugPrivilege, Ŝadna aplikacja nie moŜe "otworzyć" procesu
o atrybucie systemowym (a takim przecieŜ jest lsass.exe;)) bez
tego przywileju. Tutaj właśnie pojawia się problem, gdyŜ ten
przywilej mają sobie (tzn. programom, które uruchamiają)
prawo przyznać tylko członkowie grupy "Administratorzy" Wiec
nam (przynajmniej w większości przypadków) się to w ogóle nie
przyda. Warty zainteresowania jest równieŜ program pwdump3
przyda. Warty zainteresowania jest równieŜ program pwdump3
pozwala nam on na zdobycie hashy Ŝe zdalnego komputera
dzieje się to następująco program łączy się serwerem za pomocą
protokółu SMB jeśli mu się to nie uda tzn., Ŝe z naszego
komputera jeszcze Ŝaden uŜytkownik posiadający na
atakowanym serwerze uprawnienia Administratora nie łączył się
z tym serwerem lub po prostu serwer nie udostępnia w ogóle
protokółu SMB, ale on jest domyślnie włączany gdy konfiguruje
się w Windowsie siec wiec nie mamy się o co bać;) Przykładowo
moŜemy program pwdump3 wywołać tak: "pwdump3 127.0.0.1
hash.txt Administrator" i prosi o hasło uŜytkownika. po
połączeniu wysyła na serwer pliki LsaExt.dll i pwservice.exe. I
następnie zdalnie uruchamia program pwservice.exe, który robi z
biblioteka LsaExt.dll prawie to samo co pwdump2 robił z
samdump.dll. Znowu jednak pojawia się problem znajomości
przynajmniej jednego hasła Administratora, nie mniej jednak
sam projekt jest ciekawy. Wspomnę jeszcze, Ŝe istnieje program
pwdump4, który jest jakby połączeniem pwdump2 i pwdump3,
nie będę go wiec opisywał, podam jedynie jak dla przykładu go
uzyc:"pwdump4 /l" - to samo co pwdump2, "pwdump4 127.0.0.1
/u:Administrator" - to samo co pwdump3. Dopiero jakiś rok
temu programistom udało się całkowicie złamać SYSKEY'a, a to
za sprawa aplikacji samdump2, bkhive i bkreg. Z tych trzech
praktycznie najmniej uŜyteczna jest aplikacja bkreg. Odczytuje
ona klucz systemu (tzw. Bootkey) z rejestru, a co za tym idzie,
działa tylko uruchamiana (za wyjątkiem niektórych wersji
systemu Windows NT) przez członków grupy "Administratorzy".
bkhive natomiast wyciąga klucz systemu z pliku system, który
moŜna znaleźć wszędzie tam gdzie plik SAM. Bkreg uruchamia
się np. tak: "bkreg key.txt". W tym momencie w pliku plik
key.txt w formacie hex zostaje zapisany klucz systemu. Bkhive
natomiast następująco: "bkhive jakaslokacja\system key.txt" i
znowu mamy Bootkeya w pliku key.txt. Następnie korzystamy z
programu samdump2, który jako parametry wykorzystuje
właśnie plik SAM i jakiś plik z naszym Bootkeyem, czyli np:
"samdump2 SAM key.txt". Nie będę tłumaczył, jak zdobyć plik
system, gdyŜ jak juŜ powiedziałem, jest on wszędzie tam, gdzie
plik SAM, a jego zdobywanie zostało bardzo szczegółowo
wyjaśnione w rozdziale czwartym - "Zdobywanie hashy", w
części poświeconej aplikacji samdump. Na koniec dodam tylko,
Ŝe pierwsze wersje czasami (ale to naprawdę sporadycznie) nie
potrafiły odczytać pliku SAM, ale autor bardzo szybko sobie z
tym poradził i teraz program działa bez zarzutu. Przynajmniej ja
nie miałem z nim Ŝadnego problemu. I tym optymistycznym
akcentem mamy gdzieś SYSKEY'a, a Bill Gates z całym jego
beznadziejnym Microsoftem moŜe się wypchać:)))
7. Łamanie haseł
No wreszcie mamy juŜ te hashe no i co my z nimi moŜemy
zrobić? OtóŜ hashe są zaszyfrowane algorytmem jednostronnym,
a co za tym idzie nie wydobędziemy z nich w Ŝaden sposób
haseł. No tak ale moŜemy sami cos szyfrować np. roŜne słowa i
sprawdzać, czy nasz hash nie odpowiada temu z pliku. I to
właśnie robią łamacze tych hashy. Najlepiej wykorzystać
program L0phtCrack. Ostatnia wersja, która posiadam, to 5 cos,
ale ja skupie się na wersji 2.5, gdyŜ po pierwsze ma bardzo
prosty i czytelny interfejs, podczas, gdy 3,4 i 5 maja naćpane
mnóstwo jakiś rysunków i innych pierdol, co mnie osobiście
niesamowicie wnerwia, ale to jest wynikiem prostego faktu.
Wersja 2.5 była jeszcze tworzona przez grupę l0pht, potem
jednak sprzedali oni prawa do programu i teraz kolejne wersje są
tworzone przez prywatna firmę. I tu pojawia się drugi powód, dla
którego wole 2.5 - sentyment;) Dlatego w tym rozdziale omówię
właśnie opcje tej wersji. UŜywanie opcji "Tools->Dump
Passwords from Registry", lub "File->Import SAM File...", jest
bezcelowe gdyŜ są to kolejno odpowiedniki programów pwdump i
bezcelowe gdyŜ są to kolejno odpowiedniki programów pwdump i
samdump, a my prawie na pewno mamy do czynienia z
SYSKEY'em najlepiej jest po prostu otworzyć plik stworzony
przez program pwdump2,pwdump3,pwdump4 lub samdump2 za
pomocą opcji: "File->Open Password File" Teraz najwaŜniejsza
rzecz to przede wszystkim skonfigurować program wybieramy
plik słownika: "File->Open WordList File..." Domyślnie program
dostarcza nam plik words-english.dic. Po drugie ustawiamy
metodę szukania: "Tools->Options..." zaznaczamy w polu
"Dictionanry Attacks" (czyli ataki słownikowe) tylko opcje
LANMAN, dlaczego tak robimy zostało wyjaśnione w rozdziale
trzecim - "Sposób przechowywania haseł", w polu
"Dictionary/Brute Hybrid" zaznaczamy "Enabled" i zostawiamy
(lub jeśli jej tam nie ma wpisujemy) dwójkę w polu "Characters".
Teraz program sprawdzi wszystkie słowa Ŝe słownika (tak na
marginesie, na końcu tego słownika dobrze jest dopisać juŜ
wcześniej złamane hasła, gdyŜ moŜe to nam w przyszłości
oszczędzić trochę czasu;)), a dodatkowo sprawdzi kaŜde słowo
Ŝe słownika z jeszcze dwoma znakami. Oznacza to, Ŝe np. jeśli
dodamy do słownika słowo Karol, to w ciągu paru sekund
program sprawdzi, czy hasłem nie jest np.: "Karol12","Karolfg",
"Karol98","Karol7z",itd. I ostatnia opcja w polu "Brute Force
Attack" zaznaczamy "Enabled" i teraz są dwie drogi albo od razu
ustawiamy opcje "Character Set:" na "A-Z,0-9", i program
sprawdzi, wszystkie hasła literowo-cyfrowe(ustawianie większej
ilości znaków jest w większości wypadków bezcelowe, a poza
tym za długo by to trwało;)). Lub tez moŜemy ustawić program
tylko na opcje "A-Z", a dopiero jeśli ona zawiedzie spróbujemy
"A-Z,0-9". W głównym oknie programu myślę, Ŝe wszystkie
kolumny są proste do zrozumienia dodam tylko, Ŝe jeśli przy
którymś z uŜytkowników w kolumnie "<8" jest x, to oznacza to,
iŜ jego hasło ma mniej niŜ 8 znaków, a jak program to określił
moŜna wyczytać w rozdziale trzecim - "Sposób przechowywania
haseł". Niestety wersja 2.5 ma z tym problemy, ale wersje 3,4 i
5 radzą sobie bezproblemowo. A dokładnie wersja 2.5 sprawdza
nasze hashe zakładając, Ŝe są one zapisane duŜymi literami
(hashe nie hasła), natomiast programy: pwdump2,pwdump3, i
samdump2 w przeciwieństwie do aplikacji pwdump (pwdump4
równieŜ) i samdump nie zwracają hashy duŜymi literami, lecz
małymi. Dla ciekawskich dodam, Ŝe porównywanie to ma miejsce
(dla wersji 2.5) pod adresami 0x4048e7 oraz 0x404dde
najlepszym rozwiązaniem (poza zmiana wersji) jest dodanie w
programie procedury sprawdzania hashy równieŜ małymi
literami. Na szczęście np. pod adresem 0x404ecc kompilator
pozostawił nam bardzo duŜo miejsca, wiec dodania takiego
porównywania nie nastręczy nam Ŝadnych problemów i wymaga
jedynie podstawowej znajomości asemblera, gdyby ktoś jednak
miął problemy, lub po prostu był tym zainteresowany, to mogę
dostarczyć odpowiedniego patcha. Co najciekawsze długość
hasła nie ma praktycznie wpływu na prędkość jego łamania. Po
prostu program łamie hasło na części. Dlaczego jest to moŜliwe
równieŜ jest wyjaśnione w rozdziale trzecim - "Sposób
przechowywania haseł". Dodam na koniec, Ŝe w kaŜdym
momencie moŜemy przerwać łamanie opcja "Tools->Stop
Crack", a po chwili je kontynuować lub korzystając z opcji "File-
>Save/Save as..." zapisać nasza sesje i wrócić do niej innym
razem, gdyŜ stworzymy tym sposobem plik "jakąś nazwa.lc", w
którym to zostaną zapisane dane dotyczące naszej sesji, co
więcej nie musimy się nawet tym za bardzo martwic, bo co ileś
minut (tak na wszelki wypadek) program zapisuje nasza sesje do
właśnie takiego pliku. Pliki .lc otwieramy tak samo jak pliki z
hashami. Nie wolno nam zmienić ustawień sesji, np. rodzaju
ataków lub szukanych znaków bo program zacznie łamanie od
początku. Teraz tylko włączamy "Tools->Run Crack" i idziemy
obejrzeć jakiś film, zjeść śniadanie/obiad/kolacje, do znajomych
lub spać. W kaŜdym razie musimy dać komputerowi trochę
czasu, gdyŜ juŜ niedługo wszystkie hasła z serwera będą
czasu, gdyŜ juŜ niedługo wszystkie hasła z serwera będą
nasze:)))
8. Game Over
No myślę, Ŝe nawet ktoś, kto nie miał wcześniej pojęcia o
windowsowskich hasłach po przeczytaniu tego tekstu uzna, Ŝe
chyba lepiej zmienić system na linuxa. Wydaje mi się, Ŝe w
windowsie najgorsze nie jest to, Ŝe do swoich systemów
wypuszcza on około 50 patchy rocznie, a z tego przynajmniej
część o charakterze krytycznym, a jego zabezpieczenia (np.
hasła) pozostawiają wiele do Ŝyczenie, ale to, Ŝe Microsoft
traktuje swoich klientów, w pewnym sensie, jak idiotów. Jeśli
wykryje on jakąś dziurę w swoich systemach (np. Microsoft
ASN.1 Library Length Overflow Heap Corruption), to doda tylko
jakąś łatę w ServicePacku, a nowsze wersje systemów będę jej
pozbawione, ale uŜytkownicy, o tej dziurze nigdy się nie
dowiedzą. Ale najgorsza jest chyba, zarozumiałość tej firmy. Na
swoich stronach informuje nas jedynie, iŜ patch X likwidujący
lukę Y to tylko latka, której niezainstalowanie moŜe spowodować
problemy z zabezpieczeniami. Ja uwaŜam, Ŝe podstawa
bezpieczeństwa, jest to iŜ, Administrator powinien mieć pełna
wiedze o systemie, którego uŜywa, powinien być w stanie (bez
znajomości języka niŜszego poziomu) sprawdzić swój system,
ocenić jego słabe strony, mięć pełna kontrole nad serwisami,
które uruchamia. W Windowsie natomiast dostajemy w prezencie
domyślnie wiele serwisów, a wyłączenie ich wszystkich zajmie
nam trochę czasu. Podczas, gdy np. Mandrake bez naszego
Ŝyczenia nic nam takiego nie zainstaluje, a nawet jeśli sami
zdecydujemy się na instalacje np. demona Apache, to
zostaniemy ostrzeŜeni piec razy, iŜ moŜe to być niebezpieczne, a
co chyba najprzyjemniejsze kod źródłowy jak Ŝubr jest "tuz za
rogiem" Podsumowując w Windowsie najgorszy nie jest sam
Windows,ale Microsoft. Ten system moŜe stać się w miarę
bezpieczny, (przynajmniej dla uŜytku domowego) ale jest to zbyt
trudne dla normalnego usera, oczywiście na tym polu Linux tez
nie jest doskonały, ale zmierza w dobrym kierunku, podczas gdy
Microsoft zamiast informować uŜytkownika o wszystkim, stara
się jak najwięcej przed nim ukryć. Komercjalizacja i monopol
jeszcze nigdy nie były źródłem dobrych rozwiązań. Mimo, iŜ teraz
rynek komputerów osobistych jest zdominowany przez
Windowsy, to uwaŜam, Ŝe w tej batalii zwycięstwo prędzej, czy
później odniesie Linux. No to jeśli chodzi o hasła, to juŜ koniec
gry. Morał z tej bajki jest taki: Czego by komercyjny Bill Gates z
całym jego Microsoftem nie wymyślił, to i tak to będzie za
mało:)))
9. Podsumowanie
Jestem świadom tego, iŜ mogą się pojawić opinie, Ŝe (conajmniej
w niektórych partiach) ten tekst jest pisany zbyt dokładnie i
pierdółkowo. Z góry powiem, Ŝe zgadzam się z tymi słowami, ale
chciałem napisać go tak, Ŝeby kaŜdy załapał, jak najbardziej
łopatologicznie, po prostu jak krowie na rowie:)))