Some Less Known Tricks to easily HACK WINDOWS (Yes Viruses Does Try these too !!!! )

Cool Tricks:

Today I am going to tell you 2 almost less known and cool tricks, what can be used to break into someone’s system J   ( Happy …. Haaaaaaaaa )

All these attacks are very simple, effective and their robustness lies that they exists in the main architecture of windows.

Trick 1:

The first one is API vulnerability. This is one of the most common security mistakes Developers always made (me too L ) while coding.

The syntax of CreateProcess API is:

 BOOL WINAPI CreateProcess(

  __in_opt     LPCTSTR lpApplicationName,

  __inout_opt  LPTSTR lpCommandLine,

  __in_opt     LPSECURITY_ATTRIBUTES lpProcessAttributes,

  __in_opt     LPSECURITY_ATTRIBUTES lpThreadAttributes,

  __in         BOOL bInheritHandles,

  __in         DWORD dwCreationFlags,

  __in_opt     LPVOID lpEnvironment,

  __in_opt     LPCTSTR lpCurrentDirectory,

  __in         LPSTARTUPINFO lpStartupInfo,

  __out        LPPROCESS_INFORMATION lpProcessInformation

);

I am not going in deep and we are only interested in the first 2 parameters:

lpApplicationName and lpCommandLine.

The description of the API states as follow:

The lpApplicationName parameter can be NULL. In that case, the module name must be the first white space–delimited token in the lpCommandLine string.

So there are 2 ways to cal this API, firstly:

CreateProcess(_T("C://Windows//notepad.exe"),NULL  …… )

And the second is:

CreateProcess(NULL,_T("C://Windows//notepad.exe"), …… )

The attack lies in these parameters only.

If we are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin; otherwise, the file name remain ambiguous for this API. For example, consider the string "c:\program files\sub dir\program name". This string can be interpreted in a number of ways. The system tries to interpret the possibilities in the following order:

c:\program.exe files\sub dir\program name

c:\program files\sub.exe dir\program name

c:\program files\sub dir\program.exe name

c:\program files\sub dir\program name.exe

and thus the main point to notice here is that while resolving path in that way if we put any of the malicious/hack program with above bold mentioned names ( ex: program.exe , sub.exe etc), that program will get launched in-spite of the targeted program.

Let’s have a practical look now.

Copy “calc.exe” (calculator) or any other executable to C:\ and rename it to “Program.exe”

Now run the command prompt and type “Program files\\executbale.exe”

Like I have chosen:

C:\Program Files\Adobe\Acrobat 6.0\Reader\ AcroRd32.exe

Now type the whole path with “Quotes” and you can see Adobe reader gets launched as usual:

But then make a minor mistake (as most of the developers make while coding), only remove the quotes from this path and  J  :

BINGO!!!!  In spite of Adobe reader, Calculator gets launched.

So the only thing you have to find out, is yours victim program calling any process and if yes try this attack on his/her executableJ . If successful, you have a way to launch your program with the credential of victims’ program and suppose if his program has got ADMIN privileges thenJ.

Trick 2:

This Hack also lies in the Windows Blind trusting of its registry entries.

Most of you might know about debuggers.  A debugger or debugging tool is a computer program that is used to test and debug other programs , Microsoft provides a default debugger with Windows OS (Dr.WATSON) that gathers information about  a program/computer system when an error (or user-mode fault) occurs with a program which helps them to figure out the main cause of the bug/crash.

A user can have more than one debugger in his/her system,  In which scenario he/she has to decide that which one should be the default debugger of his/her system. I mean which debugger should invoke when any (remember ANY...) program on his/her system crashes.

The registry entry for this lies at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

You will find there a key with name:  “Debugger”

And the value would be something like: "C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld

Now the hidden truth here is that Windows never checks that any executable mentioned there is actually a debugger or not, it simply launches it (I think by this time smile starts coming to your faceJ ), so just imagine an attack scenario where you change the victim’s registry entry with your tool path, you simply WAIT for some application to crash on your victims’ system (there are many, you need not worry, after every 10-15 minutes something will keep crashing)

As soon as your victims’ system crashes, Windows will launch your tool thinking it is a debugger and you are IN J (Yes need not even learn anything, let someone else’s’ mistake makes your way to your target system).

Enough theory (I hate this portion you know…), now just have some practical look (I love thisJ)

I wrote a very simple code which crashes every time we run it:

           #include "stdafx.h"

           #include "stdio.h"

           #include "conio.h"

           char *p;

           void error()

       {

                 p = NULL;

                delete p;

       }

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

 {

               

    p = new char(10);

    error();

    printf("%s",*p);  //Error Trying to access invalid memory

                    // address

    getche();

    return 0;

  }

Now run this code with the debugger registry's entry as:

"C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld

And yes as soon as the code crashes the VS debugger gets launched.

Now Change this registry entry with any dummy program name (in real world attack, this could be any MALICIOUS program)

Suppose I changed the entry with system calculator program path

“C:\WINDOWS\system32\calc.exe”

And run the same program again,

Now see the magic… BINGO!!!, The Calculator program gets launched, that too without coming in the knowledge of user as well as auto system provoked J

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.