Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    86389289

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
Task Scheduler .job import arbitrary DACL write

Tested on: Windows 10 32-bit

Bug information:

There are two folders for tasks.

c:\windows\tasks

c:\windows\system32\tasks

The first one is only there for legacy purposes. The second one gets used by the task scheduler.

In the old days (i.e windows xp) tasks would be placed in c:\windows\tasks in the ".job" fileformat. 

If on windows 10 you want to import a .job file into the task scheduler you have to copy your old .job files into c:\windows\tasks and run the following command using "schtasks.exe and schedsvc.dll" copied from the old system: "schtasks /change /TN "taskname" /RU username /RP password" 

(found this here: https://social.technet.microsoft.com/Forums/windowsserver/en-US/467e5cab-2368-42de-ae78-d86b644a0e71/transfer-scheduled-tasks-to-server-2008?forum=winserverMigration)

This will result in a call to the following RPC "_SchRpcRegisterTask", which is exposed by the task scheduler service. (I assume that to trigger this bug you can just call into this function directly without using that schtasks.exe copied from windows xp.. but I am not great at reversing :(   )

It starts out by impersonating the current user.

But when it hits the following function: 

int __stdcall tsched::SetJobFileSecurityByName(LPCWSTR StringSecurityDescriptor, const unsigned __int16 *, int, const unsigned __int16 *)

It starts impersonating itself (NT AUTHORITY\SYSTEM)! 

And then calls SetSecurityInfo on a task it created in c:\windows\system32\tasks.




This can be easily abused.

The PoC code:

CopyFile(L"bear.job", L"c:\\windows\\tasks\\bear.job",FALSE);
	system(command.c_str());
	DeleteFile(L"c:\\windows\\system32\\tasks\\Bear");
	CreateNativeHardlink(L"c:\\windows\\system32\\tasks\\bear", L"C:\\Windows\\system32\\drivers\\pci.sys");
	system(command.c_str());

First we copy bear .job into the legacy tasks folder.

Then we call "schtasks /change /TN "bear" /RU username /RP password" 

We have to call it "normally" first without planting a hardlink because otherwise it will fail, since the task already exists in c:\windows\system32\task.

After that we delete the file it created. And plant a hardlink and re-run the same command.

This time it will call SetSecurityInfo on our hardlink.

How to run the PoC (you need to rebuild for x64, included binary is x86)

1. copy polarbear.exe, bear.job, schtasks.exe, schtasks.dll from the folder "poc files" to your test VM

2. run polarbear.exe passing a username and password of a local non admin account. I.e "polarbear.exe essbee polarbear"

You can use the included video demo as reference.

Solution?

Make sure it impersonates the user! :D

Limitations

Obviously to run to PoC we have to pass a username and password. However, this can be the account information of a local non admin account, meaning it still crosses a security boundary. But for malware it would be harder to use this, since it's not that easy to obtain a cleartext password and even if we call _SchRpcRegisterTask directly, it still has a struct _TASK_USER_CRED argument, and I assume this expects clear text account info and not a token or something. Maybe you can use the Guest account or something when calling _schrpcregistertask directly.

EDB Note ~ Download: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46918.zip