Opera – Null Pointer Dereference

Ahh… sporo czasu upłynęło od ostatniego wpisu, lecz bez wdawania się w szczegóły chciałem uspokoić, że prac nad tworzeniem tego blogu nie porzuciłem i w miarę możliwości będą się tu pojawiały nowe wpisy ;).
A teraz do rzeczy…Tak jak w tytule post będzie traktował o bug’u typu Null Pointer Dereference znajdującym się dokładnie w opera.dll do wersji Opera 10.53 włącznie, jedynie od wersji 10.10 blad nie bedzie wystepowal w sposob “automatyczny”, a będzie wymagal od nas jeszcze wiekszej ingerencji niz w wersjach poprzednich. Jednak tak jak wspomniałem kod odpowiedzialny za ten bug nie zostal poprawiony do dzisiaj ;/.
Wspominam o tej „niedociągłości” bardziej w ramach ciekawosteki niż prezentacji konkretnego bug’u do wyexploitowania, chociazby z tego powodu ze wywolanie go wymaga NIE MALEJ ingerencji od user’a.
[+]Dlaczego warto o nim wspomnieć?
1. Dla zdobycia odpowiedzie na pytania, które tygrysy lubią najbardziej : czyli po co, na co ,dlaczego ,dlaczego tak a nie inaczej 😉
2. Dla zaprezentowania wektora ataku np. na przekladarke.
[+]Jak wywołać bug?
Wystarczy stworzyc pusty plik i nadac mu rozszerzenie .eml (trudno okreslic dla jakich jeszcze rozszerzenie opera tak zareaguje, ze wzgledu na pokazny kod do rewersowania, w celu ustalenia tych danych oraz mala uzytecznosc tego bug’a jak dla mnie 😉 ),wrzucic ten plik do katalogu np. apacha’a ( to istotne zeby odwolywac sie do pliku zdalnie) odwolac sie do niego i nastepnie wywolac opcje ‘Zapisz jako’.
opera_crash
[+]Gdzie znajduje sie bug?
Rzućmy okiem na wartosci rejestrow,elementow na stos podczas wystapienia tego bledu.
Opera 10.10b PL
ok_10.10_first_instruction
Pointer na unikodowy string leżący na stosie może sugerować nam, że błąd może być związany z wypelnianiem kontrolki trzymajacej opisy typow plikow do jakich opera moze zapisac bierzacy kontent. Zdziwiłem się delikatnie, kiedy na tej samej wersji przegladarki, jedynie z zaladowanym angielskim tlumaczeniem wywolanie bug’a nie udalo sie powtorzyc. Co tu moze byc problemem?!….
[+]Wektor ataku
Wektorem ataku okazują sie tutaj pliki z tlumaczeniami,
($INSTALDIRlocale[jezyk][jezyk])
ktorych nie do końca poprawne zdefiniowanie może spowodować DoS’a ze względu na nie sprawdzanie w kodzie poprawności zawartych tam danych. Taka sytuacja bez naszej ingerencji ma miejsce do Opery 10.10b ze wzgledu na nie poprawnie zdefiniowany plik z tlumaczeniem dla jezyka polskiego.
Odnajdzmy wczesniej prezentowany interesujacy string na screen’e w pliku z tlumaczeniem PL oraz sprobujmy znaleść rożnice w formacie dla pliku z tlumaczeniem ANG.
compare_pl_eng
Baah!!!Jak widać string zawierający tekst, który jest umieszczany pozniej w kontrolce, zawierajacej liste typow plikow mozliwych do zapisu przez opera oraz rozszerzenie pod jakim plik zostanie zapisany w wersji PL nie zawiera znaku ‘|’ co jak okazuje sie jest zrodlem problemu.
[+]Malo bezpiecznie zdefiniowana funkcja
Powróćmy teraz do Olka i przyjrzymy sie miejscu gdzie nastepuje dereferencja pointer’a zerowego:
Analiza kodu dla poprawnie zdefiniowanego parametru:
-1371929526=”Archiwum strony WWW (jeden plik)|*.mht|”

registers:
EAX = 0x1732F8C
ECX = 0x1732FA0
entire code:
67ADDA16    8B4424 04       MOV EAX,DWORD PTR SS:[ESP+4] //eax == save_as_struct
67ADDA1A    8D48 14         LEA ECX,DWORD PTR DS:[EAX+14]
67ADDA1D    8B40 2C         MOV EAX,DWORD PTR DS:[EAX+2C]
67ADDA20    57              PUSH EDI
67ADDA21    E8 F842D8FF     CALL Opera_1.67861D1E
67ADDA26    8BC8            MOV ECX,EAX
67ADDA28    83C1 08         ADD ECX,8
67ADDA2B    33C0            XOR EAX,EAX
67ADDA2D    E8 EC42D8FF     CALL Opera_1.67861D1E
>>> 67ADDA32    8B00            MOV EAX,DWORD PTR DS:[EAX] //eax = pointer on string contains file extension (e.g *.mht) or NULL
67ADDA34    8B7C24 0C       MOV EDI,DWORD PTR SS:[ESP+C] //esp+c == buffer_for_copyOf_file_extension
67ADDA38    6A FF           PUSH -1
67ADDA3A    50              PUSH EAX
67ADDA3B    E8 60B3CBFF     CALL Opera_1.67798DA0
67ADDA40    5F              POP EDI
67ADDA41    C3              RETN
struct save_as_struct
{
0x1732F8C  /* +0 */  0x00000000
0x1732F90  /* +4 */  0x00000000
0x1732F94  /* +8 */  0x00000000
0x1732F98  /* +C */  0x60D76F01
0x1732F9C  /* +10 */ 0x38000000
0x1732FA0  /* +14 */ 0x4805E967     //ecx pointer
0x1732FA4  /* +18 */ 0x0A000000
0x1732FA8  /* +1C */ 0xC0E59301     //ecx + 0x8  //pointer on array->pointer->string('Archiwum strony WWW (jeden plik)')
0x1732FAC /* +20 */ 0x01000000     //ecx + 0xc // count of elements
0x1732FB0 /* +24 */ 0x0A000000
0x1732FB4 /* +28 */ 0x00000000
0x1732FB8 /* +2C */ 0x00000000
};
first call of 67861D1E:
ECX = 0x1732FA0 /* +0x14 */
EAX = 0
67861D1E    3B41 0C         CMP EAX,DWORD PTR DS:[ECX+C] /* eax = 0; ecx + C == count of elements*/
67861D21    73 07           JNB SHORT Opera_1.67861D2A
67861D23    8B49 08         MOV ECX,DWORD PTR DS:[ECX+8] /* ecx = [ecx + 8]; [ecx+8]==pointer on array->pointer->string */
67861D26    8B0481          MOV EAX,DWORD PTR DS:[ECX+EAX*4] /* eax = pointer->string */
67861D29    C3              RETN
67861D2A    33C0            XOR EAX,EAX
67861D2C    C3              RETN
second call of 67861D1E:
ECX = 0x0166C270
EAX = 0
stack view:
0x0166C270 /* +0 */ 0xB832DC67
0x0166C274 /* +4 */ 0x0A000000
0x0166C278 /* +8 */ 0xC0DF9301  //pointer on array->pointer->string('*.mht')
0x0166C27C /* +C */ 0x01000000  // count of elements

Dereferencja null pointer’a dla blednie zdefiniowanego parametru:
-1371929526=”Archiwum strony WWW (jeden plik)|*.mht”
null_pointer_dereference
Tak jak pisalem wczesniej nie analizowałem dogłebnie calego procesu parsowania pliku z tlumaczeniem …
Bez doglebnej analizy wczesniej wykonanego kodu przed kodem prezentowanym powyzej, mozemy stwierdzic ze brak znaku ‘|’ na koncu ‘parametru’ -1371929526 powoduje bledny split lancucha znakow i tym samym nie wypelnienie pola struktury gdzie powinien sie znalesc pointer na rozszerzenie pliku pod jakim miala by byc zapisana zawartosc strony.
Całe zło zaczyna sie dziać przy drugi wywołaniu funkcji 67861D1E:

second call of 67861D1E: // for bad parameter
ECX = 0x0166C270
EAX = 0
Stack view:
0x0166C270 /* +0 */0xB832DC67
0x0166C274  /* +4 */0x00000000
0x0166C278  /* +8 */0x00000000
0x0166C27C /* +C */0x00000000
67861D1E    3B41 0C         CMP EAX,DWORD PTR DS:[ECX+C] /* eax = 0; ecx + C == count of elements*/
67861D21    73 07           JNB SHORT Opera_1.67861D2A

Warunek skoku zostaje spelniony i mamy skok do instrukcji:

67861D2A    33C0            XOR EAX,EAX
67861D2C    C3               RETN

zerujacej nam eax i wychodzacej z funkcji. Nastepnie bez sprawdzania czy wartosc w eax jest poprawnym wskaznikiem mamy dereferencje:

>>> 67ADDA32    8B00            MOV EAX,DWORD PTR DS:[EAX] //eax = pointer on string contains file extension (e.g *.mht) or NULL

[+]Konkluzja
Tak jak pisałem na początku wspominam o tym bug’u raczej z formie ciekawostki niz jakiegos żalu do twórców opery ze wzgledu na sposob jaki „pozbyli” sie problemu(od wersji 10.10 plik z tlumaczeniem we wspomnianej linijce zawiera na koncu ‘|’ :D). Co niektorzy mogą się przyczepic ze mozna przeciez wykonac tutaj sprawdzanie formatu i ewentualnie wyswietlic komunikat ze plik z tlumaczeniem zostal zmodyfikowany lub jest uszkodzony i nalezy go zastapic poprawna wersja,itd….Takie rozwazania i ocene podejscia dev’ow z opery pozostawia wam Drodzy Czytelnicy ;).

Posted in Analiza, RE, Security | Tagged , , , | Leave a comment

VBox,Virtual PC,VMware i IDT Hooking

Będzie to dość stosunkowo lightowy post o “anomaliach”, które wystąpiły podczas moich testów z hookowaniem tablicy IDT pod wymienionymi w tytule post’a wirtualnymi maszynami. Dlaczego lightowy? Ponieważ żeby ustalić detale związane z sytuacjami, które później zaprezentuje, wymagało by to spooorego research’u odnośnie sposobu działania wewnętrznego mechanizmu poszczególnych wirtualnych maszyn (tak sądzę 😛 ).
Także proponuje traktować niniejszy post jako ciekawostkę/(wektor do badań) niż jako rezultat głębszego researchu.
Cała historia zaczyna się od momentu kiedy chciałem przetestować najprostszy w życiu hook na procedure KiSystemService poprzez modyfikacje jej adresu w tablicy IDT. Oto fragment kodu zakładający hook:

void IDTHook()
{
IDTINFO idtInfo;
IDTENTRY *idt_entries;
IDTENTRY *int2e_entry;
DbgPrint("[+] IDTHook");
//pobranie IDTINFO
idtInfo = getIDTInfo();
//pobranie *tablicy IDT
idt_entries = getIDTEntries(&idtInfo);
//zapisanie oryginalnego IDTENTRY_2E
orgIDTEntry_2e = idt_entries[KiSystemService_INDEX];
//zapisanie DWORD'a na potrzeby funkcji hookujacej
orgKiSystemService = MAKELONG(orgIDTEntry_2e.LowOffset,orgIDTEntry_2e.HiOffset);
__asm cli;//wylacz obsluge maskowalnych przerwan
idt_entries[KiSystemService_INDEX].LowOffset = (unsigned short)(&MySystemService);
idt_entries[KiSystemService_INDEX].HiOffset  = (unsigned short)(((unsigned long)(&MySystemService))<<16);
__asm lidt idtInfo;
__asm sti;//wlacz obsluge maskowalnych przerwan
}
&#91;/sourcecode&#93;
‘kod MySystemService przepisany w calosci z „Subverting Windows Kernel”‘
&#91;sourcecode language="cpp"&#93;
__declspec(naked) MySystemService()
{
__asm{
pushad
pushfd
push fs
mov bx,0x30
mov fs,bx
push ds
push es
//do something
//Finish:
pop es
pop ds
pop fs
popfd
popad
jmp	orgKiSystemService;
}
}
&#91;/sourcecode&#93;
&#91;sourcecode language="cpp"&#93;
/* __asm { sysenter VPC } */
&#91;/sourcecode&#93;
Bez większego wachania i namysłow postanowiłem przetestować wynikowy driver pod <strong>Virtual PC(ver. 6.0.192.0 + additions)[OS: Windows XP SP3 Eng]</strong>, z którego zwykłem korzystać. Ku mojemu zaskoczeniu (bo liczyłem co najwyżej na <strong>BSOD’a</strong> :P) przy próbie założenia hook’a wystąpił wewnętrzny błąd vpc:
<img src="http://www.icewall.pl/wp-content/uploads/2009/10/vpc_crash_error1.JPG" alt="vpc_crash_error" title="vpc_crash_error" width="827" height="452" class="alignnone size-full wp-image-297" />
Hym...dziwna kwestia pomyślałem. Między czasie przypomniałem sobie, że przecież system może w ogóle nie korzystać z <strong>IDT</strong> jeżeli posiadany przez nas procesor dysponuje obsługą instrukcji <strong>sysenter/syscall</strong>. Rzut okiem pod vpc na wywolanie jednego z najbardziej popularnych <strong>native api:
ZwOpenFile</strong>, rozwiało moje wątpliwości:
<img src="http://www.icewall.pl/wp-content/uploads/2009/10/vpc_syscalls_handler.JPG" alt="vpc_syscalls_handler" title="vpc_syscalls_handler" width="779" height="144" class="alignnone size-full wp-image-287" />
Sam error „wywalony” przez vpc wskazywał na to, że to nic stricte związanego z samym systemem, a raczej z vm, a teraz dodatkowo wiemy, że sens zakładania hook’a na IDT pod vpc jest raczej nie wielki <strong>(przez co POWINIEN być nie szkodliwy)</strong> ;). Postanowiłem wykonać test jeszcze raz po odinstalowaniu z systemu additions. Tu ponownie zaskoczenie, bo system zachował się tak jak powinien, czyli:
udało się zainstalować hook’a
oraz  żaden z breakpoint’ów(po dłuższej chwili), które założyłem na MySystemService nie został wywołany.
Zobaczmy teraz jak się sprawy maja pod VirtualBoxem.

/* __asm { INT VirtualBox } */

Ver. 3.0.8 r53138 + additions
OS pozostaje bez zmian pod każdą maszynką.

Pierwszą kwestią, którą tutaj sprawdziłem jest sposób przejścia procesu z r3 do r0.
vbox_syscalls_handler
Wyśmienicie! Jak widać na załączonym obrazku pod VBoxem możemy śmiało testować hooki na IDT. Tak mi się bynajmniej wydawało…
Ładuje driver,przekazuje odpowiedni IOCL_code do moje driver’a, który wywoła instalacje hook’a i … :
vbox_crash
cała akcja kończy się nie oczekiwanem crash’em VBox’a.
Długo nie myśląc odinstalowalem dodatki z systemu i ponowiłem próbę.
Udało się!Instalacja hook’a przebiegła bez problemowo, ale podczas paru kolejnych prób zdarzał mi się BSOD’nąć system z komunikatem, który jedno znacznie wskazywał, że nastąpiła próba dostępu do stronnicowanego obszaru pamięci.Windbg wskazywał następującą linijke kodu jako przyczyne zła:

idt_entries[KiSystemService_INDEX].LowOffset = (unsigned short)(&amp;MySystemService);

Eeee delikatnie dziwne,,,IDT w obszarze stronnicowanej pamięci o_0?
Delikatnie zmodyfikowałem więc kod instalujący hook, po przez zmapowanie tablicy IDT pod NIEstronnicowany obszar pamieci. Kod prezentuje się teraz następująco:

void IDTHook()
{
IDTINFO idtInfo;
IDTENTRY *idt_entries;
IDTENTRY *int2e_entry;
DbgPrint("[+] IDTHook");
//pobranie IDTINFO
idtInfo = getIDTInfo();
//pobranie *tablicy IDT
idt_entries = getIDTEntries(&amp;idtInfo);
//try to map it
idt_entries = mapMemory(idt_entries,idtInfo.IDTLimit);// NOWA LINIA
//update idtinfo struct
idtInfo.HiIDTbase  = HIWORD(idt_entries);
idtInfo.LowIDTbase = LOWORD(idt_entries);
//zapisanie oryginalnego IDTENTRY_2E
orgIDTEntry_2e = idt_entries[KiSystemService_INDEX];
//zapisanie DWORD'a na potrzeby funkcji hookujacej
orgKiSystemService = MAKELONG(orgIDTEntry_2e.LowOffset,orgIDTEntry_2e.HiOffset);
__asm cli;//wylacz obsluge maskowalnych przerwan
idt_entries[KiSystemService_INDEX].LowOffset = (unsigned short)(&amp;MySystemService);
idt_entries[KiSystemService_INDEX].HiOffset  = (unsigned short)(((unsigned long)(&amp;MySystemService))&gt;&gt;16);
__asm lidt idtInfo;
__asm sti;//wlacz obsluge maskowalnych przerwan
}

Ten prosty zabieg wyeliminował pojawianie się BSOD’ów.

/* __asm { VMware sysenter } */


VMware Workstation
6.5.3 build-185404

Rzut oka na przejście r3 – > r0:
vmware_syscalls_handler
Jak widać użyty jest tu sysenter. Nie będę się rozpisywał przy vmware i od razu powiem, że instalacja hooka przebiega tutaj bez problemowo czy to z zainstalowanymi dodatkami czy bez.
Na podsumowanie sporządziłem następującą tabelkę:
table
Jak zwykle komentarze i wszelkiego rodzaju sugestie mile widziane ;).It’s gonna be quite light version of post about “anomaly” which I had pleasure to notice during tests of IDT hooking under virtual machines mentioned in this post title. Why light? Because in order to present all details related with cases that I’m going to show in letter part of post, it would required a deeply research regarding to internal manner of work each virtual machine
( I guess so :P). My suggestion is to treat this post like a curiosity/(vector to research) and not like a result of deeply research.
Entire story begins from the moment when I decided to test the simplest hook on KiSystemService procedure through modification its address in IDT table. It’s a piece of code responsible of hook installation:

void IDTHook()
{
IDTINFO idtInfo;
IDTENTRY *idt_entries;
IDTENTRY *int2e_entry;
DbgPrint([+] IDTHook);
//pobranie IDTINFO
idtInfo = getIDTInfo();
//pobranie *tablicy IDT
idt_entries = getIDTEntries(&amp;amp;idtInfo);
//zapisanie oryginalnego IDTENTRY_2E
orgIDTEntry_2e = idt_entries[KiSystemService_INDEX];
//zapisanie DWORD'a na potrzeby funkcji hookujacej
orgKiSystemService = MAKELONG(orgIDTEntry_2e.LowOffset,orgIDTEntry_2e.HiOffset);
__asm cli;//wylacz obsluge maskowalnych przerwan
idt_entries[KiSystemService_INDEX].LowOffset = (unsigned short)(&amp;MySystemService);
idt_entries[KiSystemService_INDEX].HiOffset  = (unsigned short)(((unsigned long)(&amp;amp;MySystemService))&lt;&lt;16);
__asm lidt idtInfo;
__asm sti;//wlacz obsluge maskowalnych przerwan
}

‘code MySystemService has been rewritten from „Subverting Windows Kernel”‘

__declspec(naked) MySystemService()
{
__asm{
pushad
pushfd
push fs
mov bx,0x30
mov fs,bx
push ds
push es
//do something
//Finish:
pop es
pop ds
pop fs
popfd
popad
jmp	orgKiSystemService;
}
}
/* __asm { sysenter VPC } */

Without bigger doubts and not necessary thinking I decided to test obtained driver under
Virtual PC(ver. 6.0.192.0 + additions)[OS: Windows XP SP3 Eng], which I mostly used to use. To my great surprise (because I counted on BSOD:P) during attempt to hook installation, occurred internal VPC error:
vpc_crash_error
Hymm…strange issue I thought. Meanwhile I remind to myself that operation system doesn’t need to use IDT table if our processor supports sysenter/syscall instruction. Eye throw under vpc on call to one of mostly used native api: ZwOpenFile, dispelled my doubts:
vpc_syscalls_handler
Error “triggered” by VPC pointed that it’s not strict related problem with OS, rather with vm, and now additionally we know that sense of hook installation on IDT under VPC isn’t too big(by what should be harmless) ;). I decided to perform test again after uninstallation additions from system. Another surprise here, system acted like it should act, that is:
– hook have been installed successfully
and neither of breakpoints (after quite long time), which I had set on MySystemService wasn’t triggered. We will see now how to cases look under VirtualBox.

/* __asm { INT VirtualBox } */

Ver. 3.0.8 r53138 + additions
OS stays without changes under each vm.

First issue which I have checked under this vm is manner on what process steps from r3 to r0.
vbox_syscalls_handler
Delicious! Like you can see on attached screenshot without any doubts we can test hooks on IDT. It seemed as such to me …
I’m loading driver ,I’m passing proper IOCTL code to my driver which is going to trigger hook installation and … :
vbox_crash
entire action is ending with unexpected VBox crash.
Don’t wondering too much I have uninstalled additions from system and I repeated test. Success! Hook installation have been made without any problems, but after couple another attempts I’ve had situations where system crashed with BSOD unambiguously saying, that occurred access attempt to paged memory region. Windbg was pointing following line of code as source of all evil:

idt_entries[KiSystemService_INDEX].LowOffset = (unsigned short)(&amp;amp;MySystemService);

Hymm…a little strange. IDT in paged memory region o_0 ?
I have modified a little source code to eliminate this problem by mapping IDT table under NON-PAGED memory area. Code presents now in the following way :

void IDTHook()
{
IDTINFO idtInfo;
IDTENTRY *idt_entries;
IDTENTRY *int2e_entry;
DbgPrint("[+] IDTHook");
//pobranie IDTINFO
idtInfo = getIDTInfo();
//pobranie *tablicy IDT
idt_entries = getIDTEntries(&amp;idtInfo);
//try to map it
idt_entries = mapMemory(idt_entries,idtInfo.IDTLimit);// NOWA LINIA
//update idtinfo struct
idtInfo.HiIDTbase  = HIWORD(idt_entries);
idtInfo.LowIDTbase = LOWORD(idt_entries);
//zapisanie oryginalnego IDTENTRY_2E
orgIDTEntry_2e = idt_entries[KiSystemService_INDEX];
//zapisanie DWORD'a na potrzeby funkcji hookujacej
orgKiSystemService = MAKELONG(orgIDTEntry_2e.LowOffset,orgIDTEntry_2e.HiOffset);
__asm cli;//wylacz obsluge maskowalnych przerwan
idt_entries[KiSystemService_INDEX].LowOffset = (unsigned short)(&amp;amp;MySystemService);
idt_entries[KiSystemService_INDEX].HiOffset  = (unsigned short)(((unsigned long)(&amp;MySystemService))&gt;&gt;16);
__asm lidt idtInfo;
__asm sti;//wlacz obsluge maskowalnych przerwan
}

This simple “patch” eliminated occurrence of BSOD’s.

/* __asm { VMware sysenter } */

VMware Workstation
6.5.3 build-185404

Quick look on transition r3 – > r0:
vmware_syscalls_handler
As we can see sysenter has been used here. I won’t dwell on vmware and at the beginning I’m going to say that there is no problems with hook installation, with or without installed additions in system.
As summary I prepared the following table:
table
Like always comments and any kind of suggestions are welcome ;).

Posted in Analiza | Tagged , , , , , , , | 4 Comments

SecDay 2009 – Video

Po paru tygodniach oczekiwań i kilku złożonych obietnicach, w końcu mogę przedstawić wam nagranie video z mojej prelekcji, która miała miejsce na konferencji SecDay 2009.
Wszelkiego rodzaju feedback związany ze sposobem prowadzenia prezentacji jest mile widziany;).
Miłego oglądania i ………… czekam na wasze komentarze;).

Bugs in Malware

Posted in Konferencje, Malware, RE, Security | Tagged , , , , , , , , , | 2 Comments

Nowa odsłona

Witam wszystkich w nowej odsłonie mojego bloga!
Z jakich powodów przeniosłem blog na nowy server? Powodów jest kilka, a główny jest to, że posiadanie pełnego dostępu do plików na serwerze daje mi większe możliwości:
– darmowa instalacja dodatkowych pluginów do wordpress’u
napewno tutaj  odczuwalnym dyskomfortem był brak pluginu do wyświetlania fragmentów kodu.

#include
int main()
{
std::cout<<"Hello world!"; return 0; } [/sourcecode] Nie mogłem się powstrzymać:P
Jeżeli chodzi o jakieś gruntowne zmiany to takowych raczej nie przewiduje,  jedyną kwestią która być może niektórym osobą (a pewnej grupie ludzie zdecydowanie) przypadnie do gustu jest publikowanie postów, które uznam za ciekawe lub tych które będą cieszyły się dużą popularnością , w dwóch wersjach językowych: Polskiej jak i Angielskiej.
Chyba tyle jężeli chodzi o zmiany i “innowacje” ;).
BTW:Rozpoczyna się delikatnie burzliwy okres: “Rozpoczęcie roku akademickiego” , także będe musiał poświęcić trochę czasu na dogranie pracy z uczelnią i paroma dodatkowymi zajęciami, ale oczywiście jestem przekonany o tym, że znajdzie się również czas na wrzucenie nowego posta ;).
W najbliższym czasie myślę, że można się spodziewać nagrań video z SecDay2009 jaki i kolejnego postu z cyklu
“Algorytmy (de)szyfrowania wykorzystywane przez twórców trojanów bankowych”.
Stay tuned :).

Posted in Ogólne | Tagged | 2 Comments

SecDay 2009

Wczoraj, to jest 22.09.2009r zakończyła się dwu dniowa konferencja SecDay 2009 organizowana przez Lukasz Błażys’a, która odbyła się we Wrocławiu, a jak nie trudno się domyślić była ona związana z ogólno pojętym bezpieczeństwem w IT. Z wielką przyjemnością muszę przyznać, że pierwszy raz ….UWAGA…….UWAGA miałem okazję:
brać czynny udział == być prelegentem!
na tego typu event’e.
LGIM0042
Emocje były wielkie …… ale jak dokładnie było możecie przeczytać poniżej:
Na wstępie powiem, że nie będę w żaden sposób komentował prezentacji Team’u HSPL w składzie (chronologicznie względem kolejności wystąpień):

Mateusz “j00ru” Jurczyk
Adam “pi3” Zabrocki
Gynvael Coldwind

Żeby nikt nie zarzucał mi, że cukruje kolegą z pracy to tylko powiem, że każda prezentacja była petardą i warto na nie rzucić okiem :P..Heheh.
More details below…
/* SecDay 2009 dzień pierwszy */
Jako, że obecnie mieszkam we Wrocławiu to kwestie dotarcia na konferencje pominę ponieważ nie było w niej nic nadzwyczajnego(15min taxi)….taaa to nie to samo co 5h spędzonych w pociągu w drodze na confidence :P.
Konferencje rozpoczął :
Dariusz Puchalak
prezentując temat:
„Bezpieczeństwo czy wydajność pracy?”
Niestety muszę się przyznać, że delikatnie się spóźniłem na ten wykład(sorry Darek :P).
Już parę razy miałem okazje słuchać prezentacji Darka i także tym razem była ona prowadzona na wysokim poziomie. Ze względu na porę dnia długo nie zastanawiałem się
nad propozycją jaką Dariusz umieścił w swoim temacie i wybrałem …..NIEBEZPIECZEŃSTWO.:D.
Przemysław Świercz
Bezpieczeństwo Bluetooth
Na wstępie trzeba wspomnieć, że był to debiut Przemka co moim zdaniem po wysłuchaniu jego prelekcji jest jak najbardziej na plus. Temat myślę, że jak najbardziej na czasie, bo przecież bluetooth można spotkać teraz praktycznie w każdym telefonie komórkowym, większości nowych TV,itd. Prezentacja była mocno techniczna (a takie właśnie uwielbiam) + zabawne anegdoty prowadzącego działające silnie na wyobraźnie ;).
Jeżeli ktoś jest zainteresowany bezpieczeństwo Bluetooth to myślę, że warto prześledzić tą prezentacje.
/* Przerwa na kafkę i po niej …*/
Mateusz Jurczyk
Bootkit vs Windows
Jako, że j00ru prowadzi własny blog to zachęcam do przeczytania jego relacji z konferencji jak i pobrania materiałów -> j00ru’s blog
/* Przerwa obiadowa */
Mówiąc krótko i kolokwialnie „obiad był bez szału”, także nie mogę tutaj przyznać ani plusa ani minusa, ale na pewno wypadł o wiele lepiej niż tegoroczny podawany na confidence’e.
Małego minusa dam za to, że dwa dni była ta sama potrawa:P,,,,gdzie kucharz „zostawił” fantazję!?
wracamy do prelekcji:
Krzysztof Maćkowiak
„Zarządzanie ryzykiem podstawą profesjonalnego podejścia do bezpieczeństwa informacji i ciągłości działania.”
Prezentacja jak najbardziej wykonana jak i poprowadzona w sposób profesjonalny, chociaż nie interesująca mnie zbytnio ze względu na obszar działań jakie poruszała. Dlatego też 3/4 jej czasu przegadałem z carstein’em o niuansach związanych z pentestingiem :P.
Grzegorz Błoński
Problem ulotu elektromagnetycznego.
Bardzo interesująca prezentacja, mocno techniczna podczas, której mogliśmy zobaczyć parę narzędzi do monitorowania ulotu elektromagnetycznego stworzonych przez autora przy wykorzystaniu popularnych kart telewizyjnych :D. Jeżeli byłeś/jesteś fanem serialu MacGyver masz zbędną kartę TV to nie czekaj tylko przeanalizuj powyższą prezentacje i rozpocznij własne badania!
Michał Melewski
Metodyka testów penetracjnych.
Moim zdaniem elegancko wykonana prezentacja, przejrzysta, przedstawiona na luzie, dająca do myślenia jeżeli chodzi o podejście do pentestów. Dzięki za źródło do refleksji ;).
Leszek Miś
Rootkity w systemie Linux.
Niestety prelegent nie dotarł na konferencje, a szkoda bo z chęcią posłuchałbym jak wygląda kwestia związana z rootkit’ami na linuxach.
Janusz Żmudziński
Monitorowanie bezpieczeństwa jako istotny element skutecznego zarządzania bezpieczeństwem informacji
?
/* SecDay 2009 dzień drugi */
Jako, że miałem przyjemność rozpocząć dzień drugi to przejdę od razu do drugiej prezentacji, a o własnej wspomnę na końcu relacji.
Konrad Zuwała
Solaris jako bezpieczna platforma serwerowa.
Od strony technicznej prezentacja jak najbardziej poprowadzona bardzo dobrze. Przeznaczona raczej dla administratorów i w tym kręgu znalazła ona grono słuchaczy jak i wywołała burzliwą dyskusję.
Błażej Miga
Zagrożenia w Internecie – DNS
Muszę powiedzieć, że na opublikowanie tej prezentacji czekam ponieważ pojawiło się w niej parę smaczków, które z chęcią bym przetestował. Hehe no i pojawił się w niej kod python’owy z wykorzystaniem modułu scapy.. jak widać prelegent wie co dobre;).
/* Dinner */
Jakub Bryl
Testowanie planów ciągłości działania
?
Adam Zabrocki
Unusual bugs
Adam obiecał wystartować z nową stroną/blogiem, a wtedy na pewno będziecie mieli okazje przejrzeć jego materiały ;).
Gynvael Coldwind
PHP Internals (not another RFI/SQLI)
Relacja Gyn’a + jego materiały. -> LINK
Robert Dąbrowski
Monitoring bezpiecznej sieci – praktyczne wykorzystanie logów.
Przepraszam, ale prezentacje komercyjnych produktów mnie nie interesują. Tu chodzi o research w dobrym klimacie tzw „piwnicznym klimacie”:D!
I tak kończy się lista prelegentów wraz ich tematami, których miałem przyjemność w większości wysłuchać.
Jeżeli chodzi o mój temat to brzmi on następująco:
Bugs in malware
Moim główny zamiarem było uświadomienie słuchaczy o tym, że w wieluuuuu przypadkach tworzony malware NIE jest doskonały, bardzo często tworzą go ludzie, którzy nie mają nawet średnich umiejętności programistycznych, a gruntowne testowanie swojego tworu jest dla nich abstrakcją. Często zdarza mi się spoglądając w kod malware’u pomyśleć o wyrażeniu : tragizm połączony z idiotyzmem. Czy taki obraz złośliwego oprogramowania przedstawiany jest w prasie i mediach? NIE. Oczywiście głównymi hasłami jakie pojawiają się są następujące:
„nowy błyskawicznie rozprzestrzeniający się worm”
„bardzo trudny do usunięcia trojan”
„trudno wykrywalny wirus”
„maszynka do wykradania poufnych danych”
itp.

Taki obraz, będący totalną generalizacją na temat malware’u, który rzekomo jest absolutnie genialny, trudny do usunięcia, napisany przez pr0 cod3r0w miałem na zamiarze usunąć z mapy rzeczywistości słuchaczy, a przynajmniej wzbogacić ją o informacje, które pokazują „troszeczke” inny obraz tych „złośliwych” aplikacji ;). Czy mi się udało ?;]. Mam taką nadzieję;).
Jeżeli chodzi o moje materiały to możecie je pobrać stąd:
(Pliki sa oczywiscie w formacie ZIP.Przepraszam za utrudnienia w pobieraniu, ale takie są uroki korzystania z wordpress’a.)
Prezentacja -> prezentacja_Icewall_SecDay_2009.zip(ODP&PDF)
Pełna paczka(prezentacja + filmiki) -> Icewall_SecDay_2009.zip
W kwestii wyjaśnienia: Jeden z filmików zbudził delikatne kontrowersje dlatego też został odpowiednio ocenzurowany.
Hiperlinki w ODP jak i w PDF’e są ustawione w sposób relatywny, także można na nie klikać dowoli jeżeli zachowacie następująco strukturę katalogów:
Delephant
GetCodec
Zeus
prezentacja.odp
prezentacja.pdf


PS: Możliwe, że nawet do końca tygodnia pojawi się photo jaki i video relacja z konferencji dla której myśle stworze osobny post. Na video relacji będziecie mogli obejrzeć wszystkie prelekcje ludzi zarówno z HSPL jak i Vexillium. Także bądźcie czujni;),będzie co oglądać.

Pozdrawiam i zapraszam na kolejną edycje SecDay już we wrzesniu, bo warto;).

Posted in Analiza, Konferencje, Malware, RE, Security | Tagged , , , , , , , | 4 Comments

Algorytmy (de)szyfrowania wykorzystywane przez twórców trojanów bankowych – PART II

Tak jak wspominałem w poprzednim poście niniejszy będzie o sposobach (de)szyfrowania stosowanych w pewnej rodzinie trojanów bankowych pisanych w delphi.
Oczywiście tradycyjnie zaczniemy od przedstawienia naszego bohatera:
[=]Dane[=]

Antivirus	Version	Last Update	Result
a-squared	4.5.0.24	2009.08.28	Trojan-Spy.Win32.Bancos!IK
AhnLab-V3	5.0.0.2	2009.08.28	-
AntiVir	7.9.1.7	2009.08.28	TR/Spy.Banker.DS.5102592
Antiy-AVL	2.0.3.7	2009.08.24	-
Authentium	5.1.2.4	2009.08.28	-
Avast	4.8.1335.0	2009.08.28	Win32:Spyware-gen
AVG	8.5.0.406	2009.08.28	PSW.Banker5.IQR
BitDefender	7.2	2009.08.28	DeepScan:Generic.Banker.OT.4CC5D1C8
CAT-QuickHeal	10.00	2009.08.28	-
ClamAV	0.94.1	2009.08.28	Trojan.Agent-119128
Comodo	2125	2009.08.28	-
DrWeb	5.0.0.12182	2009.08.28	Trojan.PWS.Banker.based
eSafe	7.0.17.0	2009.08.27	-
eTrust-Vet	31.6.6706	2009.08.28	-
F-Prot	4.5.1.85	2009.08.27	-
F-Secure	8.0.14470.0	2009.08.28	-
Fortinet	3.120.0.0	2009.08.28	W32/Banker.B!tr.pws
GData	19	2009.08.28	DeepScan:Generic.Banker.OT.4CC5D1C8
Ikarus	T3.1.1.68.0	2009.08.28	Trojan-Spy.Win32.Bancos
Jiangmin	11.0.800	2009.08.28	-
K7AntiVirus	7.10.830	2009.08.28	-
Kaspersky	7.0.0.125	2009.08.28	-
McAfee	5723	2009.08.28	PWS-Banker.gen.b
McAfee+Artemis	5723	2009.08.28	Artemis!504F1C591479
McAfee-GW-Edition	6.8.5	2009.08.28	Trojan.Spy.Banker.DS.5102592
Microsoft	1.5005	2009.08.28	TrojanSpy:Win32/Bancos.gen!C
NOD32	4378	2009.08.28	probably a variant of Win32/Spy.Banker.QEO
Norman		2009.08.28	W32/Banker.EKFF
nProtect	2009.1.8.0	2009.08.28	-
Panda	10.0.2.2	2009.08.28	Trj/CI.A
PCTools	4.4.2.0	2009.08.28	-
Prevx	3.0	2009.08.28	-
Rising	21.44.40.00	2009.08.28	Trojan.PSW.Win32.Banker.dnl
Sophos	4.45.0	2009.08.28	Mal/Generic-A
Sunbelt	3.2.1858.2	2009.08.28	-
Symantec	1.4.4.12	2009.08.28	Infostealer.Bancos
TheHacker	6.3.4.3.389	2009.08.27	-
TrendMicro	8.950.0.1094	2009.08.28	-
VBA32	3.12.10.10	2009.08.28	-
ViRobot	2009.8.28.1907	2009.08.28	-
VirusBuster	4.6.5.0	2009.08.28	TrojanSpy.Banker.CDVF
Additional information
File size: 5102592 bytes
MD5   : 504f1c5914799e5122c69620c0b892e2
SHA1  : 32980745998151bda4a9e3bab767201ebc52fc0a
SHA256: 54d974192dd53aba186d56803087224ff8f8b0aba9687604332891842bb5ef58

[=]Prolog[=]
Tak jak pewnie udało wam się zauważyć w poprzednim poście malware ten posiada np. zaszyfrowane ścieżki, do których zostaną wykonana jego kopie. Przykładowy zaszyfrowany ciąg wygląda tak:
GpfSH6zZTMrbRdHp865kP21JPNHqQMvdSrn1R6mWLNDbSdDSJMLkTI19RcbZQM5oN51oRsToOMrXSrn9RcbZQM5iQNfXSbnNQMvaRtTpCp8kPNXb
gdzie po deszyfrowaniu otrzymujemy łańcuch:
C:Documents and SettingsAll UsersMenu IniciarProgramasInicializarWindows32.exe
W jaki sposób funkcjonuje ten algorytm ? Tego dowiemy się już za chwilę.
Wcześniej jednak sprecyzuje „elementy”, które w tym malware’e wymagają deszyfrowania:
– ścieżki, do który kopiowany jest malware
– tytuły okien IE(malware używa tytułów okien do rozpoznania czy user znajduje się obecnie na stronie, dla której trojan ma przygotowany np. fałszywy panel logowania)
– treść fałszywych komunikatów mówiących o tym, że np. Internet Explorer wykonał
nieprawidłową operacje i zostanie zamknięty.

w niektórych wersjach także:
– login&hasło do serwera ftp/mysql używanego jako drop host
– adresy email na które mają zostać przesłane skradzione dane

Warto tutaj wspomnieć o różnicy, która występuje w podejściu autorów trojana obecnego i tego z poprzedniego postu. Jak pamiętamy tam autor nie dość, że stosował różnego rodzaju klucze xor’ujące to jeszcze zmieniały się w nieznacznym stopniu same procedury szyfrowania. Tutaj spoglądając na wygląd ciągów reprezentujących zaszyfrowane dane:
encrypted_strings
Można zakładać, że procedura deszyfrująca jest jedna, globalna. Po dokładnej analizie okazuje się, że faktycznie tak jest i nadszedł czas żeby przyjrzeć się jej bliżej.
Oczywiście jej lokalizację można w prosty sposób ustalić po przez przejście do kawałka kodu, który odwołuje się do jednego z zaszyfrowanych ciągów:
decryption_routine_call
Wywołanie funkcji deszyfrującej. Oczywiście argumenty, są przekazywane zgodnie z konwencja __fastcall typową dla Borlanda.
[=]Analiza[=]
Procka deszyfrująca przedstawia się następująco:
decryption_routine
gdzie:
ESI – długość zaszyfrowanego ciągu
Local.1 – pointer na zaszyfrowany ciąg

Jak widać procka jest o wiele pokaźniejsza od tych, które mogliśmy obserwować w poprzednim malware’e.
[=]Deszyfrowanie[=]
Bez większe zastanawiania się tworzymy decryptor, który w pythonie przedstawia się następująco:

import sys
#Delephant decryption script
ascii_table = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz+/"
def decrypt(encrypted):
    decrypted = []
    local_4 = 0
    edi     = 0
    for index in range(0,len(encrypted)):
        pos = ascii_table.find(encrypted[index])
        if pos < 0:
            return "Encrypted string is in unproper format"
        pos = pos + (local_4 << 6)
        local_4 = pos
        edi = edi + 6
        if edi < 8:
            continue
        edi = edi - 8
        local_4 = local_4 % ( 1 <> (edi & 0xff) ) & 0x800000ff
        if pos < 0:
            pos = ( (pos - 1) & 0xffffff00 ) + 1
        decrypted.append( chr(pos) )
    return "".join(decrypted)
if __name__ == "__main__":
    if len(sys.argv) < 2:
        print "Usage: %s encrypted_string" % sys.argv[0]
        sys.exit(0)
    print decrypt(sys.argv[1])


Rezultat deszyfrowania losowo wybranych stringów:
result_of_decryption
Warto tutaj zauważyć jedną znacząco różnice:

MOV EAX,[Local.5] ; kolejny znak z zaszyfrowanego ciagu
MOV EDX,zloavgtr.00480BAC ; ASCI „0123456789ABCD….”
CALL StrPos
MOV EBX,EAX
DEC EBX

i odpowiednik tego kodu w Python’e:

pos = ascii_table.find(encrypted[index])

Trzeba być tutaj świadomym jednej rzeczy, a mianowicie tego ze StrPos Borlandowy indexuje pozycje znaków w stringu od 1 a find Pythonowy od 0. Dlatego też w kodzie pythona nie pojawia się dekrementacja wartości pozycji znaku do odszyfrowania.
[=]Epilog[=]
Jak można zauważyć, procedura deszyfrująca tego trojana jest objętościowa ok.3 razy większa od tych, z którymi mieliśmy do czynienie w poprzednim sampel’u co jednak nie przeszkodziło nam w stworzeniu python’ego decryptor’a.
Jeżeli chodzi o algorytmy wykorzystywanego przez ten malware’u do „szyfrowania„ skradzionych danych to są to przeważnie:
– URL Encode
– Base64

ze względu na powszechność nie zostały one tutaj opisane.
Na sam koniec dla ciekawych, chcących przeanalizować krok po kroku działanie decryptor’a pare stringów do deszyfracji:

“IKLuS6nlScK”
“IMvcRt9jOUVZRo1fRcDlSd9bT64X851oPMLkOsXX86DlSd9bT65jPMvqPI1l86DXRN1l84HfPsbqRou”
“H65aRtCWIMvZRt9oPNHlSomWK6zo86PXTczo86HfPsbqPI1kRtPXRMLkT6Kk”
“K6zo86PXTczoB21fRcPlScrb86baPMvqQMPfOs7dusyi865dPMvZQM4i86DlRdHX”
“Kt8eOIak84PXTczo86HfPsbqON8WOI1pTM4WSsLkQ64WP64WT65YPMnX86DlSd9bT65jPMvqPIu”
“LNDruN9fRoukBYukBYukBYukBZe”
“K6zo86rlT6bsRo1aPI1JPMTrSc5kvs4WSsLr84D1KbJ3Jo14HI1JHKTLKa5Enq4WP6LsPI1pPN8WKcLZOMHXStHoOMHlB21JRsnfOsbqOMrlSo1nTMKWLczZwY18OM9fR6bqPI1pPNKWGs5oTEDl86Hb85DbPtLoOMxdOI1ERtPXRMLkT6Kk”
“Gc5kOsyWINHX+Y0j84PbQNHl851XSc4WLczZwY0WBI1DQMDoRtDlPdGWIMvqPN9kPNGWHNXmR6zoPN8”

Posted in Analiza, Malware, RE | Tagged , , , , , , , | Leave a comment

Reversowanie trojanów pisanych w Delphi/BCB.

Jako, że kolejny post z cyklu „Algorytmy (de)szyfrowania wykorzystywane przez twórców trojanów bankowych” , który mam w planach napisać, będzie o algorytmach szyfrowania wykorzystanych w trojanach napisanych w Delphi 😀 (tak tak, poczekajcie jeszcze pare lat i będzie wysyp trojanów pisanych w .NET… using System.malwares.bankers; i go go go !!! :D) , to postanowiłem wcześniej napisać co nie co o moim ogólnym podejściu do trojanów pisanych w tym właśnie języku oraz narzędzi ułatwiających ich analizę.
Nasz dzisiejszy „bohater” przedstawia się następująco:
[=]Dane[=]

Antywirus	Wersja	Ostatnia aktualizacja	Wynik
a-squared	4.5.0.24	2009.08.02	Trojan-Banker.Win32.Banker!IK
AhnLab-V3	5.0.0.2	2009.08.01	Win-Trojan/Banker.7315456.D
AntiVir	7.9.0.238	2009.08.02	TR/Agent.GGO.1
Antiy-AVL	2.0.3.7	2009.07.31	-
Authentium	5.1.2.4	2009.08.02	W32/Trojan.BZCX
Avast	4.8.1335.0	2009.08.01	Win32:Banker-CXH
AVG	8.5.0.406	2009.08.02	PSW.Banker4.AJJ
BitDefender	7.2	2009.08.02	Generic.Spy.Bank.ZWQ.720719B9
CAT-QuickHeal	10.00	2009.07.30	-
ClamAV	0.94.1	2009.08.02	-
Comodo	1840	2009.08.02	TrojWare.Win32.Spy.Banker.OHT
DrWeb	5.0.0.12182	2009.08.02	Trojan.PWS.Banker.12795
eSafe	7.0.17.0	2009.07.30	Win32.Banker.cwo
eTrust-Vet	31.6.6650	2009.08.01	-
F-Prot	4.4.4.56	2009.08.02	W32/Trojan.BZCX
F-Secure	8.0.14470.0	2009.08.01	Trojan-Banker.Win32.Banker.fgw
Fortinet	3.120.0.0	2009.08.02	Spy/Banker
GData	19	2009.08.02	Generic.Spy.Bank.ZWQ.720719B9
Ikarus	T3.1.1.64.0	2009.08.02	Trojan-Banker.Win32.Banker
Jiangmin	11.0.800	2009.08.02	-
K7AntiVirus	7.10.808	2009.08.01	-
Kaspersky	7.0.0.125	2009.08.02	Trojan-Banker.Win32.Banker.fgw
McAfee	5695	2009.08.01	PWS-Banker.gen.cb
McAfee+Artemis	5695	2009.08.01	PWS-Banker.gen.cb
McAfee-GW-Edition	6.8.5	2009.08.02	Heuristic.BehavesLike.Win32.Spyware.K
Microsoft	1.4903	2009.08.02	TrojanSpy:Win32/Banker.USW
NOD32	4299	2009.08.02	Win32/Spy.Banker.OHJ
Norman	6.01.09	2009.07.31	W32/Banker.BQZT
nProtect	2009.1.8.0	2009.08.02	-
Panda	10.0.0.14	2009.08.02	Trj/Banker.gen
PCTools	4.4.2.0	2009.08.02	TrojanSpy.Banker.ARXE
Rising	21.40.62.00	2009.08.02	Trojan.Spy.Win32.Banker.c
Sophos	4.44.0	2009.08.02	Mal/DelpBanc-A
Sunbelt	3.2.1858.2	2009.08.02	Bulk Trojan
Symantec	1.4.4.12	2009.08.02	Infostealer.Bancos
TheHacker	6.3.4.3.375	2009.08.01	Trojan/Spy.Banker.cwo
TrendMicro	8.950.0.1094	2009.07.31	-
VBA32	3.12.10.9	2009.08.02	Trojan-Spy.Win32.Banker.cwo
ViRobot	2009.7.31.1863	2009.07.31	-
VirusBuster	4.6.5.0	2009.08.02	TrojanSpy.Banker.ARXE
Dodatkowe informacje
File size: 7319552 bytes
MD5   : d9e6a8e34c8c6f33919c33889c23811c
SHA1  : 38bb2fbb82e419d044a2a9e9199eb948eb891679
SHA256: 9fe271dbe89dd60d072789f49197d217edf75d9ed5a46fc5e94e28c7522341d8
TrID  : File type identification
65.9% (.EXE) InstallShield setup (43065/22/16)
13.0% (.EXE) Win32 Executable Generic (8527/13/3)
11.6% (.DLL) Win32 Dynamic Link Library (generic) (7583/30/2)
3.1% (.EXE) Win16/32 Executable Delphi generic (2072/23) 3.0% (.EXE) Generic Win/DOS Executable (2002/3) ssdeep: 98304:aVwdUDdAVtUSlUTE2PIEH4B4Yo1qIZtDxHw7SbrKD:anAUkQPIYA49m PEiD : - RDS : NSRL Reference Data Set

Ja kto przeważnie bywa sygnaturki, są bardzo ooooooogggggólne. Jeżeli nawet, któraś z nich wskazuje na jakiś bardziej konkretny typ trojana to analiza techniczna bardzoooooo mija się z rzeczywistością, weźmy chociażby :
Symantec – Infostealer.Bancos
Morał jest taki, że ludki pracujące nad tego typu malware’em, a m.in. są to osoby z brazylijskich slumsów oraz innych biednych krajów A.Pd, (polecam tutaj wystąpienie
Mikko Hypponen : Online Crime and Crime Online
) nie robią sobie urlopów :D.
[=]Prolog[=]
Jeżeli kiedykolwiek zdarzyło Ci się pisać w BCB/Delphi aplikację z GUI (bo na takich będziemy się skupiać) to możesz podejrzewać, a jeżeli już je reversowałeś to jesteś świadom, że narzut kodu wygenerowanego przez kompilator, który nie specjalnie nas interesuje jest dość spory. Dodatkowo mamy tu do czynienia z budową silnie obiektową (masa metod wirtualnych, delegaty [tak tak, borland dostarcza do tego celu specyfikatora „__closure”],wielodziedziczenie,itp.) przez co nasza analiza jest nieco „utrudniona”(interpretuj. utrudniać: wydłużać czas zabawy :D). Dlatego też, pokarze parę narzędzi oraz plugin’ów do nich, które przyspieszą samą analizę kodu jak i pomogą nam na znalezienie tych fragmentów, które zastały napisane przez autora trojana.
[=]Analiza[=]
Na początku naszej analizy zastanówmy się jakie akcje są przeważnie wykonywane podczas początkowego uruchomienia trojana. Z mojego doświadczenia wynika, że są to przeważnie następujące działania :
– kopiowanie własnej instancji do katalogu systemowego
– dodanie wpisu w rejestrze pozwalającego na auto uruchomienie trojana po reboot’e systemu
– rejestracja zainfekowanej maszyny

Ok, na początek tyle ustaleń nam wystarczy teraz pojawia się kwestia jak zlokalizować ten kod?
Oczywiście niektórzy z was mogli pomyśle, od razu o rozwiązaniu w stylu ustawianiu BP na api, które w jakiś sposób są powiązane z wyżej wymienionymi akcjami. Jest to na pewno jakiś sposób, ale w przypadku aplikacji Borlandowskich warto użyć paru dodatkowych narzędzi poza disassambler’em i debugger’em żeby osiągnąć naprawdę interesujące rezultaty, ale o tym za chwilę. Obejrzyjmy wstępnie kod trojana:
ida_wstepny_kod
Na chwilę obecną powyższy kod nie daje nam zbyt wiele informacji, widać „rzetelne sprawdzanie błędów” 😀, tworzenie mutex’a i wywołanie paru metod na globalnym obiekcie off_500864.Pierwszą rzeczą, która z pewnością ułatwi nam dalsze analizowanie kodu są FLIRT’y(więcej informacji TU), które dostarcza nam IDA Pro w wersji komercyjnej. Trudno mi powiedzieć jak wygląda kwestia z wersją Free, niestety nie testowałem, także jeżeli ktoś z was będzie testował lub już to zrobił to dajcie znać ;). Załadujmy odpowiednie FLIRT’y i rzućmy okiem na kod po tym zabiegu:
flirts
code_after_flirts_load
Ahhh….na mój gust kod wygląda już znacznie lepiej ;).
Jak widać IDA zastąpiła większość wywołań VCL’owych metod sygnaturami przez co kod jest znacznie czytelniejszy. Warto jeszcze tutaj zastosować tryb:
Options->Demangled names
I przy wyborze „Show demangled C++ names as” zaznaczyć radio box „Names” czego rezultatem będzie poniższy wynik:

code_after_flirts_load_comments_as_FunName
Wracając do kodu, osoby, które miały styczność czy to z BCB czy Delphi już na pewno rozpoznają ten fragment.Tak tak jest to standardowy kod, którego główny cel możemy określić na:
– automatyczne tworzenie form używanych w projekcie
oraz obsługę komunikatów do nich napływających.

Porównamy teraz kod z pod IDA’y z kodem jednej z moich aplikacji pisanych w RAD Studio 2007( dawne wersje nazywane były Borland C++ Builder):
code_from_RAD
Tak jak widać kod jest uderzająco podobny, z czego morał taki, że dzięki IDA’e i sygnaturką zaoszczędziliśmy czas na analizowaniu standardowych VCL’owych metod.
Ok, wszystko fajnie, ale dalej nie mamy żadnych szczegółów związanych z naszymi wcześniejszymi ustaleniami. Po listingu z IDA’y możemy stwierdzić, że przy uruchomieniu trojana tworzone są automatycznie 3 formy, co wiąże się z wywołaniem pewnych zdarzeń. Zanim jednak omówimy sobie te zdarzenia przyjrzyjmy się wszystkim formą. Do tego celu oczywiście posłużymy się resource editor’em. Wyróżnie tutaj dwa:
Komercyjny:
PE Explorer: genialny edytor zasobów i nie tylko. Umożliwia podgląd form znajdujących się w zasobach, komponentów znajdujących się na nich (Timerów,Buttonów,Obrazów,…) oraz ich właściwości.
Darmowy:
DFM Editor: autorstwa MiTeC’ka jest darmowym prawie że odpowiednikiem PE Explorer’a, jeżeli chodzi o samo edytowanie zasobów. Jedynym mankamentem tego narzędzia jest brak możliwości podglądu obrazków znajdujących się na formach co w przypadku identyfikacji przeznaczenia formy(np. dzięki umieszczonym bannerą czy imitacją form przeznaczonych do logowania, możemy określić jakich banków klienci są narażeni na atak przez danego trojana już po samym analizowaniu zasobów) jest bardzo użyteczne.
W naszych badaniach identyfikacja przeznaczania danej formy pod kątem konkretnego banku jest zbyteczna ( a nawet z paru względów zabroniona :P). Rzućmy okiem do zasobów:
resource_preview
(Niektóre nazwy form były zbyt oczywistymi skrótami nazw banków przez co musiałem je troszeczkę ocenzurować.)
Jak widzimy trojan ten posiada sporą dawkę fałszywych form imitujących panel’e do logowania, wirtualne klawiatury, a skończywszy na oknach prezentujących imitacje crash’u IE czy nawet BSOD’a :D.
Jest jednak parę form. :
TAup – Application update?
TCMD – Commands ?
TFUNC – Functions ?

które nie posiadają charakterystycznych Bitmap, lecz np. komponenty takie jak :
TTimer
TIdSMTP
TIdMessage

i tym formą się przyjrzymy.
Przeglądając komponenty znajdujące się na wyżej wymienionych formach szybko dochodzimy do wniosku, że tak naprawdę tylko TCMD jest formą, która może nas zainteresować, ponieważ:
TAup – co prawda posiada komponent TTimer lecz nie ma on podczepionego event handler’a.
aup
Czyżby autor trojana doznał chwilowego przebłysku oraz chęci dodania kolejnej funkcjonalności po czym, po krótkie chwili porzucił tą idee, oraz wszelkie elementy z nią związane? Tego się nigdy nie dowiemy.
TFUNC – ta forma jest kompletnie pusta.
Nie mogę tego inaczej skomentować niż jako wyjątkowego przejawu nonszalancji :D.

func
TCMD
Rzućmy okiem na najbardziej interesujące nas komponenty oraz ich własności:

object CMD: TCMD
  OnActivate = FormActivate
  OnCreate = FormCreate
  object TPrincipal: TTimer
    OnTimer = TPrincipalTimer
    Left = 8
  end
  object Tcook: TTimer
    Interval = 100
    OnTimer = TcookTimer
    Left = 40
  end
  object Tsite: TTimer
    Enabled = False
    Interval = 50
    OnTimer = TsiteTimer
    Left = 72
  end
  object Tjanela: TTimer ;
            nie wierzcie, że event handler jest ustawiany dynamicznie:P
	To raczej kolejny przejaw wrodzonej rozrzutności autora malware’u.
    Left = 104
  end
  object Taup: TTimer
    Enabled = False
    Interval = 720000
    OnTimer = TaupTimer
    Left = 136
  end
end

resource_preview_TCMD
Jak widać forma ta posiada obsłużone dwa zdarzenia:

  OnActivate = FormActivate
  OnCreate   = FormCreate

Oba, są idealne do tego żeby podpiąć w ich obsłudze wszystkie 3 wymienione przeze mnie początkowe działania wykonywane przez większość trojanów.
W pozostałych event handler’ach:

TaupTimer
TsiteTimer
TcookTimer
TPrincipalTimer

związanych z eventem OnTimer:
można się raczej spodziewać akcji takich jak:
– aktualizacji trojana
– wysyłania skradzionych danych do twórcy malware’u
– monitorowania aktualnych procesów w systemie (i cykliczne ubijanie np. firewall’a)
czy monitorowania odwiedzanych stron.

Ok., mamy więc ustalone parę procek, których kod chcielibyśmy prześledzić. Nasuwa się pytanie:
W jaki sposób uzyskać ich VirtualAddress?
Odpowiedzią jest:
DeDe
Wszystkie informacje o DeDe jak i sam tool znajdziecie tutaj RCE Tools.
Ładujemy naszego trojana w DeDe i po parunastu sekundach otrzymujemy taki o to rezultat:
_preview_into_dede
Wspaniale! Jak możemy zaobserwować na powyższym screen’e DeDe dostarczyło nam informacji o zdeklarowanych przez użytkownika klasach (np. TCMD), Event handler’ach oraz miejscach ich lokalizacji!
Podsumowując uzyskane informacje mamy:
OnTime:

TaupTimer         = 004FD5C8
TsiteTimer          = 004FD0A0
TcookTimer 	      = 004FC834
TPrincipalTimer = 004FACE4

oraz eventy związane bezpośrednio z formą:

OnActivate = FormActivate =  004F7C44
OnCreate   = FormCreate    =  004FAC44

Oczywiście teraz nasza analiza staje się o wiele wiele prostsza, ponieważ bezpośrednio możemy zająć się interesującymi nas fragmentami kodu bez przedzierania się przez standardowe procedury.
Dla potwierdzenia wcześniejszych założeń związanych z operacjami wykonywanymi na starcie przez trojana, rzućmy okien na kod wykonywany przy event’e OnCreate, czyli:
FormCreate @ 004FAC44:
oncreate
Mhmm sporo call’i, których IDA nie rozpoznała jako standardowych wywołań, więc najprawdopodobniej, są to pomocnicze metody napisane przez „programistę”. Zanim jednak przejdziemy do ich przeglądania, skorzystamy ponownie z dobrodziejstwa informacji dostarczanych przez DeDe, a mowa tutaj dokładnie o pliku MAP.
map_export
Dzięki wyexportowaniu informacji takich jak:

- event handlers
- control references

do pliku map
map_file_preview
oraz załadowaniu go do IDA’y: (polecam plugin Fast IDB2Sig and LoadMap) disassemblowany przez nas kod staje się ponownie jeszcze bardziej czytelny:
oncreate_with_map
To co najbardziej rzuca się w oczy to fakt zamiany nazwy call’a i jego komentarza z :

loc_4FACBD:
mov     dl, 1
mov     eax, [ebx+318h] ;
call    unknown_libname_172 ; Delphi2006/BDS2006 Visual Component Librar

na

loc_4FACBD:
mov     dl, 1
mov     eax, [ebx+318h] ; Taup:N.A.
call    SetEnabled      ; ExtCtrls.TTimer.SetEnabled(TTimer;Boolean)

odrazu widać, że jest to fragment kodu aktywujący Timer : Taup.
Ok, przyjrzyjmy się którejś z metod, której sposób działania jest nam jeszcze nie znany. Sprawdźmy jako pierwszą :
sub_483BE8
add_to_registry
Ahh jak widać metoda ta wykonuje operacje na rejestrze, a po głębszej analizie okazuje się, że dodaje ona do klucza :
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun
wartość : Windows32 zawierającą scieżkę do kopi trojana, czyli
sub_483BE8 możemy zaklasyfikować jako :
– dodanie wpisu w rejestrze pozwalającego na auto uruchomienie trojana po reboot’e systemu

Super!!! jedno z założeń odnalezione. Idźmy dalej:
sub_483D78:
instation_copy
Jak widać w najwyżej położonym bloku widocznym na screen’e, zostaje sprawdzona wersja systemu operacyjnego ( Windows XP/NT/98 itd.) i na tej podstawie podejmowane, są działanie takie jak:
deskrypcja stringu
pobranie parametru wywołania aplikacji
oraz wykonanie kopi pliku gdzie parametrami, są rezultaty operacji dwóch poprzednich funkcji
…czy coś wam to mówi 😀 ?,,,,,a teraz
CopyFile(ParamStr(),Decrypt()) :D?
Tak jest! Oczywiście widać tutaj bloki instrukcji odpowiedzialnych za kopiowanie instancji trojana do charakterystycznych katalogów uzależnionych od wersji systemu Windows.
sub_483D78
– kopiowanie własnej instancji do katalogu systemowego

Na tym poprzestaniemy nasze dalsze dochodzenie, bo nie dokładna analiza techniczna była naszym celem, a jedynie przekonanie się o tym jaki potencjał niesie zastosowanie :
– sygnatur IDA’y
– informacji o adresach metod/obiektów uzyskanych dzięki DeDe
oraz pliku MAP

A co z naszym ulubionym Olkiem :D? Czyż nie było by miło prowadzić dynamicznej analizy kodu mając do dyspozycji możliwości Olka ,sygnaturki IDA’y i możliwość załadowania pliku MAP ? Oczywiście byłoby, a najlepsze w tym jest to, że da się to osiągnąć!
[=]Olly’s time[=]
Żeby osiągnąć powyższe możliwości wystarczy tak naprawdę jeden plugin:
GoDup
GoDup_preview
Żeby dostrzec różnice po zastosowaniu kolejnych zabiegów w wykonaniu tego pluginu, ustawmy się na kod handler’a TPricipalTimer @ 004FACE4:
pure_olly_code
po zastosowaniu sygnatur:
sig_olly_code
dorzućmy jeszcze informacje z pliku MAP:
map_olly_code
Czyż kod nie wygląda piękniej? :D.

Posted in Analiza, Malware, RE, Uncategorized | Tagged , , , , , , , , , , | Leave a comment

Algorytmy (de)szyfrowania wykorzystywane przez twórców trojanów bankowych.

Post otwierający serie postów traktujących o sposobie szyfrowania i deszyfrowania czy to:
– plików konfiguracyjnych
– skradzionych danych
– ciągów znaków reprezentujących np. nazwę winapi

wykorzystywanym przez twórców trojanów bankowych.
Przedstawiając kolejne rodziny trojanów postaram się je ułożyć w kolejności zaczynając od tych stosujących najmniej skomplikowany sposób szyfrowania do tych prezentujących coraz to bardziej złożony rodzaj algorytmów ( o ile ,którykolwiek z nich można tak określić :P).
Pierwszy twór, któremu się przyjrzymy na VirusTotal przedstawia się w sposób następujący: 7050369f20acdb4587872ff1eccf43f3cccddf5dc03c7cd6a936a383a6863aac
[=]Dane[=]

Antivirus	Version	Last Update	Result
AhnLab-V3	5.0.0.2	2009.04.26	Dropper/Agent.61440.AF
AntiVir	7.9.0.156	2009.04.25	TR/BHO.gcw
Authentium	5.1.2.4	2009.04.25	W32/Dropper.AHBB
Avast	4.8.1335.0	2009.04.25	Win32:Trojan-gen {Other}
AVG	8.5.0.287	2009.04.26	Dropper.Agent.LCJ
BitDefender	7.2	2009.04.26	Trojan.Generic.1252968
CAT-QuickHeal	10.00	2009.04.25	TrojanDropper.Agent.abjf
Comodo	1130	2009.04.25	TrojWare.Win32.Trojan.Agent.Gen
DrWeb	4.44.0.09170	2009.04.26	Trojan.Fakealert.3764
F-Prot	4.4.4.56	2009.04.25	W32/Dropper.AHBB
F-Secure	8.0.14470.0	2009.04.25	Trojan-Dropper.Win32.Agent.abjf
Fortinet	3.117.0.0	2009.04.26	PossibleThreat
GData	19	2009.04.26	Trojan.Generic.1252968
Ikarus	T3.1.1.49.0	2009.04.26	Trojan-Dropper.Agent
K7AntiVirus	7.10.716	2009.04.25	Trojan-Dropper.Win32.Agent.abjn
Kaspersky	7.0.0.125	2009.04.26	Trojan-Dropper.Win32.Agent.abjf
McAfee	5596	2009.04.25	Generic.dx
McAfee+Artemis	5596	2009.04.25	Generic.dx
McAfee-GW-Edition	6.7.6	2009.04.26	Trojan.BHO.gcw
Microsoft	1.4602	2009.04.26	Trojan:Win32/Relbma.A
NOD32	4035	2009.04.25	Win32/BHO.NDB
Norman		2009.04.24	W32/Agent.KPCN
nProtect	2009.1.8.0	2009.04.26	Trojan-Dropper/W32.Agent.61440.AW
Panda	10.0.0.14	2009.04.26	Generic Trojan
Prevx1	3.0	2009.04.26	High Risk Worm
Sophos	4.41.0	2009.04.26	Mal/Generic-A
Sunbelt	3.2.1858.2	2009.04.24	Trojan-Downloader.Win32.FraudLoad.vdxo
Symantec	1.4.4.12	2009.04.26	Trojan Horse
TheHacker	6.3.4.1.314	2009.04.26	Trojan/Dropper.Agent.abjf
TrendMicro	8.700.0.1004	2009.04.25	TROJ_AGENT.PRPR
VBA32	3.12.10.3	2009.04.25	Trojan-Dropper.Win32.Agent.abjf
VirusBuster	4.6.5.0	2009.04.25	Trojan.DR.Agent.IMHD
Additional information
File size: 61440 bytes
MD5   : fa1faad9a5db4f33173ee0b439e410f6
SHA1  : 5aea25ef14f52930ebc3520a1bf43b1b74573899
SHA256: 7050369f20acdb4587872ff1eccf43f3cccddf5dc03c7cd6a936a383a6863aac
PEiD  : Armadillo v1.71

Jak widać nazwy sygnatur, są bardzo ogólne co może wskazywać jedynie na wieeeeele mutacji tej rodziny pojawiających się w sieci.
[=]Prolog[=]
Tak jak wspominałem wcześniej będziemy się przyglądać trojanom stosującym coraz to bardziej wyrafinowane metody szyfrowania, więc zgodnie z nasza konwencją niniejszy
sampel, a dokładnie metody stosowane przez niego nie powinny szokować( no chyba, że prostotą :D).
Jakie elementy będą „wymagały” tu deszyfrowania:
– plik konfiguracyjny
– dll’ka, która jest instalowana w systemie jako BHO
– adres url wskazujący na drop host

Napisałem „wymagały” ,ponieważ tak na dobrą sprawę akurat w tym konkretnym samplu np.autor postanowił ułatwić badaczowi sprawę i plik konfiguracyjny jest dropowany do filesystem’u już po deszyfrowaniu :D. Inna kwestią jest to, że zamiast deszyfrować konkretne elementy, można zrobić dump’a całego procesu i np. w przypadku kiedy config jest deszyfrowany przez trojana tylko i wyłącznie na czas użycia, liczyć na to, że w dump’e znajdziemy go już w plain-text’e. Podejść do sprawy jest wiele, ale w naszych badaniach zależeć nam będzie na tym, żeby poznać algorytm szyfrowania i w miarę możliwości go odwrócić. Oczywiście zdarzają się przypadki gdzie:
– nie zależy nam na poznawaniu algorytmu używanego przez trojana, bo jest to sampel należący do rodziny, która widzimy pierwszy raz i nie koniecznie będzie dla nas użyteczny z różnych względów. Wtedy oczywiście idziemy po najmniejsze lini oporu.
– procedura deszyfrująca jest na tyle duża, a my na tyle leniwi ;], lub mało zainteresowani jej odwracaniem nie podejmujemy się pisania dekryptora od zera, ale np. wykorzystujemy prockę używaną przez trojana w charakterze shellcode’u (o tym więcej w dalszych postach).

[=] Analiza [=]
Ok., pora na analizę naszego celu. Jako, że zależy nam tylko na procedurach (de)szyfrującyh to bezpośrednio będę wskazywał elementy oraz ich lokalizacje, które będą wymagały naszej interwencji. Ewentualne pokaże sposoby na znalezienie interesujących nas części kodu procedur.
Tak na dobrą sprawę wszystkich istotne elementy, które postaramy się deszyfrować znajdują się w zasobach(‘Resource Directory’) pliku wykonywalnego. Może podejrzeć zasoby używając do tego celu np.
CFF Explorer’a:
resource_dirView
Jak widać na powyższym screen’e dane w takiej postaci niczego nam nie mówią, ale w miarę wykonywanej przez nas deszyfracji wszystko stanie się bardziej klarowne. Deszyfrować zwartość zasobów zaczniemy od końca czyli od „WFP”.Zanim zaczniemy, wykonajmy dump zasobu do plik np.
C:config i sprawdźmy jego entropię:
config_entropy
Już spieszę z wyjaśnieniami. Skala, którą widać po prawej reprezentuje poziom entropii w zakresie od 0-8. Tak jak obiecywałem algorytm(y) szyfrowania użyty w tym trojanie będzie prosty o czym już teraz możemy się przekonać analizując wykres. Wartości funkcji, są dość nie regularne i rozciągają się w zakresie od 4,2 do 5,4. Od razu wspomnę, że ciekawszych procek szyfrujących można się spodziewać w przypadku entropii na poziomie 7-8.
Dla porównania wykres entropii dump’a traffic’u zawierającego dll’ki, ściągane przez Mebroot’a:
C&C_response_entropy
[=]Analiza procedur szyfrujących[=]
Jak już wiemy interesujące nas bloki danych znajdują się w resource directory. Teraz rodzi się pytanie w jaki sposób odnaleźć funkcje (de)szyfrującą/e? Każdy kto pisał aplikacje z użyciem winapi, korzystającą z katalogu zasobów skojarzył od razu funkcje „FindResourceA/W”, która zwraca uchwyt do zasobu, którego nazwę podamy jako jeden z parametrów tego api.
Więc nasuwają się tutaj dwa podejścia, a tak naprawdę jedno chyba najbardziej logiczne ;].
– wyszukać wszystkie referencje do wywołań api FindResourceA/W
albo odnaleźć wszystkie referencje do stringu „WFP” .

Oczywiście posłużymy się tutaj podejściem drugim które najprawdopodobniej od razu wskaże nam okolice kodu zawierającego procedurę deszyfrującą.
wfp_resource
Ohoo…wygląda na strzał w dziesiątkę, co prawda na razie nie widać jakichkolwiek manipulacji na uzyskanym pointerze do zasobu, zerknijmy jednak do procedury :
CALL zly_troj.0040155F
mając na uwadze, że argumentami tej procki są:
arg1 : pointer do zasobu „WFP”
arg2 : rozmiar zasobu „WFP”

wfp_decryption_proc
Ahhh udało nam się zlokalizować prockę deszyfrującą!(zielona ramka).
Jak widać okazała się nią prosta operacja xorująca każdy bajt z kluczem o wartości:
0x13.
[=]Deszyfrowanie[=]
Oczywiście po tym co właśnie zobaczyliśmy stworzenie własnego deszyfratora, który „sksoruje”, każdy bajt dumpu zasobu, który wcześniej wykonaliśmy z kluczem 0x13.
Świetnie się do tego nada JEDNOLINIJKOWY skrypt w python’e:
"".join(map(lambda x: chr(ord(x)^0x13),file(r’C:config’,’rb’).read()))
, a oto rezultat:
decrypted_wfp
widać teraz, że rzeczywiście jest to plik konfiguracyjny zapisany w xml’u.
Przejdźmy do następnego zasobu.
„REM”
Rzućmy okiem na entropię:
rem_entropy
Mhmm…tutaj już entropia wygląda ciekawiej, więc z pewnością możemy się spodziewać czegoś więcej niż tylko prostego xor’owania.
Oczywiście, miejsce z istotną dla nas procką znajdujemy analogicznie do poprzedniego przypadku, a naszym oczom ukazuje się taki o to kod:
rem_decryption_routine
Jak widzimy, w tym przypadku klucz xor’ujący nie jest stały. Jego wartość będzie zmieniała się cyklicznie po każdej iteracji, stąd też widoczne na wykresie entropii zmiany w kierunku wyższego zbioru wartości.
Warto zwrócić uwagę na dwie istotne kwestie, które są wykonywane przed wejściem do pętli:

ESI – pointer na zaalokowaną pamięć, która będzie zawierać deszyfrowane dane.
004013CD  |.  C606 4D       MOV BYTE PTR DS:[ESI],4D
004013D3  |.  C646 01 5A    MOV BYTE PTR DS:[ESI+1],5A

4D5A ,czy coś wam to mówi ?:D. Oczywiście jest to magic number, który zawsze powinien znaleźć się na początku pliku PE.
Jak widać autor trojana dodaje magic number dopiero w momencie deszyfrowania. Takie podejście może świadczyć jedynie o tym iż autor chciał utrudnić wykrycie potencjalnie niebezpiecznego zasobu antywirusą czy innym skanerą. Drugą kwestią jest wyliczenie stałej która będzie wykorzystywana do indexowania zaszyfrowanych danych. Jej wyliczenie wygląda następująco:

004013D9  |.  895D FC       MOV [LOCAL.1],EBX ; EBX = encrypted_data
004013DC  |.  2975 FC       SUB [LOCAL.1],ESI     ; ESI   = decrypted_data

następnie w pętli mamy: (stale wartości odpowiednie do pierwszej iteracji)

EDI = 2 ;
004013E5  |.  8D0C37        |LEA ECX,DWORD PTR DS:[EDI+ESI]
…
004013EA  |.  8B45 FC       |MOV EAX,[LOCAL.1]
…
004013EF  |.  321408        |XOR DL,BYTE PTR DS:[EAX+ECX]

widzimy, że w momencie xor’owania :
DL – cyklicznie zmieniający się klucz
a na co wskazuje BYTE PTR DS:[EAX+ECX]?
Prosty zapis matematyczny wszystko wyjaśnia:

LOCAL.1 = encrypted_data - decrypted_data
ECX = decrypted_data + 2
EAX = LOCAL.1
I w momencie xor’owania:
XOR DL,BYTE PTR DS:[LOCAL.1+decrypted_data+2]
podstawiajac za LOCAL.1
XOR DL,BYTE PTR DS:[ encrypted_data - decrypted_data
+decrypted_data+2]
,więc w ostateczności mamy
XOR DL,BYTE PTR DS:[ encrypted_data + 2]

ot taki troszeczkę nie intuicyjny sposób indexowania ;).
Przykładowy skrypt deszyfrujący:


def decrypt(encrypted):
    decrypted = []
    edi = 2
    decrypted.append('M')# 0x4d
    decrypted.append('Z')# 0x5a
    while edi != len(encrypted):
        edx = edi % 0x78
        edx = (edx << 1) & 0xFF
        decrypted.append(chr( (ord(encrypted[edi])^edx)&0xFF ))
        edi = edi + 1
    return "".join(decrypted)
if __name__ == "__main__":
    f = file(r"c:evil_dll",'rb')
    fw = file(r"c:decrypted_evil_dll",'wb')
    fw.write(decrypt(f.read()))
    f.close()
    fw.close()

i rezultat deszyfrowania:
decrypted_dll
Jak widać na screen’e w katalogu zasobów „REM” ukrywała się dll’ka.
Ostatni już katalog zasobów „CAS”. Jako, że danych w każdej pozycji katalogu CAS jest niewiele, trudno tutaj mówić/prezentować wykres rozkładu entropii. Przejdziemy więc od razu do sposobu ich deszyfrowania. Co prawda dane z tego zasobu, są ekstraktowane do systemu , (a dokładnie do rejestru )lecz w formie nie zmienionej. Dopiero dll’ka , która wcześniej mieliśmy przyjemność deszyfrować(a która jest dropowana do C:WINDOWSsystem32sxmg4.dll i rejestrowana jako BHO)
będzie pobierała te dane i deszyfrowała tylko w momencie zaistniałem potrzeby.
Zaszyfrowane dane w rejestrze prezentują się w następujący sposób(interesują nas tylko wartości Ad i Ad2):
cas_encrypted
HKEY_LOCAL_MACHINESOFTWARETSoft
Ok, weźmy pod lupę więc dll’ke: Stosując identyczne podejście jak w dwóch poprzednich przypadkach znajdujemy następujący kod:
cas_decryption
Kolejna różna od pozostałych procedura bazująca wciąż na xor’owaniu, lecz tym razem użyto stałego klucza o długości 3 bytów. Warto wspomnieć jakie konsekwencje niesie za sobą takie podejście oraz jak to rozwiązano w niniejszej implementacji:

ECX = ilość odczytanych(zaszyfrowanych) bajtów z wartości rejestru
100053B0  |.  6A 02         PUSH 2
100053B2  |.  33C0          XOR EAX,EAX
100053B4  |.  5A            POP EDX
100053B5  |.  889C0D F0FDFF>MOV BYTE PTR SS:[EBP+ECX-210],BL
100053BC  |.  3BCA          CMP ECX,EDX
100053BE  |.  76 31         JBE SHORT sxmg4.100053F1

Jak widać sprawdzane jest tutaj czy ilość bajtów które mają być odszyfrowane przekracza 2, ponieważ przy mniejszej ilości, w pętli już po pierwszej iteracji dostalibyśmy błędne dane (akurat przy tej implementacji nie wystąpi ,ani BO ani Off-by-One). To jedna kwestia, kolejną jest to, że długość danych do rozszyfrowania może nie być wielokrotnością 3’ki.
Więc należy tutaj zadbać o sprawdzanie czy w kolejnym kroku deszyfrowania mamy przynajmniej 3 bajt do przetworzenia. Jeśli nie, pętla powinna się zakończyć a pozostałe bajty( max 2) należy deszyfrować indywidualnie.
Sprawdźmy jak to zostało tu zaimplementowane:
Przed wejściem do pętli mamy :

EDX = 2
100053C0  |.  8DB5 F1FDFFFF LEA ESI,DWORD PTR SS:[EBP-20F]
100053C6  |.  2BD6                     SUB EDX,ESI
EBP – 210h = encrypted_data
,więc EBP – 20Fh == encrypted_data +1

w pętli:

…
100053E3  |.  8D3402        |LEA ESI,DWORD PTR DS:[EDX+EAX]
100053E6  |.  8DB435 F1FDFF>|LEA ESI,DWORD PTR SS:[EBP+ESI-20F]
100053ED  |.  3BF1          |CMP ESI,ECX
100053EF  |.^ 72 D7         JB SHORT sxmg4.100053C8

kiedy przyjrzymy się temu kawałkowi kodu mamy:

ECX = encrypted_data_length
EAX = index
EDX = 2 – (encrypted_data+1)
ESI = EDX + EAX
ESI <-  EBP + ESI – 20F == EBP -20F + ESI ==
(encrypted_data+1) + 2 –(encrypted_data+1)+ index
czyli ostatecznie
ESI = 2+index

,więc co iteracje w pętli( a jest to pętla do while) sprawdzane jest czy
index+2 < encrypted_data_length, jeżeli tak to pętla jest kontynuowana.
Po zakończeniu pętli możemy zauważyć to o czym wspominałem, a mianowicie indywidualne xor’owanie bajtów, które pozostały lub w przypadku kiedy długość zaszyfrowanych danych < 3:

100053F1  |> 3BC1          CMP EAX,ECX
100053F3  |.  73 08         JNB SHORT sxmg4.100053FD
100053F5  |.  80B405 F0FDFF>XOR BYTE PTR SS:[EBP+EAX-210],0F
100053FD  |>  8D50 01       LEA EDX,DWORD PTR DS:[EAX+1]
10005400  |.  3BD1          CMP EDX,ECX
10005402  |.  73 0F         JNB SHORT sxmg4.10005413
10005404  |.  80B405 F1FDFF>XOR BYTE PTR SS:[EBP+EAX-20F],10

Prosty kod który powinien działać 😀 przy dowolnej długości klucza:


def decrypt(buffer,key):
    decrypted = []
    notAligned = len(buffer) % len(key)
    secureLen  = len(buffer) - notAligned
    for i in range(0,secureLen,len(key)):
        for j in range(0,len(key)):
            decrypted.append( chr( ord(buffer[i+j])^key[j] ) )
    #dekrypcja pozostalych NIE odszyfrowanych bajtow o ile takie istnieja
    if notAligned:
        for i in range(secureLen,len(buffer)):
            decrypted.append( chr( ord(buffer[i])^ key[-secureLen+i]) )
    return "".join(decrypted)
if __name__ == "__main__":
    key  = [0xf,0x10,0x11]
    print decrypt(file("c:\evil_host1").read(),key)
    print decrypt(file("c:\evil_host2").read(),key)

oto rezultat działania kodu:
(evil_host1 i evil_host2 to oczywiście wartości z rejestru Ad1 i Ad2)
decrypted_hosts_cas
Jak widać zaszyfrowane dane przedstawiają najprawdopodobniej adresy drop hostów, albo hostów z których mają być pobierane dodatkowe moduły, nowe plik konfiguracyjne ,etc.
[=]Epilog[=]
To już wszystko odnośnie tego trojana, jak mieliśmy okazje zobaczyć jego autor „nie ograniczał” swojej fantazji jeżeli chodzi o rożnego typu algorytmy szyfrowania choć bazowały one na prostym xor’owaniu to jednak zobaczyliśmy parę mutacji;]. Wspomnę jeszcze, że trojan ten zawiera jeszcze parę zaszyfrowanych bloków danych jednak ze względu na identyczne metody dekodowania ( zmienia się np. klucz xor’ujacy z 0x13 na 0xc) postanowiłem je pominąć. W następnych postach (o ile czas w najbliższym okresie wakacyjnym pozwoli :D) zajmiemy się trochę bardziej złożonymi algorytmami, sposobami ustalania formatu pliku konfiguracyjnego ,etc.

Posted in Analiza, Malware, RE | Tagged , , , , , , , , | 2 Comments

Filtry

Ostatnio miałem okazje trochę pobawić się w pisanie filtrów używanych w grafice, m.in. filtru okienkowego oraz medianowego co okazało się całkiem niezłym fun’em, szczególnie jeżeli chodzi o rezultat ich działania. Swoją implementacje filtrów wykonałem w C++ Builder’e i na koniec posta postaram się dołączyć co nieco kodu ,ale nie będzie to całość, z tego względu, że imo całość nie jest tak dojrzała(co nie przeszkodziło im uzyskać max pkt. za to zadanie na uczelni :P) aby ujrzeć światło dzienne :P.
Cała filozofia filtru okienkowego polega na wybraniu rozmiaru okna (najpopularniejsza wartością jest 3×3) czyli ilości pixeli branych pod uwagę podczas filtrowania oraz odpowiedniemu dobraniu dla nich współczynników.
Grid
Tablica pixeli. Przykład okna filtrującego o rozmiarze 3×3.
Powyższy rysunek prezentuje zastosowanie okna o rozmiarze 3×3 gdzie pixel zaznaczony na fieletowo jest pixelem wyróżnionym. Iterując po tablicy pixeli musimy sprawić, aby każdy pixel w pewnym momencie iteracji był pixelem wyróżnionym, czyli jest to nic innego jak poruszanie się po niej od pozycje x = 0,y =0 do x = image_width -1 , y = image_height -1.
Przenosząc te informacje na kod :

	for(int x = 0;x < bmp->Width;++x)
	{
	  for(int y = 0;y < bmp->Height;++y)
	  {
	      //loopy odpowiedzialne za operowanie na oknie filtrujacym
	      for(int j = -(windowSize/2); j < windowSize - 1; ++j)
	       {
		for(int i = -(windowSize/2); i < windowSize - 1;++i)
		{
                         //pobranie pixela z uwzględnieniem
                        //wysokości i szerokości bitmap’y
		color = getProperPixel(bmp,x+i,y+j);
		( … )

Warto tutaj zauważyć , że indexy “i” oraz „j” , są tak dobrane tak iż pixel wyróżniony znajduje się w środku okna, czyli od razu mamy wniosek taki, że aby móc wyznaczyć środek okna jego wielkość musi być liczbą nie parzystą >1 (bynajmniej nie spotkałem się z zastosowaniem innych wartości, jeżeli ktoś miał taka przyjemność to piszcie).
No tak ,ale nie powiedzieliśmy sobie jeszcze co tak naprawdę oznacza to „wyróżnienie”. Oznacza ono tyle iż wartość tego pixela zostania zmieniona na podstawie banalnego algorytmu , o którym za chwilę. UWAGA!!! Nie zmieniamy wartości pixeli w obrazie źródłowym , a więc należy sobie przygotować kolejny obiekt reprezentujący nasz image po filtrowaniu, który będzie podlegał modyfikacją. Ok., teraz jak przedstawia się sam algorytm wyliczający nową wartość dla pixela wyróżnionego.
Zapis matematyczny dla okna o wymiarach 3×3:
formulka_1
oraz
formulka_1
oraz w przypadku kiedy suma współczynników równa się 0.
Myślę, że sprostowania wymaga jedynie oznaczenie W(i,j) – jest to oczywiście tablica współczynników okna filtrującego.
Rzućmy teraz okiem jak ten zapis przedstawia się w kodzie(wielkość okna dowolna ze wspomnianego wyżej przedziału):

(   …   )
for(int j = -(windowSize/2); j < windowSize - 1; ++j)
{
  for(int i = -(windowSize/2); i < windowSize - 1;++i)
   {
      //pobierz odpowiedni pixel
      tmpColor = getProperPixel(SrcPixels, x+i , y+j );
      r =  GetRValue(tmpColor)  * window[index];
      g = GetGValue(tmpColor)  * window[index];
      b = GetBValue(tmpColor)  * window[index];
      totalR +=   r;
      totalG +=  g;
      totalB +=  b;
      index++;
      }
}
//zsumowanie wartości wszystkich współczynników
suma = accumulate(window.begin(),window.end(),0);
if(suma == 0)
    suma = 1;
totalR /= suma;
totalG /= suma;
totalB /= suma;
totalR = min(255, max(0, totalR));
totalG = min(255, max(0, totalG));
totalB = min(255, max(0, totalB));
//modyfikacja wartości pixela w obrazie docelowym
DstPixels->Canvas->Pixels[x][y] = (TColor)RGB(totalR,totalG,totalB);
//zeruj index pozycji w oknie współczynników
index = 0;
//zeruj wartości
totalR = 0;
totalG = 0;
totalB = 0;

To czego nie objął wzór matematyczny ,a co raczej jest oczywiste to wykonanie całego algorytmy dla każdego kanału RGB osobno. Oczywiście można zastosować np. konwersje z formatu RGB na YUV i tam jedynie manipulować wartości Y , a następnie już przy samej aktualizacji obrazu docelowego zamienić YUV na RGB, ale w tym zapisie chodziło mi o prostotę.
Ok. czas na przykładowy interface aplikacji:
interface
,aż razi swoją prostotą ;].
Teraz cała zabawa polega na tym, aby dobrać odpowiednie współczynniki dla okna filtrującego.
Przyjrzyjmy się rezultatom działania filtrów z różnych kategorii (jako modela wybrałem myślę wszystkim dobrze znaną postać Dexter’a 😀 ):
Filtr dolnoprzepustowy
dolno
Filtr górnoprzepustowy
gorno
Filtry krawędziowe
krawedziowe1
krawedziowe2
Filtr konturowy
konturowe
Myślę, że efekty całkiem ciekawe;).
Przejdźmy teraz do filtru medianowego. Jego zasada działania jest nieco odmienna choć nadal będziemy korzystać z okna lecz w tym wypadku nie definiujemy żadnych wartości współczynników. Myślę ,że kawałek kodu wyjaśni sprawę:

void CFilters::medianFilter(Graphics::TBitmap *bmp,
Graphics::TBitmap *bmpRez,
int windowSize)
{
	vector pixels;
	TColor color;
	//glowny loop dla siatki pixeli wyznaczajacy tzw pixel wyrozniony
	for(int x = 0;x < bmp->Width;++x)
	{
	  for(int y = 0;y < bmp->Height;++y)
	  {
		//loopy odpowiedzialne za operowanie na oknie filtrujacym
		for(int j = -(windowSize/2); j < windowSize - 1; ++j)
		{
			for(int i = -(windowSize/2); i < windowSize - 1;++i)
			{
				  color = getProperPixel(bmp,x+i,y+j);
				  pixels.push_back(color);
			}
		}
	sort(pixels.begin(),pixels.end());
	bmpRez->Canvas->Pixels[x][y] = (TColor)pixels[pixels.size()/2];
	pixels.clear();
	  }
	}
}

Tak ja wspomniałem powyżej nadal posługujemy się oknem lecz w tym wypadku tylko i wyłącznie w celu zgromadzenia wartości pixeli „pokrytych” przez okno. Wartość pixela wyróżnionego zastanie zastąpiona poprzez wartość środkową zgromadzonych pixeli , stąd widoczne sortowanie w kodzie:
sort(pixels.begin(),pixels.end());
oraz wskazanie elementu środkowego:
(TColor)pixels[pixels.size()/2];
(Np. dla filtru o rozmiarze okna 3×3 elementem środkowym będzie element o indexe 5).
Oczywiście , żeby móc obserwować efekty działania filtra medianowego należy wcześniej dodać „szum„.Oto kod prostego „zaszumiacza” 😀 :

 //glowny loop dla siatki pixeli wyznaczajacy tzw pixel wyrozniony
for(int x = 1;x Width - 5;++x)
{
  for(int y = 1;y Height - 5;++y)
  {
 bmp->Canvas->Pixels[x][y] = bmp->Canvas->Pixels[x+rand()%5][y+rand()%5];
  }
}

i efekt jego działania:
szum
Czas na przyjrzenie się działaniu tego filtra:
wielkość okna 3×3
med1
wielkość okna 9×9
med2
W razie jakiś pytań ,ciekawie „przefiltrowanych fotek” ,sugestii piszcie ;).
Obiecany kod – > Filters.zip.

Posted in Aplikacja, Grafika | Tagged , , , , | 4 Comments

Confidence 2009

LGIM0007
W ostatni weekend to jest 15-16 Maj 2k9 miałem przyjemność uczestniczyć( tak ja w zeszłym roku z resztą :P) w piątej już edycji konferencji traktującej o bezpieczeństwie IT Confidence 2009. Na wstępie powiem co mi się chyba już zdarzyło na tym blogu, że lepszej konferencji od Confidence w Polsce nie było i jak na razie nie widać „rywala” ;).
Postępując chronologicznie:
/* Podróż */
W tym roku bez żadnych dodatkowych kłopotów z PKP( tak tak ,warto o tym wspomnieć ,bo w tamtym roku czekaliśmy z Coldwind’em ok.3.5h na spóźniony pociąg, a jego delay time co 45min był sukcesywnie inkrementowany o kolejne 45 :D) w sielankowej atmosferze podziwiając krajobrazy ,przemierzaliśmy z Gyn’em kolejne setki kilometrów. Gdzieś po drodze do przedziału zainjectował się j00ru i już pełną tegoroczną ekipa zmierzaliśmy do celu.
/* Camp place */
Camp place tudzież miejsce noclegowania to dość nietuzinkowy tegoroczny pomysł organizatorów nazwany Hackers’ Squad.
LGIM0011
Pomysł polegał na umieszczenie uczestników we dwóch hostelach przy czym uczestniczy trafiali do pokojów w sposób losowy :D. Powiem szczerze, że na początku miałem mieszane uczucia co do tego pomysłu, ale ostatecznie muszę postawić wielkiego plusa za hostel/śniadania i ekipę jaką można tam było poznać ;). Dodatkowym atutem
hostelu była jego lokalizacja :D, jakieś 300m od Kina Kijów gdzie odbywała się konferencja
Fotka z pokoju:
hs3
j00ru & me
/* Before party */
Kolejna innowacja :D. Jako, że Kino Kijów ma własny klub to organizatorzy postanowili wykorzystać i tą możliwość do zagospodarowania nam pierwszego wieczoru poprzez projekcje następujących tytułów:
Gry Wojenne (Wargames)
Metropolis
PI
Wróg Publiczny (Enemy of the State)
H4ck3rs Are People Too
LGIM0004
me & Gynvael Coldwind na seansie w klubie Kijów
Napisałem „oglądając”, bo wytrwaliśmy do końca pierwszego filmu :P, ale w sumie bez większych strat, bo widziałem wcześniej już:
H4ck3rs Are People Too jak najbardziej polecam i jakby ktoś nie reflektował tego dokumentu to jest to video o społeczności związanej z security, a film ten został po raz pierwszy zaprezentowany na DefCon’e 2008.
PI – bardzo klimatyczny film, polecam jeżeli lubisz nie przeciętne kino
Gry Wojenne – ten film właśnie udało mi się obejrzeć w całości w klubie i powiem, że czasami był zabawny:D Najlepszy tekst z filmu:
Teacher: “Who first suggested the idea of reproduction without sex?”
David: “Your wife?”

I tak upłynął pierwszy wieczór.
/* Dzień pierwszy */
Kolejną delikatna zmianą, która pojawiła się w tym roku (można ją było odczuć rano)jest godzina rozpoczęcia się wykładów. Przesunięto ją z 9:00 na 10:00 😀 (imo bardziej ludzka godzina).
Oczywiście jak to zwykło bywać na konferencjach po rejestracji zostaliśmy obdarzeni przez piękne hostessy torbą z gadgetami:
LGIM0008
Konferencje rozpoczęła się prezentacja:
Bruce Schneier’a – „Reconceptualizing Security”
Mówił on o tym jak odczuwamy bezpieczeństwo ,kiedy czujemy się bezpieczni, a tak w ogóle nie jest oraz kiedy jesteśmy bezpieczni, a tego bezpieczeństwa nie odczuwamy. No…., moim zdaniem prezentacja nietuzinkowa ze szczyptą filozofii tak jak lubię, widać tu po prostu wieloletnie doświadczenie w branży oraz ogrom przemyśleń na temat security. Mistrzostwo po prostu;).
Joanna Rutkowska – „Thoughts about Trusted Computing”
Bardzo dobra prezentacja (czego można się było z resztą spodziewać;)) ,m.in. omawiająca składniki
Trusted Computing: takie jak : TPM,TXT,VT. W szczególności muszę wspomnieć, że forma samej prezentacji przypadła mi do gustu ponieważ slajdy były przejrzyste(bez zbędnego przerostu formy nad treścią oraz wodotrysków), czarne tło kilka bloków/schematów objaśniających bieżące zagadnienie i to wszystko. Co do ciekawostek to Joanna zapowiedziała opublikowanie najnowszych badań w najbliższe wakacje m.in. na temat Trusted Computing :D. Czyżby wspomniane komponenty nie były tak bezpieczne jak zakładają ich twórcy ?Przekonamy się w wkrótce.
Eddie Schwarz – „Understanding Social Networking Threats Using Live Threat Intelligence”
Prezentacja dość na czasie zważając na to, że niektórzy wydają się żyć portalami społecznościowymi.
no i nadszedł czas na …
/* Lunch Break */
Jeżeli chodzi o same snacki, które są cały czas dostępne podczas konferencji to jest git, ale niestety ja jako wielki smakosz musze niestety przyznać minusa za obiad, bo to były dania w stylu:
„prawie zupa” oraz „prawie szaszłyk”. Także zdecydowanie to nie było to co misie lubią najbardziej. W swojej opinii nie byłem osamotniony ,bo moje zdanie podzieliło jeszcze parę osób, także coś w tym musi być :).
Po wydłużonym lunch’u ,zdecydowałem się( tak tak ,sesje NIESTETY zostały podzielone po 3’im wykładzie) na prezentacje:
Alexander Kornbrust – “Oracle SQL Injection in Webapps”
Dla mnie interesująca prezentacja z tego względu, że o ile przeprowadznie pentestów na bazach MSSQL czy MySQL to jest chleb powszedni to jednak bazy Oracle chodź tak powszechne i lubiane w świecie biznesu to widywane są przeze mnie rzadko, a wręcz wcale. Także miło było zobaczyć co do „zaoferowania” mają funkcjonalności w różnych wersjach baz Oracle podczas ataków np. SQL (Blind) Injection :D.
Walter Belgers – „Lockpicking 101”
To był jeden z wyczekiwanych przeze mnie tematów ponieważ panowie zajmujący się Lockpicking’em mieli pojawić się na zeszłorocznej konferencji, a niestety się to nie udało. To co można było zobaczyć na prezentacji to masa różnego rodzaju zamków oraz metod, którymi można je otworzyć w sposób mniej lub bardziej inwazyjny. Widać było także wieloletnie doświadczenie prelegenta w tej branży.
Zabawna historia związana z tym tematem, którą przytoczę wydarzyła się wieczorem podasz powrotu do hostelu kiedy to równocześnie doszliśmy do drzwi(ja,Gyn,j00ru) i cześć ekipy loockpickerów już w środku kamienicy. Chwila konsternacji ,każdy uderza się po kieszeni gdzie te klucze po czym ,któryś lockhackerów chciał się pochwalić skillem i zamierzając otworzyć zamek niczym szpieg z krainy deszczowców świecąc miniaturowa latarką zaczął wyciągać picka ,ja nacisnąłem po prostu dzwonek do drzwi i ktoś otworzył je od wewnątrz 😀 ..hahah..byłem szybszy. Kolejny raz potwierdza się reguła, że najprostsze metody są najlepsze ;).
Michał Sajdak – „Zdalny root na ruterze klasy SOHO”
Prezentacja ok., bez jakiś większych rewelacji, ale ukazująca potencjał wykorzystania błędów w tanich powszechnie używanych router’ach .
Martin Mocko – “Race to baremetal: UEFI and hypervisors”
Interesująca prezentacja oraz ciekawa dyskusja, która wywiązała się tuż po niej, pomiędzy Joanna( w tym temacie to było do przewidzenia :P) oraz prelegentem.
. Tam trzeba było po prostu być.
… i tak minął pierwszy dzień prelekcji. Wieczorem w klubie kijów było o czym rozmyśla jak i dyskutować, także pozytywnie ;).
/* Dzień drugi */
Rich Smith – „VAASeline: VNC Attack Automation Suite”
Rich jest członkiem firmy Immunity, myślę, że jest to firma, którą większość z was kojarzy m.in. przez takie projekty jak CANVAS czy Immunity Debugger. Rich stworzył bardzo użyteczną biblioteka dla pythona ułatwiającą proces automatyzacji ataków na VNC, której moim zdaniem warto się przyjrzeć;).
Jacob Appelbaum – „Tor Network”
Było technicznie ,było filozoficznie czyli bardzo dobra mieszanka.
Na tej prezentacji można było się dowiedzieć o tym jak działa sieć tor jak można stać się jej aktywnym węzłem , itd. , ale nie tylko. Jacob wspomniał także jaki jest sens tworzenia takiej sieci. Na szczęście w Polsce nie mamy takich problemów jak np. w Chinach, że rządowi nie podoba się youtube no to trach!!! i nikt już nie zobaczy kolejnego odcinka Tiger Team’u, a dzięki Tor’wi można to ominąć. Prelegent wspominał także o takich krajach, w których anonimowość, jaką daje Tor np. dziennikarzom, którzy piszą otwarcie na swoich blogach o tym co nie podoba się im w ich kraju ,jest na wagę ich życia.
Zabawną historią była opowieść o dwóch obozach FBI, które wzajemnie się kłócą czy Tor przynosi im więcej korzyści czy kłopotów :D.
Alessio Pennasilico – „Bakeca.it DDoS: How evil forces have been defeated.”
Hehhe jeden z moich ulubionych prelegentów confidence. Niesamowity sposób opowiadania oraz zabawny akcent (wyrażenie brzmiące “eso hon” rozkminiałem sporo czasu w tamtym roku, aż udało mi się odganąć, że chodzi tu o „and so on” :D). Jeżeli chodzi o sprawy techniczne związane z prezentacja to tak jak w temacie Alessio opowiadał o ataku DDoS na firmę Bakeca.it ( coś ala allegro),
która pozwoliła mu jak widać zresztą ( i brawa dla niej) na opisania i opowiedzenie całego zdarzenia.
Genialnie opowiedziane kolejne kroki postępowania ataku oraz środków przeciw działania.
Michael Kemp – „Rootkits are awesome: Insider Threat for Fun and Profit”
To wystąpienie było mega zabawne, a zarazem tragiczne :D. Inaczej skomentować tego nie mogę, bo jeżeli, ktoś pokazuje listing Dll’ek wykorzystywanych przez dwie aplikacje, porównuje je, dochodzi do wniosku że są one identyczne i na tej podstawie stwierdza, że obie aplikacje działają identycznie to sorry 😀 Po prostu po parunastu minutach słuchania zacząłem się obawiać o tego człowieka jak daleko posunie się on w swoich fantazjach i jak wiele osób naskoczy na niego po prezentacji :D.
Tłumaczyć go może jedynie fakt, że tak jak wspomniał na samym wstępie był na dużym kacu i nie bardzo pamięta jak wrócił do hotelu:D…mam też nadzieje, że cała tą prezentacje tworzył w podobnym stanie wtedy jestem w stanie o tym zapomnieć. Oczywiście zgodnie z moimi oczekiwaniami po prezentacji znalazło się „parę” osób entuzjastycznie (tak to nazwijmy :D) wytykających prelegentowi pewne nieścisłości w jego rozumowaniu. No niestety, Michael chciał zareklamować swoją nową firmę,
ale imo nie robi się tego w takim stylu ;).
Raoul Chiesa – „Corporate Security and Intelligence: the dark links”
Niestety obiecałem, że nic nie powiem :D. Prezentacja naprawdę bardzo ciekawa, a fakty przerażające.
I tym sposobem dotarliśmy do końca konferencji……
Podsumowując, wielki plus dla orgów za przygotowania i organizacje pozostaje mi tylko mieć nadzieję, że za rok znów się tam pojawię ;).

Posted in Konferencje, Security | Tagged , , , , | 2 Comments