Na blogu GDTR ukazał się jakiś czas temu ciekawy artykuł opisujący metody przyśpieszania Fuzzingu, zachęcam każdego zainteresowanego wyszukiwaniem luk do przeczytania:
„Speed up your fuzzfarm: fast hit tracing”
Gynvael Coldwind opisał ciekawy przypadek wykorzystania współdzielonych sekcji DLL bibliotek Cygwin do uzyskania praw administratora.
„Revisiting DLL shared sections. Cygwin vulnerability”
Artykuł przedstawiający obejście ograniczeń co do tworzenia zdalnych wątków w obcych procesach w systemie Windows 7, w którym wprowadzono dodatkowe ograniczenia w stosunku do starszych wersji Windows.
„CreateRemoteThread. Bypass Windows 7 Session Separation”
http://syprog.blogspot.com/2012/05/createremotethread-bypass-windows.html
DataHASP to system szyfrowania dowolnych plików aplikacji, dzięki któremu oryginalna treść takich zaszyfrowanych plików widoczna jest jedynie dla aplikacji, które zostały zabezpieczone przez Sentinel HASP Envelope (exe-protector HASPa).
HASP pozwala na szyfrowanie pojedynczych plików jak i całych katalogów z danymi aplikacji poprzez dodatkowe narzędzie:
W samym envelope określa się rodzaj plików, które zostały zaszyfrowane:
Zaszyfrowane pliki aplikacji może odczytać jedynie zabezpieczona aplikacja, realizowane jest to poprzez system hooków na funkcje systemu plików na poziomie usera.
Jeśli aplikacja zostanie rozpakowana, dostęp do oryginalnej treści zaszyfrowanych plików będzie niemożliwy (brakuje tych hooków, które w locie deszyfrują dane).
Jak uzyskać zatem dostęp do oryginalnej treści zaszyfrowanych plików?
Należy do działającej i zabezpieczonej aplikacji wstrzyknąć kod, który wykorzysta jej funkcje systemu plików (na które nałożone są hooki HASPa) i po prostu zaemulować czytanie wybranych plików.
Najprościej można to zrealizować poprzez skrypt ODBScript:
; wolna przestrzen po sekcji kodu
mov dump_hasp,008864D5
mov eip,dump_hasp
asmtxt eip,"dumper.asm"
; alokuj 2 bufory na nazwe pliku wyjsciowego i wejsciowego
alloc 512
mov input_file,$RESULT
alloc 512
mov output_file,$RESULT
; zrzuc 1 plik
mov x, "C:\PATH\APP\DATA.DAT"
call dump_file
; zrzuc 2 plik
mov x, "C:\PATH\APP\CONFIG.DAT"
call dump_file
ret
; funkcja do zrzucania zaszyfrowanych plikow
dump_file:
fill input_file, 512, 0
mov [input_file], x
; plik wyjsciowy bedzie posiadal rozszerzenie .x
add x, ".X"
fill output_file, 512, 0
mov [output_file],x
; ESI -> sciezka pliku wejsciowego
; EDI -> sciezka pliku wyjsciowego
mov esi,input_file
mov edi,output_file
; ustaw EIP na adres procedury dumpujacej
mov eip,dump_hasp
; exec ... ende za chiny nie dziala u mnie... inaczej bym tu dal call dump_hasp?
; uruchom kod z biezacego EIP do napotkania instrukcji RET
rtr ;run to return
mov x, ""
ret
Pomocniczy kod w assemblerze dla skryptu:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; odczytaj plik wejsciowy
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; zapamietaj na stosie nazwe pliku wyjsciowego
push edi
; otworz plik wejsciowy
push 0 ; hTemplate
push 0 ; attribs
push 3 ;OPEN_EXISTING ; creation
push 0 ; security
push 1 ; share mode
push 80000000 ;GENERIC_READ
push esi ; lpFileName
call [0800004] ;CreateFileA
mov ebx,eax
push 0
push ebx ; hFile
call [0800008] ;GetFileSize
mov edi,eax
; zaalokuj pamiec do odczytania danych pliku wejsciowego
push 4 ;PAGE_READWRITE
push 3000 ;MEM_RESERVE or MEM_COMMIT
push edi ; size
push 0
call VirtualAlloc
mov esi,eax
; czytaj plik wejsciowy korzystajac z hookowanych API
push 0
mov eax,esp
push 0 ; dwOverlapped
push eax ; &dwRead
push edi ; dwSize
push esi ; lpBuffer
push ebx ; hFile
call [0800024] ;adres funkcji ReadFile w zabezpieczonym pliku
pop edx
; zamknij plik wejsciowy
push ebx
call [0800088] ;CloseHandle
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; zapisz plik wyjsciowy
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; zdejmij ze stosu nazwe pliku wyjsciowego (odszyfrowany)
pop eax
push 0 ; hTemplate
push 0 ; attribs
push 2 ;CREATE_ALWAYS ; creation
push 0 ; security
push 0 ; share mode
push 40000000 ;GENERIC_WRITE
push eax ; lpFileName
call CreateFileA
mov ebx,eax
; zapisz odczytana tresc pliku wejsciowego
push 0
mov eax,esp
push 0 ; overlapped
push eax ; &dwWritten
push edi ; size
push esi ; buffer
push ebx
call WriteFile
pop edx
; zamknij plik wyjsciowy
push ebx
call CloseHandle
; zwolnij pamiec
push 8000 ;MEM_RELEASE
push 0
push esi
call VirtualFree
ret
Przedstawiona technika pozwala z łatwością odczytać wszystkie zaszyfrowane pliki.
ArcaBit to polski producent oprogramowania antywirusowego ArcaVir, wywodzący się z MksVir-a. Całą smutną historię rozdzielenia się części pracowników i utworzenia ArcaVir oraz o późniejszych wielu sporach moża przeczytać na forach obu firm oraz na portalu DobreProgramy.pl.
Dzisiaj ciekawe opinie o pracy w tej firmie znalazłem na forum 4programmers, a docelowo znajdują się na portalu o pracy GoWork, jeden z ciekawszych cytatów:
Właściciele mają samochody za kilkaset tysięcy [każdy] a w biurze nie ma nawet sprzątaczki.
Jest biuro na parterze i tam ludzie mają grafik, kto i kiedy sprząta [myje podłogi, odkurza i czyści kible – tak kible]. Biuro na piętrze jest sprzątane przez Panią W. [odkurzanie, mucie naczyń, kurze i kible]. Warto nadmienić że Pani W. jest szefową biura a mimo wszystko w godzinach pracy w elegandzkim stroju – sprząta.
Najlepsza było przyjęcie wigilijne – było owszem ciasto i Cola i ….. no niestety nic więcej nie było.
Okropne dziadostwo
Oryginalny wpis:
http://www.gowork.pl/opinie_czytaj2,33733,0,0
PS.
Dzisiaj wyszedł news o upadłości firmy MKS, R.I.P gorszego dziadostwa antywirusowego nie widziałem, jeszcze w czasach wersji DOS-owej skasował mi połowę exeków z dysku, a w czasach Windowsa nie chcieli ze mną nawet rozmawiać o false-positivach w moich pierwszych exe-pakerach.
Zestaw narzędzi do analizy .NET-owych aplikacji znacznie różni się od klasycznych narzędzi dla zwykłych aplikacji x86 / x64, odmienna architektura kodu wymusiła utworzenie całej gamy dedykowanych narzędzi dla plików wykonywalnych .NET, spróbuję przedstawić kilka z nich, które mogą się przydać w reversingu.
Pierwszym i podstawowym narzędziem, które chyba zna większość osób zajmujących się analizą oprogramowania i nie tylko jest dekompilator .NET Reflector.
Pozwala on na dekompilację plików wykonywalnych z formatu kodu przejściowego CIL (Common Intermediate Language) do kodu wysokiego poziomu w wybranym lub ulubionym przez nas języku np. C#, VB# etc.
Jest to najbardziej znany dekompilator i nie tylko, gdyż dzięki całej masie wtyczek umożliwia np. modyfikację plików binarnych (wtyczka Reflexil), debugowanie aplikacji (wtyczka Deblector) i wiele innych czynności związanych z analizą kodu.
Ostatnio .NET Reflector stracił na popularności, gdyż projekt od początku istnienia był darmowy, jednak po przejęciu go przez firmę Red Gate Software (notabene twórców obfuscatora SmartAssembly, z czego można wysnuć teorię spiskową, że chcieli ograniczyć dostęp do jednego z najpopularniejszych narzędzi do analizy aplikacji) i początkowych zapewnień o utrzymaniu jego darmowego statusu, po jakimś czasie został przekształcony w komercyjną wersję, z najtańszą licencją za 35 USD. W Internecie można jednak znaleźć złamane kopie jak również całkowicie zrekompilowane (wraz ze źródłami), bardziej odporne na narzędzia zabezpieczające.
Strona domowa — www.reflector.net
Lista wtyczek — http://reflectoraddins.codeplex.com/
Darmowy dekompilator firmy Telerik, raczej dla niewymagających użytkowników, ponieważ liczba dostępnych opcji (lub ich brak) nie powala na kolana, nie można nawet przejrzeć kodu w postaci IL, nie mówiąć o innych rzeczach, jest tu tylko dekompilator i wyszukiwarka referencji.
Strona domowa — www.telerik.com/products/decompiler.aspx
Warto wspomnieć również o tym narzędziu, chociaż z mojego doświadczenia wynika, że jest ono raczej mało używane, to deasembler dla .NET-owych binariów firmy Microsoft dołączany do SDK .NET-a oraz dostarczany wraz z Visual Studio.
Pozwala on na przeglądanie struktury pliku oraz deasembling do kodu przejściowego w związku z czym nie jest tak poręczny w analizie jak .NET Reflector.
Jest to kolejny deasembler i edytor jednak już bardziej zaawansowany od IL DASM-a, posiadający masę opcji, pozwalających na łatwą modyfikację kodu IL, kopiowanie instrukcji, wycinanie, wszystko bardzo poręcznie skonstruowane, od jakiegoś czasu jest to mój faworyt jeśli chodzi o modyfikację .NET-owych plików binarnych.
SAE posiada system wtyczek oraz wbudowany deobfuscator, który może przydać się w analizie zabezpieczonych aplikacji.
Jeśli chcesz nauczyć się podstaw programowania w IL, zmodyfikować szybko i sprawnie binaria to jest to idealne narzędzie.
Strona domowa — http://code.google.com/p/simple-assembly-explorer/
Dis# to stosunkowo mało znany dekompilator, być może ze względu na to, że to komercyjne narzędzie, projekt dawno nie był aktualizowany, ale może być traktowany jako ciekawostka, gdyż posiada kilka interesujących cech jak wbudowany deobfuscator, edytor kodu pozwalający w prosty sposób zamieniać nazwy funkcji, zmiennych etc.
Strona domowa — http://netdecompiler.com
Z moich obserwacji i doświadczeń wynika, że większość analiz związanych z .NET da się rozwiązać statycznie (w przeciwieństwie do natywnych aplikacji), jednak i tutaj może przydać się prześledzenie wykonywanego kodu.
Dile to prosty w obsłudze debugger dla .NET-owych aplikacji, troszkę przypomina debugger z Visual Studio.
Strona domowa http://sourceforge.net/projects/dile/
Dla aplikacji natywnych podstawowym identyfikatorem jest PEiD oraz częściej uaktualniany Protection ID (oraz kilka innych), dla .NET powstał odpowiednik PEiD o nazwie DNiD.
Wykrywa on obecnie większość stosowanych zabezpieczeń stosowanych dla aplikacji .NET-owych. Do ściągnięcia lokalna kopia — DNiD.v0.11-Rue.rar (384 kB)
Aplikacje .NET-owe obecnie rzadko rozprowadzane są w czystej formie po kompilacji, gdyż dzięki narzędziom takim jak .NET Reflector jest to praktyczne równoznaczne z rozprowadzaniem open source i większości wypadków do zabezpieczania używane są obfuscatory.
Część obfuscatorów oprócz modyfikacji kodu IL, całość aplikacji „opakowuje” w kod ładujący (z ang. loader) w formacie natywnym (x86), który zwykle deszyfruje całe .NET-owe assembly i dopiero w odszyfrowanej formie ładuje je do pamięci.
Taka forma zabezpieczenia nie pozwala na używanie narzędzi .NET-owych i wymagane jest najpierw zrzucenie z pamięci załadowanych assembly .NET-owych w celu dalszej analizy.
Projekt autorstwa Daniela Pistelli (obecnie pracujący nad IDA w HexRays), generyczny jak nazwa wskazuje dumper, który potrafi wykryć w pamięci obraz pliku wykonywalnego .NET mimo zewnętrznego natywnego loadera.
Strona domowa — http://www.ntcore.com/netunpack.php
Prosty w użyciu dumper, który również posiada obsługę zrzucania z pamięci plików kilku rodzajów zabezpieczeń, generalnie z tymi dwoma dumperami można sobie poradzić z większością zabezpieczeń natywnych.
Do ściągnięcia lokalna kopia — DotnetDumper.zip (66 kB)
Oprócz dedykowanych dumperów, równie dobrze działają klasyczne metody przeszukiwania pamięci np. w OllyDbg w poszukiwaniu sygnatur .NET-owych aplikacji (np. stringów „_CorExeMain”).
Po zrzuceniu z pamięci obrazu pliku .NET jest on często niezdatny do analizy w narzędziach takich jak .NET Reflector, wynika to ze zmian jakie wprowadzają najczęściej obfuscatory, aby dodatkowo utrudnić analizę. Tak zrzucone obrazy plików należy naprawić.
Do ściągnięcia lokalna kopia — Universal_Fixer.zip (31 kB)
Zawsze aktualna kopia — http://forum.tuts4you.com/topic/25376-universal-fixer/
Liczba obfuscatorów dostępnych na rynku jest ogromna, mogę śmiało powiedzieć, że przebija ilość dostępnych narzędzi zabezpieczających dla natywnych aplikacji. W związku z tak zmasowanym atakiem, powstały deobfuscatory dla wielu narzędzi, często zintegrowane i obsługujące wiele rodzajów zabezpieczeń.
de4dot to aktywnie rozwijany deobfuscator obsługujący sporą listę zabezpieczeń, podstawa jeśli ktoś myśli poważnie o analizie oprogramowania .NET
Do ściągnięcia ze strony — https://github.com/0xd4d/de4dot/downloads
Obecny stan zabezpieczeń .NET-owych może z początku przerazić i zniechęcić do dalszej analizy, ale jak widać istnieje wiele narzędzi, które potrafią ułatwić nam życie.
Celowo nie opisywałem tutaj gotowych unpakerów, które można z łatwością znaleźć samemu, gdyż nie zawsze sprawdzają się w działaniu i warto wtedy wiedzieć jak sobie poradzić bez ich pomocy.
Jeśli natknę się na jakieś ciekawe narzędzie to dopiszę je do artykułu, a jeśli wy znacie coś interesującego do analizy aplikacji .NET — opiszcie w komentarzach, a ja to przejrzę i z chęcią dodam opis do artykułu.
Na koniec jeszcze kilka linków, gdzie można znaleźć narzędzia do analizy .NET-owych aplikacji:
BlackStorm — http://portal.b-at-s.net/download.php?list.9
RCE Tool Library — http://www.woodmann.com/collaborative/tools/index.php/Category:.NET_Tools