busterb (321)

For crying out loud people, it’s silly that this has it’s own CVE. It’s a documented feature that the Pi has a default password. So do lots of other things.

Likely pre-auth RCE via stack overflow in PAM username parsing. Simply provide an overlong username, and PAM does an over copy into a stack buffer.

Bug being discussed in open source offshoots for Solaris here: https://illumos.topicbox.com/groups/developer/T4da539ebf8f90156/urgent-cve-2020-14871

But they’re not sure if it’s actually related to this commit https://github.com/illumos/illumos-gate/commit/1d276e0b382cf066dae93640746d8b4c54d15452, or if it’s a different bug. My money is on the former. https://www.illumos.org/issues/13242

ZDNet article referencing exploitation in the wild: https://www.zdnet.com/article/hacker-group-uses-solaris-zero-day-to-breach-corporate-networks/

If you actually have a working Secure Boot installation in the first place and rely on it, yes this is a problem.

However, whether that is true is specific to your environment. Many cloud environments (like AWS), do not support secure boot/UEFI in the first place, so there’s no point to worrying about this; an attacker could just replace your grub binary already, or kernel, or anything else. You’re better off monitoring VM reboots for this kind of attack, and reprovisioning if that happens. Since this is basically a persistence mechanism, it seems like there are lot of other lower-hanging mechanisms that could also work. By the time you’ve bothered getting root or physical access, you could do so much else in the mean time. I can’t imagine this being in the top 50 things an attacker would try to do, outside of a supply chain attack of some sort.

This vulnerability was patched February 2020, but there is renewed interest in it thanks to research by wetw0rk and their submission of a recent Metasploit Module. The underlying vulnerability here is a lack of authenticated controls on the Nimbus protocol itself, which allows an attacker to simply run arbitrary commands on the target. This combined with CVE-2020-8012 allows arbitrary code execution as well.

You are unlikely to see this on the internet (the only boxes I found on Shodan listening on TCP port 48000 were NAS devices using it as the NFS lock service, so it’s hard to gauge the wide-spread nature) but this is more commonly used as mass-deployments in cloud environments or server environments. Since it is the robot/controller that is vulnerable, potentially every target in a managed environment is vulnerable to this if it has the vulnerable version of the Nimsoft software installed. If an enterprise is using this software, it’s likely an attacker will be able to easily use it to control the whole environment if it is left vulnerable, and could likely become an easy crypto locking target.

Matt Shockley wrote a nice blog post, noted by @timwr and @ccondon-r7, on how to trivially bypass the TCC framework in MacOS by modifying the $HOME environment variable to point to an arbitrary TCC entitlement database that the attacker controls. What this means is that a post-exploitation implant will have an easy time bypassing TCC to access all files available to a user without any prompting.

However, since this is a relatively new feature in Catalina, users of earlier macOS versions were already ‘vulnerable’ simply because this feature was not available. It may be some time before users expect this to be a real security boundary on macOS, though on iOS it is definitely more of an expectation.

This just dropped from https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ro-path-KJuQhB86

Noted by https://twitter.com/ptswarm/status/1285974719821500423

Looks like there is a PoC already, HT to @ccondon-r7 for spotting: https://twitter.com/aboul3la/status/1286012324722155525

Limited scope in the advisory seems to indicate nothing hugely important would be revealed by this vuln, but it is probably very dependent on the configuration and nature of any company’s particular deployment. And there tends to be a notion that once a path traversal vuln is found, folks often find new ways to expand their scope.

Given the need to include a corrupted response from a recursive DNS server in the chain, this may be difficult to exploit in practice, at least with a properly configured DNS server that doesn’t allow recursive queries from untrusted sources.

This vuln seems like it needs a hat trick to execute, when there might be easier ways to get DA in a network, but after looking at some analysis by others on this, it seems there could be some creative solutions. I’m changing my mind in that there may be some form of attack on this soon, even if it’s just leveraging the DoS attack, such as this is a crash PoC from maxpl0it:

https://twitter.com/maxpl0it/status/1283537179365564417
https://twitter.com/maxpl0it/status/1283471692006920193

Here are some ruminations on alternate vectors outside of just directly making queries:
https://twitter.com/bmenrigh/status/1283189603873075201

Basically all the info is here for someone to try to attempt a mass DoS attempt at least in conjunction with some sort of side-channel attack on domain-joined clients. So this may become easier to weaponize for crashing domain controllers, but I still posit a reliable RCE will be difficult.

Taking a quick look at [NCC group research](https://research.nccgroup.com/2020/07/10/rift-citrix-adc-vulnerabilities-cve-2020-8193-cve-2020-8195-and-cve-2020-8196-intelligence/] on this, it looks like combining the CVE-2020-8193 authentication bypass with one of the other vulnerabilities allows one to steal VPN session data from a device.

This is paired with sister vulnerability CVE-2020-1457, is a memory corruption issue with Microsofts HEVC (High Efficiency Video Codec) that is a component one can optionally install from the Windows Store on Windows 10 and later. This is not a default component; it even requires the user to actually pay $0.99 in order to install it. So, in order for this to be exploitable::

• a user would have to have also configured the Windows Store to allow payments in the first place.
  
• a user would have had to have manually installed this codec and paid the fee
  
• the user would also have to have open a malicious file they downloaded
  
• while simultaneously not being connected to the internet such that the Windows Store could update (which it does automatically, and when a file is opened)
  

It is possible to enumerate that this codec is installed through a WMI query (see here for how to enumerate), but it is highly unlikely that it could be exploited in any viable way. It is not even possible to easily perform research on the memory corruption vulnerability itself at this time, since it does not appear possible to obtain the vulnerable version of the codec from the store anymore.

As an experiment, I downloaded several sample HEVC files, and was not even able to get the Windows video player to play them or open the store to install the codec in the first place, since Windows does not support many of the common video encapsulation formats used with HEVC.

HT to this helpful Slashdot thread for additional information: https://tech.slashdot.org/comments.pl?sid=16708416&cid=60262150

Noticed an initial script from @RootUp that looks handy for scanning environments: https://raw.githubusercontent.com/RootUp/PersonalStuff/master/http-vuln-cve2020-5902.nse

This script may be better with fewer false-positives according to here :
https://github.com/rwincey/CVE-2020-5902-NSE/blob/master/http-f5-tmui-path-traversal.nse

Note that these scripts actively exploit the vuln, which may not be legal to run without permission, noted by @tsellers-r7 https://twitter.com/TomSellers/status/1280485081908305920