Rechercher
Fermer ce champ de recherche.

Vous êtes victime d’un incident de sécurité ? Contactez notre CERT

25/03/2024

Blog technique

A way to find LPE in Windows App

Team CESTI

Through this article, we propose a way to find LPE in Windows applications, by using SysInternals tools. What and how to look at? How to exploit in an easy and quick way?

How it works

When a Windows app is executed, it loads several libraries (DLLs) needed to its functioning (i.e., C:\Windows\System32\cryptbase.dll, etc.). To load DLLs dynamically, the LoadLibraryA() function is usually used (or LoadLibraryExA()).

				
					HMODULE LoadLibraryA(
    [in] LPCSTR lpLibFileName
);
				
			

When this function is called, a specific search order is respected, as shown below:

The search order is the following:

  • Application: installation app repository
  • System: C:\Windows\system32\ repository
  • Windows: other Windows repositories
  • Current PATH: current repository
  • %PATH%: local user repository

Sometimes, developers are not using the usual places and put their own libraries in specific folders, accessible by non-privileged users. In specific cases, these folders can be abused and can be used by a local attacker to elevate his privileges. Let’s look how to proceed.

SysInternals: Procmon

In 1996, Mark RUSSINOVICH created the Sysinternals website to host his system utilities. Today, these tools are referenced on the Microsoft site.

One of the proposed tools is ProcessMonitor. This tool is able to monitor the activity of the file system, registers and processes/threads in real time. Here is an example.

It is possible to observe all operations performed by processes and their associated results and details:

  • Access to the register (RegOpenKey, RegQueryKey, etc.)
  • Windows API calls (CreateFile, ReadFile, WriteFile, etc.)
  • Path accessed
  • and a lot of more!

By this way, it is so possible to observe paths that an app tried to access. What about « NAME NOT FOUND » paths?

Name not found?

On Windows, when an app tries to access to a file, it first checks if it exists by systematically performing a CREATE FILE API call both on its path and on its name. Such a call can either return a SUCCESS if the file or path exists or PATH NOT FOUND/NAME NOT FOUND otherwise. In our case, by analyzing the execution flow of an app, we only focus on these error results in ProcMon, by filtering. Here is the obtained result.

Several paths/files do not exist. These inaccessible files are often forgotten during a product development or because of bad practices. A bad access attempt generally targets:

  • A directory of the current user (%APPDATA% -> C:\Users\Jean-Michel\AppData\Roaming)
  • A non-existing directory in C:\ (like C:\dev\, having read/write access by default for a domain user)
  • A directory of another file system (C:\proc\stat or C:\bin\bash)
  • A hard-coded library (like C:\Users\Jean-Michel\Desktop\dev\debug.dll)

In this example, it is possible to see that the app tries to access to the C:\proc\stat\ folder.

Below, another example that exploits the dll PATH NOT FOUND. An unprivileged user puts its own dll in his environment. Then, a privileged process searches the dll in the user (wrong) environment (instead of a safe environment). The process finds the dll, and then loads it.

How to proceed?

In this example, we consider a non-privileged attacker, having a local access to a Windows workstation. His goal is to elevate his privileges. He observes that a privileged app process tries loads its own DLL from a not found path. This attacker will easily develop his own DLL by following the associated Microsoft documentation (which necessitates a special formalism in order to be executed).

The Microsoft documentation shows the entry points for a DLL. The attacker is able to execute his code, as soon as his DLL is loaded by an app and by executing DLL_PROCESS_ATTACH.

				
					BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    switch(fdwReason) 
    { 
        case DLL_PROCESS_ATTACH:
            Exploit();
            break;

        case DLL_THREAD_ATTACH:
            break;

        case DLL_THREAD_DETACH:
            break;

        case DLL_PROCESS_DETACH:
            break;
    }
    return TRUE;
}
				
			

Then, he can copy it in the current directory and wait its loading by the vulnerable app. When loaded, the code is executed with the app rights, i.e., NT AUTHORITY\SYSTEM.

But the app also crashes!

Why does it crash?

Once the DLL is executed, it can crash the app. It’s a usual behavior. After executing the payload, the app seeks to use functions from the DLL (that it believes it has successfully contacted). As the called function does not exist, it crashes.

To overcome this problem and ensure that the product continues to work, the attacker has to perform DLL proxying. It will be the subject of another blog article, to see how to proceed!

Voir les derniers articles de notre Blog technique

28 novembre 2024
L'exfiltration de modèles LLM (Model Theft in english) par des acteurs malveillants ou des groupes de cyberespionnage avancés est une […]
26 novembre 2024
La surconfiance (Overreliance en anglais) peut survenir lorsqu'un LLM produit des informations erronées et les présente de manière autoritaire [...]
25 novembre 2024
Avec une souche éprouvée, des outils bien choisis et des cibles stratégiques, 8Base se distingue comme une menace particulièrement redoutable. […]
13 novembre 2024
Un système basé sur les LLM (Large Language Models) est souvent doté d'un certain degré d'autonomie par son développeur, [...]
12 novembre 2024
Les plugins pour LLM sont des extensions qui, lorsqu'ils sont activés, sont automatiquement appelés par le modèle pendant les interactions […]
7 novembre 2024
Les LLM ont le potentiel de révéler des informations sensibles (Sensitive Information Disclosure en anglais), des algorithmes propriétaires ou d'autres […]
6 novembre 2024
Le machine learning étend les vulnérabilités aux modèles pré-entraînés et aux données d'entraînement fournis par des tiers, qui sont susceptibles […]
31 octobre 2024
Un déni de service du modèle (Model Denial of Service en anglais) se produit quand un attaquant interagit avec un […]
28 octobre 2024
L'empoisonnement des données d'entraînement (Training Data Poisoning en anglais) fait référence à la manipulation des données de pré-entraînement ou des […]
27 octobre 2024
Find here the crypto and reverse challenges that our teams created for the European Cyber Week pre-qualification and qualification tests […]