.:: strefa ::. - Bezpieczeństwo

Gra Anti-Phishing Phil

nospam@example.com (Marcin Guzowski) — Thu, 27 Sep 2007 11:55:25 +0200

W sieci pojawiła się gra Anti-Phishing Phil, której celem jest edukowanie internetautów w zakresie rozpoznawania ataków typu phishing (czyli praktycznie rzecz ujmując - oszukańczego sposobu pozyskiwania informacji poufnych m.in. przy zastosowaniu spreparowanej strony www). Gra jest przeznaczona zwłaszcza dla osób rozpoczynających przygodę z World Wide Web, które często mają problemy z oceną wiarygodności odwiedzanych witryn internetowych. Jedynym mankamentem może się okazać wersja językowa (angielska), gdyż niejednokrotnie początkującym w obsłudze komputera daleko do swobodnego posługiwania się językiem angielskim. Mimo to na pewno warto promować tego typu inicjatywy.

Więcej informacji:
Zagraj w Anti-Phishing Phil

Generator silnych haseł

nospam@example.com (Marcin Guzowski) — Sun, 29 Jul 2007 22:15:00 +0200

Zacząłem ostatnio pisać pewien artykuł dla magazynu security-related o atakach na hasła i kwestiach związanych z bezpieczeństwem haseł - tak dla odmiany, żeby nie siedzieć ciągle w rozwiązaniach bazodanowych :) Przy okazji zagłębiania się w tematykę, napisałem prosty generator losowych silnych haseł. Udostępniłem go pod adresem http://guzowski.info/passgen,pl (link jest dostępny także z mojej strony domowej). Czasem trudno zebrać myśli, żeby wymyślić jakieś dobre hasło, może więc mój generator komuś się przyda. Potrafi generować określoną liczbę haseł o zadanej długości, łańcuchy znaków budowane są w sposób zgodny z większością zaleceń dotyczących tworzenia silnych haseł.

Więcej informacji:
Marcin Guzowski - strona domowa

Słabość mocnych haseł

nospam@example.com (Marcin Guzowski) — Thu, 01 Mar 2007 19:24:00 +0100

Hasła są jedną z najstarszych i najbardziej popularnych metod uwierzytelniania w systemach komputerowych, ale także i w systemach nieinformatycznych. Wszelkiego typu klucze znakowe, tajne słowa, PINy itp. to często jedyne zabezpieczenie systemu przed niepowołanym dostępem. Z tego właśnie powodu przykłada się do nich duże znaczenie i zaleca się, żeby jedynym miejscem ich składowania była pamięć osób uprawnionych (a nie żółta karteczka naklejona na monitorze).

Od lat funkcjonuje pojęcie tzw. słabych haseł (weak passwords), którym określa się hasła bardzo podatne na złamanie (metodą słownikową lub brute-force). Chodzi oczywiście o krótkie łańcuchy znaków, często będących imieniem, nazwiskiem danej osoby itp. Jako przeciwieństwo haseł słabych wprowadzono termin haseł mocnych (strong passwords), czyli najlepiej takich, których... w ogóle nie da się zapamiętać i trzeba je zapisać na żółtej karteczce :) Oczywiście intencjonalnie ironizuję, ale ilość haseł, którymi bombarduje się przeciętnego użytkownika - nie mówiąc już o administratorze czy deweloperze - jest coraz większa. Stawia się także coraz większe wymagania co do jakości haseł, m.in. głosząc postulat losowości i odpowiedniej ilości znaków. Prosty przykład: jeszcze kilka lat temu spora część specjalistów była w stanie uznać prawidłowo sformułowane hasło 8-znakowe za dostatecznie mocne. Dziś w programie TrueCrypt (pisałem o nim jakiś czas temu) spotykamy się z zaleceniem, żeby używać haseł dłuższych niż 20 znaków. Ta tendencja jest nieodwracalna, gdyż wraz z gwałtownym wzrostem mocy obliczeniowej systemów komputerowych, moc wszystkich haseł na świecie równie gwałtownie maleje.

Interesującą wielkością jest przeciętna ilości haseł przypadająca na jednego użytkownika. Zakładając, że do każdego systemu uwierzytelniającego stosować będziemy oddzielne hasło (a jest to jedyne rozsądne założenie), można szybko dojść do ciekawych wniosków. Zastanowiłem się na swoim przykładzie i policzyłem, że muszę pamiętać około 40 haseł (do kilku komputerów, kont pocztowych, serwerów w pracy, kont FTP, partycji szyfrowanych, kont bankowych i systemów innych instytucji, komórki, bloga i innych stron itd.). Warto zaznaczyć, że często nie wystarczy zapamiętanie samego hasła, gdyż konieczne jest również dysponowanie dodatkową informacją - identyfikatorem, numerem klienta (który sam w sobie jest przecież czymś w rodzaju hasła sensu largo). Jeżeli uznamy, że długość bezpiecznego hasła zaczyna się od 15 losowych znaków (małe/duże litery, cyfry i znaki niealfanumeryczne) i wykonamy następujące działanie:

40 x 15 = 600

to otrzymamy, że przeciętnie człowiek z IT powinien zapamiętać 600 znaków czegoś, czego nawet nie da się fonetycznie wymówić, a co wygląda mniej więcej tak:

suA(knAeFfroO4tADhLe2TapoIoL2eGSspU/SpagRnEi?TueMneG?laPsNd
teN@OfeVDur7WaiHudYu1OydyAeC*AsFiG?IllSwuBu^yoUaSSwu,zArAlD
muN{LuneGOe/jeLMuRas8GybiLOe|oWAoR5VoTeeEx2fIOduT(tHrHAs=th
pY9RudIefF,bUpRiYe~LoqnUlRat*GadLoe)dEdwAtuR!zUaCyfO8alFeNg
Oc9oOcAnhY?lUrSlpUm]aMnAsiblO3yANu|NuviLEj~sKgIggEo.EanAupU
sN*nOxzURa4XyLyaC(twOtOgSad/oYheKa.SlIrexI@DefStIc0SexmNiV!
pLo6aToSmaAxi#vUsiBnE^tSdUbiA8PaRe6fLdAgsU|tWiNwsP.rIiASy}S
Fae[nyLVogzI=IgiCpIp6AgopHorA"MudH0BifJVor@AlywHRut9OvafIjA
Pas(AwJaMou9FugclOZl9aBiNaFl!dObfUn!AbSfcZa{caLnOsL!NumFoas
nOb1tSnaMpY.qUoMTr@hIrrEeoP=EnrdDw0oTPilsP*VigPtsiN^leVyOoF

Problem z ilością haseł jest więc całkiem spory. Oczywiście wypracowano różne metody, by zminimalizować jego oddziaływanie. Jedni stosują w swoich hasłach część stałą dla wszystkich haseł i część zmienną - niepowtarzalną. Nie jestem jednak pewien czy jest to w wypadkowym rozrachunku opłacalne. Nie ułatwia to jakoś zasadniczo zapamiętywania, a znacznie osłabia moc hasła. Innym pomysłem również nie pozbawionym wad jest przechowywanie wszystkich haseł w zaszyfrowanym pliku i pamiętanie wyłącznie silnego hasła szyfru. Ujawnienie tego hasła ma jednak kolosalne konsekwencje, nie polecałbym więc stosowanie tego rozwiązania zbyt intensywnie. Nie polecam również zapamiętywania haseł w programach (np. przeglądarkach), choć w przypadku mniej ważnych haseł może to być akceptowalne. Najrozsądniej jest opracować we własnym zakresie pewien prywatny system tworzenia i kojarzenia haseł, gdzie poszczególne jego fragmenty zależne będą od np. aktualnego miesiąca, nazwy systemu i danych znanych wyłącznie nam. Całość musi być oczywiście odpowiednio wkomponowana w elementy czysto pamięciowe, aby złamanie jednego z naszych haseł nie ułatwiało złamania pozostałych.

Kiedyś uczestniczyłem w pewnym projekcie, którego głównym celem było rozwijanie stricte webowego portalu dla ograniczonej grupy użytkowników (forum, zasoby wewnętrzne, private messaging itp.). Uwierzytelnianie opierało się oczywiście na dedykowanych hasłach dostępowych. Jako administratorzy postanowiliśmy swego czasu rejestrować hasła podawane podczas nieudanych prób logowania. Oczywiście najczęstszym przypadkiem były drobne literówki w hasłach, jednak wcale nie rzadko użytkownicy wprowadzali łańcuchy znaków zupełnie odmienne od ich haseł w systemie. Jak się później okazało, były to hasła do innych systemów - najczęściej do kont pocztowych... Od tamtego czasu zawsze staram się podkreślać, że zanim zaczniemy wprowadzać do jakiegokolwiek systemu nasze hasło, zastanówmy się dwa razy, czy jest ono przeznaczone rzeczywiście dla niego.

Ostatnią kwestią, którą chciałbym tutaj poruszyć, jest częstotliwość zmiany haseł. Każde hasło można złamać (odgadnąć) - to tylko kwestia czasu odwrotnie proporcjonalnego do mocy obliczeniowej, jaką się dysponuje. Oczywiście inny jest poziom trudności odgadywania hasła w zdalnym systemie informatycznym, gdzie system może bronić się przed atakami blokując dostęp dla hosta po X nieudanych próbach logowania, a inna - jeżeli chodzi np. o hasło do zabezpieczonego archiwum z danymi. Z punktu widzenia właściciela hasła, całą sytuację da się jednak zredukować do swoistego wyścigu, w którym jakiś byt próbuje odgadnąć hasło, a my musimy okresową zmianą hasła zmuszać go do tego, aby zaczynał od początku. Oczywiście także i niedawno zmienione hasło może zostać szybko złamane. Wszystko w bezpieczeństwie jest kwestią prawdopodobieństwa i analizy zagrożeń, a z tego punktu widzenia zmiana hasła przynajmniej raz na miesiąc wydaje się całkiem rozsądną ucieczką do przodu.

TrueCrypt: wygodna poufność danych

nospam@example.com (Marcin Guzowski) — Mon, 05 Feb 2007 22:28:00 +0100

W dzisiejszym świecie ochrona informacji przed niepowołanym dostępem staje się tematem coraz bardziej doniosłym. Twórcy oprogramowania oczywiście dostrzegają ten trend, oferując całkiem spory i różnorodny wachlarz rozwiązań z tego zakresu. Sprawne poruszanie się w tematyce bezpieczeństwa systemów komputerowych, ochrony informacji, kryptografii itp. wymaga posiadania ugruntowanej wiedzy - co często powoduje, że osoby nie związane zawodowo z security rezygnują z tego typu nowinek. Jak postaram się niżej pokazać - rezygnacja ta nie jest wcale konieczna.

Chciałbym zaprezentować jedną konkretną aplikację, która ze względu na szereg cech wydaje mi się najbardziej godną uwagi propozycją dla osób o różnym zaawansowaniu (zwykli użytkownicy, power users, administratorzy) zainteresowanych możliwością realnego zabezpieczenia poufnych danych. Chodzi o opensource'owy program TrueCrypt (linki do strony domowej poniżej), który dostępny jest w wersjach zarówno pod Microsoft Windows, jak i Linux. TrueCrypt należy do gatunku aplikacji szyfrujących dane w locie (on-the-fly encryption). Program tworzy specjalny wirtualny dysk (virtual encrypted disk), na którym wszystkie dane przechowywane są w postaci zaszyfrowanej. Wolumen taki - po zamontowaniu przez TrueCrypt - jest przez system widziany jak każda inna jawna partycja. Pracujący w tray'u TrueCrypt pośredniczy w wymianie danych między zaszyfrowaną partycją a systemem operacyjnym - szyfrując lub deszyfrując dane w zależności od kierunku komunikacji. Całość operacji kryptograficznych odbywa się na bieżąco w pamięci RAM.

Zaszyfrowane wirtualne dyski to w rzeczywistości albo standardowe pliki w systemie plików (z niestandardową zawartością), albo pełnowartościowe partycje dyskowe. W pierwszym przypadku TrueCrypt montuje wirtualną partycję z zaszyfrowanej zawartości pliku, w drugim - z fizycznej partycji zawierającej specjalną strukturę z zaszyfrowanymi danymi. W przypadku ostatnim pewnym problemem jest fakt, że system operacyjny widzi dwie partycje - zaszyfrowaną i odszyfrowaną (zamontowaną przez TrueCrypt). O ile w przypadku odszyfrowanej nie ma problemów z interpretacją systemu plików, o tyle partycja zaszyfrowana jest dla systemu operacyjnego zupełnie niezrozumiała i prawdopodobnie będziemy zasypywani propozycjami jej formatowania (opracowano oczywiście pewne środki zaradcze, aby sytuacja nie była uciążliwa).

Z punktu widzenia użytkownika najistotniejszym momentem całej układanki jest montowanie wirtualnego dysku z zaszyfrowanego źródła (np. plikowego). Do wykonania tej operacji TrueCrypt wymaga podania dedykowanego hasła montowania ustalonego podczas tworzenia zaszyfrowanego wolumenu.

Podczas tworzenie zaszyfrowanego wolumenu użytkownik konfiguruje typ kontenera (plikowy vs partycja dyskowa), rozmiar, system plików - jaki ma naśladować zamontowany wirtualny dysk (NTFS, FAT), wybierany jest także algorytm szyfrujący i algorytm funkcji skrótu. Mamy do dyspozycji najmocniejsze i najszybsze algorytmy szyfrujące:
- AES
- Blowfish
- CAST5
- Serpent
- Triple DES
- Twofish
- Cascades

oraz algorytmy hashujące:
- Whirlpool
- RIPEMD-160
- SHA-1

Program umożliwia automatyczne przetestowanie wszystkich algorytmów w danym systemie pod kątem wydajności - łatwo możemy więc wybrać np. najszybszy z dostępnych. Oczywiście procesy szyfrowania/deszyfrowania należą do ciężkich obliczeniowo, ale na stosunkowo nowej maszynie opóźnienia z tym związane są dla przeciętnego użytkownika praktycznie niezauważalne.

Autorzy TrueCrypt opracowali i zaimplementowali dodatkowo bardzo ciekawą funkcjonalność, tzw. ukryty wolumen (hidden volume). Doszli do wniosku, że w niektórych sytuacjach właściciel zaszyfrowanych danych może zostać zmuszony do ujawnienia hasła montowania (np. poprzez zastosowanie przemocy fizycznej). Możliwe jest więc tworzenie zaszyfrowanego wolumenu w innym zaszyfrowanym wolumenie. Pierwszy (wewnętrzny) przechowuje dane, które użytkownik rzeczywiście chce ukryć. Zajmuje on wolny obszar wolumenu drugiego (zewnętrznego). Aby rozwiązanie miało sens, obydwa magazyny muszą mieć różne hasła montowania. W wolumenie zewnętrznym zaleca się umieścić dane wyglądające na ważne i poufne. W sytuacji kryzysowej ujawnione zostanie tylko hasło montowania do wolumenu zewnętrznego. Istnienie wolumenu wewnętrznego jest niewykrywalne nawet po zamontowaniu wolumenu zewnętrznego, gdyż każdy magazyn podczas tworzenia w całości wypełniany jest losowymi danymi. Utrata poufności dotknie więc tylko dane "podstawione" - tym samym realnie chronione informacje mają dużo większą szanse pozostania nieujawnionymi.

Myślę, że zagłębianie się w szczegóły implementacyjne byłoby tutaj bezcelowe, acz warto podkreślić, że autorzy mieli szereg bardzo ciekawych i skutecznych pomysłów. Wykorzystali również sprawdzone rozwiązania opracowane wcześniej (choćby generator praktycznie silnych liczb losowych Petera Gutmanna). Wszystkie szczegóły wraz z kodem źródłowym i dokumentacją techniczną dostępne są na stronie projektu. Na pochwałę zasługuje też bardzo intuicyjne i wygodne GUI. Nic więc dziwnego, że TrueCrypt może się pochwalić wierną rzeszą entuzjastów. Warto też zaznaczyć, że zaszyfrowane wolumeny TrueCrypt są całkowicie cross-platformowe.

Oczywiście prezentowane przeze mnie rozwiązanie ma pewne słabości. Można tu wskazać problem incydentalnego zapisu niezaszyfrowanych poufnych danych do pliku stron - choć w tym przypadku da się zagrożenie wyeliminować przez włączenie opcji no paging file w systemie Windows. Problemem może być także hibernacja czy np. informacje o montowanych partycjach zapisane przez system w rejestrze. Nie są to duże issues i według mnie finalna analiza zagrożeń wypada dla TrueCrypt bardzo korzystnie. Należy jednak pamiętać, że przecież nie ma zabezpieczenie idealnego.

Więcej informacji:
TrueCrypt - strona domowa

hack..ed.pl i drugie dno

nospam@example.com (Marcin Guzowski) — Thu, 11 Jan 2007 11:20:00 +0100

W jednym z poprzednich postów pisałem o sytuacji, w której serwis hacking.pl wywołał mniejsze czy większe poruszenie związane z niskim poziomem zabezpieczeń znanego systemu aukcyjnego Allegro.pl. Później, o czym już z braku czasu nie pisałem, podobny scenariusz był realizowany w odniesieniu do mBanku, acz ze względu na specyfikę problemu odbyło się to w mniej widowiskowy sposób. Jak podaje serwis IDG.pl w swojej wiadomości, wczoraj w późnych godzinach wieczornych - o ironio - to hacking.pl stał się ofiarą wrogiego wykorzystania luk w bezpieczeństwie. IDG.pl określiło zdarzenie jako kompromitację. Może i jest to uzasadnione w świetle ostatnich publikacji dotyczących Allegro.pl i mBanku, jednak podobne przejęcie tej strony ma miejsce średnio co kilka miesięcy, więc nie używałbym tutaj zbyt mocnych słów :) W momencie, w którym powstał ten wpis, serwis hacking.pl nadal nie funkcjonuje (wyświetlane jest jedynie logo). Do niedawna na stronie widniało:

own3d by kotecek
THERE IS A NEW ROOT IN TOWN AND WHAT WAS ALL THAT CHROOTING FOR?
Plik shadow
http ://platyna.platinum.linux.pl/gorion/
http ://memoires.viedzma.pl/2006/12/
Gr33tZ to:
#chcialbym_byc_jak_gorion
#linux-slackware2
Baseciq
viedzma

Cała sprawa ma jednak drugie dno, które chciałbym skomentować.

Każdy, kto choć trochę obserwuje środowisko security related w Polsce, bez wątpienia dojdzie do wniosku, że przejęcie hacking.pl to reakcja na "popis" Pawła "Goriona" Jabłońskiego w telewizji TVN z topornego gatunku "hakowanie na ekranie". Kto ma inne zdanie, niech poczyta informacje zawarte w linkach z powyższego listingu. Nie chcę tutaj oceniać występu telewizyjnego, gdyż go nie widziałem. Nie chcę też oceniać reakcji społeczności, choć po przeczytaniu pewnych informacji (o ile oczywiście są prawdziwe) - znajduję dla niej pewne zrozumienie :) W każdym razie to, co teraz można obserwować, to klasycznie piękna eskalacja konfliktu jednego człowieka i pewnej grupy ludzi. Obydwie strony będą w tym momencie umacniać swoje pozycje, gdyż atrakcyjna jest zarówno rola buntownika i samotnego wojownika, jak i działające integrująco posiadanie wspólnego wroga czy napiętnowanie "czarnej owcy". Wśród osób z większym dystansem do całej sprawy nie brakuje komentarzy, że obie strony zachowują się po prostu dziecinnie... Pewnie coś w tym jest, choć trudno oceniać emocje, które każdy przeżywa w sobie tylko znany sposób. I to właśnie obserwacja zachowań ludzi podyktowana tymi emocjami wydaje mi się w tej całej sprawie najciekawsza - gdyby nie to, opisywane zdarzenia nie zasługiwałyby na większą uwagę.

Niebezpieczne Allegro

nospam@example.com (Marcin Guzowski) — Tue, 19 Dec 2006 23:11:00 +0100

Polski internet obiegła informacja o fatalnym stanie zabezpieczeń znanego serwisu aukcyjnego Allegro.pl. Od jakiegoś czasu krążyły mniej czy bardziej jednostkowe informacje o możliwości skutecznego zastosowania stosunkowo prostych technik typu Cross Site Scripting i przejmowanie sesji do pozyskania danych osobowych i kont dowolnych użytkowników. Szeroką dyskusję na temat zagrożeń i niebezpieczeństw związanych z takim stanem rzeczy swoją publikacją wywołał serwis hacking.pl.

Allegro.pl nie ustosunkowało się jeszcze do zarzutów dotyczących poziomu zabezpieczeń, ale zapowiedziało przerwę w dostępie do usługi - jednak dopiero w nocy ze środy na czwartek 20/21 grudnia między 1:00 a 2:00. Można przypuszczać, że przedstawiciele Allegro.pl będą usiłowali maksymalnie zbagatelizować informacje o zagrożeniach - m.in. możliwości wycieku danych osobowych.

Więcej informacji:
hacking.pl: Allegro milczy i zapowiada przerwę techniczną
itbiznes.pl: Allegro dziurawe jak szwajcarski ser?

Bezpieczeństwo kodu źródłowego

nospam@example.com (Marcin Guzowski) — Sat, 11 Nov 2006 14:36:00 +0100

Platforma .NET dostarcza deweloperom wielu nowych możliwości, ułatwień i ulepszeń, także w aspekcie bezpieczeństwa - zwiększając tym samym ochronę szeroko pojętych dóbr intelektualnych. Współczesne organizacje poświęcają wiele energii dbając o to, by określona informacja nie dotarła do osób niepowołanych. Stosowane są zaawansowane metodyki bezpieczeństwa, szyfrowanie, ścisła identyfikacja zasobów, firewalle itd. Tymczasem dając użytkownikowi do ręki skompilowaną do kilku plików DDL i pliku EXE aplikację .NET - dajemy mu jednocześnie na talerzu co najmniej jej algorytmiczne tajemnice, a często także szereg innych cennych informacji.

Wszystkie .NETowskie asemblacje objęte są tzw. mechanizmem reflection, który jest interfejsem do pozyskania szczegółowych metainformacji dotyczących wszystkich klas w danej assembly. To cena, jaką płacimy m.in. za intellisense w Visual Studio.

Wprawdzie self-desribing assemblies nie ujawniają własnego kodu MSIL (Microsoft Intermediate Language), jednak droga do jego pozyskania dla amatorów cudzego kodu źródłowego jest banalnie prosta. Jeszcze łatwiej natomiast zamienić instrukcje języka pośredniego na kod języka wyższego poziomu - C#, VB.NET czy managed C++. Razem z .NET Framework dostarczany jest IL Assembler - to oczywiste. Być może mniej oczywisty jest fakt, że wraz z .NET Framework SDK (dołączonym m.in. do Visual Studio), dostarczany jest także IL Disassembler. Wystarczy więc uruchomić plik lidasm.exe i już mamy okienkowy interfejs prowadzący wprost do kodu pośredniego dowolnej aplikacji .NET, nie robiąc przy tym kompletnie nic nielegalnego. IL Disassembler jest jednak troszkę toporny, w końcu dlaczego nie mielibyśmy od razu otrzymać kodu w dowolnym języku wyższego poziomu (do wyboru), wraz z całą hierarchią obiektów, typami, metodami w przyjaznym dla oka GUI? Nic bardziej prostszego, programów tego typu jest całkiem sporo. Wystarczy polecić Lutz Roeder's .NET Reflector (strona domowa). Na życzenie program ten wygeneruje nam w pełni funkcjonalny projekt, który natychmiast możemy otworzyć w Visual Studio.

Okrutna prawda jest taka, że każdy program można poddać mniej lub bardziej skutecznej disasemblacji, przy czym jest to o wiele trudniejsze w przypadku binarki Win32, a o wiele łatwiejsze w przypadku aplikacji .NET (analogicznie: Javy czy Perla). Potwierdza to starą zasadę, że nie ma zabezpieczenia, którego nie dałoby się złamać. Jedyne co można zrobić, to maksymalnie utrudnić reverse engineering, mając nadzieję, że skutecznie zniechęci to ewentualnych zainteresowanych. Jeżeli już musimy udostępnić komuś bezpośrednio skompilowany program, to zadbajmy chociaż o maksymalne "zaciemnienie" jego kodu źródłowego. Można użyć do tego celu jednego z powszechnie dostępnych obfuscatorów, np. programu Dotfuscator (strona domowa, polecany przez Microsoft). Kod źródłowy zostanie wtedy odpowiednio zmodyfikowany: obfuscator zamieni nazwy zmiennych, obiektów, metod na niezrozumiałe dla człowieka sekwencje znaków, zaszyfruje wartości stringów, zastosuje instrukcje goto utrudniające zrozumienie kolejności instrukcji itp. Oczywiście wszystkie wymienione czynności nie będą wpływały na efekt działania skompilowanej aplikacji, chodzi tylko o jak największe skomplikowanie analizy kodu pozyskanego przez disasemblację. Trzeba jednak od razu zaznaczyć, że istnieje co najmniej kilka deobfuscatorów, które potrafią przywrócić kod do całkiem czytelnej formy...

Szczerze mówiąc, nie ma dobrej metody na ochronę kodu aplikacji .NET, jeżeli fizycznie przekazujemy skompilowany program osobie trzeciej. Trzeba mieć to na uwadze projektując rozwiązania z zastosowaniem tej technologii. Nie zawsze jednak sytuacja wymaga takiego kroku - wtedy otwiera się obszar dla zastosowania technologii webowej lub usług terminalowych. Może i są to rozwiązania mniej wygodne dla użytkownika, ale nie ma przecież nic za darmo.

Windows XP: uzyskiwanie uprawnień systemowych

nospam@example.com (Marcin Guzowski) — Wed, 04 Oct 2006 21:01:00 +0200

W systemie Windows XP do uzyskania uprawnień systemowych (większych niż uprawnienia administratora systemu) można wykorzystać możliwości, jakie daje harmonogram zadań (task scheduler). Jeżeli po wydaniu w shellu komendy at nie uzyskamy komunikatu odmowy dostępu, system jest prawdopodobnie podatny na eskalowanie uprawnień do poziomu systemowego. Podatność w konkretnym przypadku zależy od zainstalowanych poprawek i poziomu dostępu konta, z którego wykonywana jest próba.

Opisywana podatność wynika z faktu, że usługa harmonogramu zadań działa na koncie systemowym (Local system account), więc w tym kontekście uruchamiane są wszystkie harmonogramowane zadania. Wydanie polecenia:

at 00:00 /interactive "cmd.exe"

sprawi, że o żądanym czasie (odpowiednio dobranym, by stało to się szybko po wydaniu powyższego polecenia) zostanie odpalona powłoka. Co ciekawe, na pasku tytułowym nie będzie widniało "cmd.exe", tylko "svhost.exe" (Service Host), czyli shell zostanie uruchomiony w "trybie roota", używając analogii *nixowej. Teraz wystarczy zabić proces explorer.exe i wydać z powłoki systemowej polecenie:

explorer.exe

Efekt będzie identyczny, jakbyśmy zalogowali się na konto "SYSTEM".

W związku z powyższym zaleca się:

1. wyłączenie usługi harmonogram zadań - jeżeli nie jest używana
2. skonfigurowanie usługi na działanie na nisko uprzywilejowanym koncie

Więcej informacji i dokładny opis krok-po-kroku: kliknij tutaj

Cebulowa anonimowość

nospam@example.com (Marcin Guzowski) — Wed, 27 Sep 2006 18:17:05 +0200

W poprzednim wpisie napisałem o przeglądarce umożliwiającej anonimowe przeglądanie stron dzięki sieci Tor. Możliwości Tor`a się na tym jednak nie kończą i myślę, że warto przybliżyć samą ideę.

Tor (the onion routing) - to działająca w dużym rozproszeniu sieć hostów węzłowych, które w losowej kombinacji uczestniczą w połączeniu komputera źródłowego i docelowego - zastępując tym samym bezpośrednie połączenie tych komputerów. Tzw. trasowanie cebulowe (ang. onion routing), czyli przesyłanie informacji w sieci Tor, zapewnia anonimowość inicjatorowi połączenia TCP. Kluczem do tego jest taka konstrukcja systemu, że żaden z węzłów sieci Tor nie może znać całej ścieżki utworzonego ad hoc obwodu - widzi tylko noda, od którego otrzymał pakiet. Pierwszy z nodów obwodu komunikuje się z komputerem źródłowym, a ostatni - z docelowym, czyli np. serwerem www czy serwerem pocztowym. Dodatkowo transmisja w ramach sieci Tor jest szyfrowana, a trasa przejścia (obwód) zmieniana jest co 1 minutę.

Należy pamiętać, że Tor nie jest środkiem zapewniającą pełną anonimowość - co prawda sprytnie zabezpiecza komunikację na warstwie transportu, ale do anonimowości pozostaje jeszcze warstwa aplikacyjna i warstwa zdrowo-rozsądkowa umysłu użytkownika...

Więcej informacji i pobieranie: kliknij tutaj

Torpark - anonimowe przeglądanie

nospam@example.com (Marcin Guzowski) — Mon, 25 Sep 2006 22:39:08 +0200

Pojawiła się nowa wersja przeglądarki Torpark (v1.5.0.7). Przeglądarka ta podczas łączenia z serwerami www automatycznie korzysta z sieci serwerów proxy (tzw. Tor circuit/network), zapewniając tym samym stosunkowo anonimowe przeglądanie stron www. Anonimowy browsing można oczywiście wyłączyć, wtedy przeglądarka nie różni się zasadniczo od Firefoxa, którego framework z resztą wykorzystuje.

Pobierz program: Torpark download