Windows'/Applications' Attack: Via WINAPI Parameters' Tampering

Today I will be writing on a very interesting topic to tell you that actually how some of the attacks on the windows work.

I already wrote over WINDOWS ARCHITECTURE where I wrote very briefly about the WINDOWS APIs.

Well first have looks what the hell these windows APIs are actually?

The Windows API, informally WinAPI, is Microsoft's core set of application programming interfaces (APIs) available in the Microsoft Windows operating systems. It was formerly called the Win32 API and used by applications to invoke windows services.

In a nutshell I can say that via these APIs, Windows provide a way to communicate to OS and let it carry/perform the task for the application.

On a broad spectrum, these Windows API functionalities can be grouped into eight categories:

Base Services

Advanced Services

Graphics Device Interface

User Interface

Common Dialog Box Library

Common Control Library

Windows Shell

Network Services

Pretty much the names are self descriptive. Okie, but then where these APIs reside in my system and how I can use them …. Hmmmmmmmm… Let’s have a look J

Got to %systemroot%\system32 and you will find many DLL’s (Dynamic Link Libraries … Thinking of writing something on these also but not now J  )

You will find bunches of Dlls there, some to name are Kernel32.dll, Win32spl.dll etc. Hover the mouse over any of them and you will find a brief description of them as of:

But then how I will know that what functionalities these Dlls are providing to me.

There are many tools for this; I will be using Dll Export View for this. Use this tool, and simply drag and drop the Dll for which you want to see exported functions. (I have done for Kernel32.dll)

So you can see all the functions being exported by this Dll. You will find 2 versions of each function, ASCII Version (CreteFileA() ) & UNICODE Version  (CreateFileW()). This is for providing backward compatibility support.

Now the main thing is that how we use these Functions in our code. The answer is there exists 2 ways,

Via Implicit Linking and Via Explicit Linking.  All the Windows Dlls are loaded using explicit linking where we do the follow:

1.             Load the Dll    
2.                  Get the Function pointer      
3.              Call the function with Function pointer and passed the arguments 
4.              Once done with work, unload the Dll.

But the good thing is that all these things are done and carried by windows internally, here we need to simply call the API function:

Like if I want to create a process, I might be using “CreateProcess ()” API in Kernel32.dll

And my code will look like:

  #include "windows.h" 

  
// bla bla bla J ….. (Other Code)

    
 STARTUPINFO siStartupInfo;

    PROCESS_INFORMATION piProcessInfo;

    memset(&siStartupInfo, 0, sizeof(siStartupInfo));

    memset(&piProcessInfo, 0, sizeof(piProcessInfo));

    siStartupInfo.cb = sizeof(siStartupInfo);

CreateProcess(_T("C://Windows//notepad.exe"),NULL,0,0,FALSE,
CREATE_DEFAULT_ERROR_MODE,0,0,&siStartupInfo, &piProcessInfo);

I have not done anything, As i mentioned above, the "windows.h"  header file will take care of all the previously mentioned steps to call the respective WINAPI.
 

Now the question arises, why I should use MS API , the reply is NO, You are not bounded in most of the cases, but these APIs are well tested and written by MS Professionals and well suited as per Windows architecture. You may write your own code but then there will be 2 fear factors:

1)      Whether it will run on all the windows or not?

2)      The code might be buggy and non –optimal.

So no one is stopping you to write your own code but to just boost up the development and to ensure that it will be as good on all windows as it is in front of you, most of the time we use Windows APIs (Yes in Professional development too, I myself used a lot J ) and also we don’t bother about testing  these codes , Microsoft is doing it on behalf of us .  In some cases, we are restricted to use WINAPI as there is no other way to control Windows functionality. One example of this is Windows Graphics portion. There we heavily depends on WINDOWS API for its fast responses and of course there is no other way around L.

There are many other things which can be discussed here on this but we better leave this thing here itself.

Okie, coming back to our discussion, so if you remember my doc over Windows architecture, you will be remembering that the WINAPI we call are in USER MODE SESSION CALLS and at some point to get it executed it has to transfer to KERNEL MODE where OS will handle it, do the work and return the same to USER MODE again. Now today what attack I am going to discuss, this is based on this fact only.

The WINDOWS has some great flaws in its architecture and that are:

1.          Windows heavily relies on WIN API and for windows, anything passed as argument of WINAPI ,  window treat it as a valid argument    
2.              Windows does very minor kinda of checking over the passed arguments of WINAPI and directly runs the request.

So this makes the plot of attack. What if we hook some of the API calls of some Executables and tamper those parameters (Change it to our desired ones) and let it pass to Windows Kernel. The answer is simple: Windows Kernel will execute it, thinking that it is performing a task on behalf of the executable you have tampered. And the BINGO!!! here is that if you are able to tamper the parameters of some executables running with higher privilege mode then J ….. (I bet smile, came on your face ;D)

But this task is not as simple as it looks, it needs a different skills what we usually call Reverse Engineering.  So ready to learn it (or get your hand dirty J ) .. Well so start:

The code which we are going to take as Case Study is:

#include "stdafx.h"

#include "windows.h"

#include "stdio.h"

#include "tchar.h"

int _tmain(int argc, _TCHAR* argv[])

{

     

      printf("Launch NOTEPAD");

      getchar();

    STARTUPINFO siStartupInfo;

    PROCESS_INFORMATION piProcessInfo;

    memset(&siStartupInfo, 0, sizeof(siStartupInfo));

    memset(&piProcessInfo, 0, sizeof(piProcessInfo));

    siStartupInfo.cb = sizeof(siStartupInfo);

      CreateProcess(_T("C://Windows//notepad.exe"),NULL,0,0,FALSE,CREATE_DEFAULT_ERROR_MODE,0,0,&siStartupInfo, &piProcessInfo);

 

  getchar();

  return 0;

     

}

To learn this attack you should have following skills:

1.              Knowledge of debugger (Windbg) (Shortly I will write on this , but not now)
2.               Good Assembly Knowledge  ( Hope your teacher taught you J )
3.                WIN API  knowledge  (Can get Via Windows Platform SDKs)

The attack starts as follow:

1.                 Target the executable you want to tamper or hack  
2.                  First you need to know that the executable you targeted uses which Dlls and from which files, for  this simply get the Import function list of this executable ,there are many  free tools available for this:

So a quick glance will reveal this info:

You can see that this executable is importing “CreateProcessW” function from KERNEL32.dll

(WINAPI to create a process)

Now I have to target this API Call. So this starts as follow:

3)      I will launch this executable from WinDbg ( I can also attach WinDbg to already running process)

                              Fig: Attached process in WINDBG (ParameterName.exe)

4)      I will put a break point on the API call CreateProcessW()

<Don’t forget to set the symbol path for WinDbg, as this is not topic of discussion, I am leaving this for now>

5)      I will run the process and wait for the Breakpoint to get hit.

6)      After this, I will take out the call stack (remember I told you should have a good knowledge of assembly J ) of this application at the moment of breakpoint hit.

 

7)      I will convert the first passed parameter to the function (Kernel32!CreateProcessW) to readable String value:

BINGO …………………… J , have  you seen this …. ;D

The parameter value is “C://WINDOWS//notepad.exe”

8)      Now I  am free to change this value here J , the Windows will run this request thinking that as though the application has requested to run the program ( which in fact, I tampered and changed) and the application will get launched will same privilege as  parent process (almost in 90% chances).

But again there should be some twist, isn't it  ;D , so I am giving you a hint that how you can tamper this parameter , hmmmmmmmm.. okie use “eu” command of WinDbg to tamper this parameter , let this program run and see the magic.

If still stuck, feel free to ask J  …. But I suggest you to try it by your own , it will make you feel good.