Kilka dni temu ukazał się exploit umożliwiający zdalne wykonanie kodu przy wykorzystaniu znanej od 4 grudnia podatności przepełnienia sterty ( heap overflow vulnerability) w procedurze systemowej sp_replwritetovarbin. Kilka dni po publikacji exploita Microsoft potwierdził, że narażonych jest całkiem sporo wersji systemu SQL Server. Problem dotyczy bowiem wszystkich wersji 2000 oraz wszystkich 2005 bez najnowszego SP3, który lukę eliminuje. SQL Server 2008 jest wolny od problemu.
sp_replwritetovarbin to rozszerzona procedura składowana ( extended stored procedure - czyli de facto zewnętrzna biblioteka wywoływana w kontekście instancji SQL Server) wykorzystywana przez wewnętrzne interfejsy replikacyjne wyłącznie w jednej sytuacji - kiedy w replikacji transakcyjnej z modyfikowalnymi subskrypcjami ( transactional replication with updatable subscriptions) o odpowiednim ustawieniu @update_mode ( 'failover' lub 'queued tran' - domyślne) dokonywana jest DMLowa operacja modyfikacji w tabelach subskrypcji. Aby zablokować możliwość przeprowadzenia ataku najlepiej odebrać prawa wykonywania procedury roli public (REVOKE) lub odmówić tego prawa (DENY):
USE master
DENY EXECUTE ON sp_replwritetovarbin TO public
a następnie - o ile to możliwe - podnieść wersję instancji do co najmniej SQL Server 2005 SP3. Oczywiście powyższa zmiana uprawnień będzie skutkowała wyłożeniem się replikacji (ale tylko w/w rodzaju, pozostałe replikacje - np. klasyczna transakcyjna - nie są zagrożone workaroundem).
Na czym polega problem z niesławną procedurą sp_replwritetovarbin? Na tym, że kiedy zostanie wywołana z takimi przykładowymi parametrami:
DECLARE @retcode int,
@end_offset int,
@vb_buffer varbinary,
@vb_bufferlen int,
@buf nvarchar;
EXEC master.dbo.sp_replwritetovarbin 1, @end_offset output, @vb_buffer output, @vb_bufferlenoutput,
'AAAAAAAAAAAAAAAA(..3 tysiące liter A..)AAAAAAAAAAAAAA','1','1','1', '1','1','1','1','1','1';
to biblioteka stojąca za procedurą wykona zapis do kontrolowanego adresu w pamięci, przez co możliwe jest wstrzyknięcie i wykonanie obcego kodu w kontekście procesu instancji SQL Server. Gotowy exploit można znaleźć tutaj (zapytania zaszyte w kodzie VB strony ASP, exploit tworzy tzw. reverse shella na porcie 4445). Atakujący musi dysponować uwierzytelnionym dostępem do instancji serwera (czyli mówiąc wprost musi być w stanie wykonać kod T-SQL choćby w kontekście konta o najsłabszych uprawnieniach), gdyż prawo wywołania procedury przypisane jest do roli public bazy master. Do wykorzystania exploita w scenariuszu prawdziwego ataku potrzebny jest więc także np. skuteczny SQL injection, choć oczywiście to tylko jedna z wielu możliwości.
Luka jest moim zdaniem całkiem poważna i występuje w miejscu, które od dawna wskazywane było i jest jako niebezpieczne - czyli wesoły i swawolny obszar rozszerzonych procedur składowanych. Od kiedy w wersji SQL Server 2005 pojawiła się możliwość integracji CLR (czyli pisania m.in. procedur składowanych w kodzie zarządzanym .NET), uzasadnienie istnienia procedur XP ogranicza się już tylko do kwestii interfejsów wewnętrznych/systemowych, a i te można przecież "unatywnić" w samym silniku bazodanowym, tak jak jest to zrobione m.in. z obsługą dziennika transakcji. Choć z drugiej strony całkowicie rozumiem programistów z Redmond - też bałbym się dotykać czegokolwiek związanego z replikacją :)
Więcej informacji:
Microsoft Security Advisory (961040): Vulnerability in SQL Server Could Allow Remote Code Execution
SEC Consult Security Advisory < 20081209-0 >
EXPLOIT: Microsoft SQL Server "sp_replwritetovarbin()" Heap Overflow - Reverse Shell
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
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
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.
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
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ę.
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?
|
