Results 1 to 4 of 4

Thread: From where FastPebLockRoutine is called?

  1. #1

    From where FastPebLockRoutine is called?


    I was reversing Waledac malware for a bit and it is using some interesting way change its control flow. It basically modifies [PEB+0x20] which is FastPebLockRoutine and initially it points to ntdll!RtlEnterCriticalSection. After replacing FastPebLockRoutine Waledac makes only one call to SwichToThread and returns from the main function, which leads to ExitThread. So here is the question: from where is PEB.FastPebLockRoutine called? Can it be called from kernel because I could not find any code that makes the call. Thank you.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Blog Entries

    This is a known exploit up to XP (overwriting PEB FastPebLockRoutine / FastPebUnlockRoutine) i.e.

    Windows Heap Overflows using the Process Environment Block (PEB)

    Generic Anti-Exploitation Technology for Windows

    Overwriting Critical Pointers

    Some newer exploits are specifically targeting interesting pointers within the PEB itself for example the
    recent public release of an exploit for an ASN.1 bitstring vulnerability uses a hardcoded address of
    0x7ffdf020 for the pointer to FastPEBLockRoutine(). The FastPEBLockRoutine is called when code wants
    to lock the PEB so that it can be modified and it happens to be called during exception handling.
    other words this exploitation trick is another variation of abusing code that is run after memory corruption
    has occurred.

    Interestingly, Microsoft have removed some of the interesting pointers from the PEB under Windows
    2003, so many exploits that use these methods are not effective for Windows 2003 systems. Specifically,
    the pointers FastPEBLockRoutine() and FastPEBUnlockRoutine()at PEB offset 0x020 and 0x024 have
    been removed.

    Running Shellcode in the PEB

    One last reason the PEB is interesting to attackers is because the memory pages where the PEB resides
    are both Writeable and eXecutable. Since the PEB has always been in a fixed location, attackers have
    the option of copying their shellcode to a known address in the PEB and then transferring execution to
    that location. This technique can be useful when an arbitrary memory overwrite is possible but the
    payload is difficult to locate such as for heap overflows. For this reason, copying shellcode into the PEB
    and then using an overwritten pointer which is called during exit is the currently preferred method for
    universal and reliable heap exploitation
    on Windows 2000 and Windows XPSP1. PEB randomization
    can complicate this technique slightly, but since the address change is only very slight, an attacker can
    still "guess" a safe location to copy the payload with high reliability.

    From the above, there are a few clues as to what actually triggers the exploit - whenever the PEB is locked so it can be modified, possibly during exception handling.

    There is also the mention of the overwritten pointer being "called during exit" and references the article

    Reliable Windows Heap Exploits

    though I can't quite see what they mean by the phrase "called during exit".

    I can't find any specific code in ntoskrnl which accesses FastPEBLockRoutine. SwitchToThread leads to NtYieldExecution and SwapContext, it may occur there on the context switch. Or it might occur during the call to _PspExitThread.

    What is the actual address written to FastPebLockRoutine? Is it contained within a separate thread? Or is it within the same thread, indicating it will execute as the current thread is exiting?

  3. #3
    The PEB is also locked, I believe, when a dll is loaded. So, for IE exploits you could simply force the load of an ActiveX object, which you are probably doing anyway, and then you've got a race condition. To make the condition more reliable, force the load of a module that has a longer DllMain function. The PEB is locked until after DllMain returns (which is the reason for the MSDN warnings about waiting and other things in DllMain, because it can cause a deadlock if an exception triggers in another thread, among other things).

  4. #4
    Thank you guys for the replies.

    Kayaker: The control transfer occurs when thread calls ExitProcess. Actually the FastPebLockRoutine is called from ntdll!RtlAcquirePebLock. If you look at RtlAcquirePebLock you will clearly see TIB and PEB are accessed. The interesting part was that I tried to place memory BP on access and hardware BP on access, however none of these were triggered.

    I have another question. Is there a way to intercept context switch from user mode? I read something about KiUserApcDispatcher is this a good place to put a hook?

    Thank you.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

Similar Threads

  1. A virtual function is called directly. What's that about?
    By tlgspk in forum The Newbie Forum
    Replies: 0
    Last Post: May 10th, 2012, 06:51
  2. Problem getting where my code was called from
    By henrik in forum The Newbie Forum
    Replies: 5
    Last Post: April 5th, 2009, 09:28
  3. Question: Trying to learn from a program called 'X'
    By zambuka42 in forum Advanced Reversing and Programming
    Replies: 3
    Last Post: July 31st, 2006, 21:14
  4. How to set breakpoints in called EXE file
    By alan in forum OllyDbg Support Forums
    Replies: 7
    Last Post: May 8th, 2005, 16:36
  5. application packed with something called ficken
    By npcracker in forum Malware Analysis and Unpacking Forum
    Replies: 3
    Last Post: April 11th, 2002, 13:07


Posting Permissions

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