Last Login: January 25, 2023
busterb's Latest (20) Contributions
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/
I caught this interesting info from Trammell Hudson today, where there are experimental patches to enable Secure Boot from Xen. https://safeboot.dev/faq/#does-safeboot-work-with-qubes-or-xen
The above site is also super handy just for understanding the whole Secure Boot landscape, where it fails and how to make it work in general.
If you’re curious about the cloud environment issue, it’s interesting because it’s hard to find vendors that say something that sounds scary like ‘we don’t support secure boot’, which makes sense. Folks would equate that to ‘not secure’. But if you read between the lines, basically AWS does a neat trick if you do try to boot with a GPT / UEFI partition. It silently swaps in an MBR partition instead, signalling to your OS implicitly to disable secure boot. In the end, even if they did support secure boot, you’d have to trust them anyway (they can see all of your memory and disk after all). You can check here for details, other cloud providers may have similar fine print: https://docs.aws.amazon.com/vm-import/latest/userguide/vmie_prereqs.html
I’d love to hear that there is a way to basically get a chain of trust when you don’t own the hardware, just to know folks are thinking about how to implement zero-trust with cloud providers, but it seems like you’d have to send them your own custom TPM modules to establish your own personal chain of trust.
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:
Here are some ruminations on alternate vectors outside of just directly making queries:
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.
There is more information here on how the attack was carried out: http://www.webmin.com/exploit.html
From the article:
At some time in April 2018, the Webmin development build server was exploited and a vulnerability added to the password_change.cgi script. Because the timestamp on the file was set back, it did not show up in any Git diffs. This was included in the Webmin 1.890 release.
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 :
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
Here’s a nice whitepaper from SCADAFence attempting to reproduce these vulnerabilities. Takeaways quoted from the research.
On the negative side: The vulnerabilities exist on additional products that are unknown to the public. Attackers are likely to use this information gap to attack networks.
On the positive side: Some devices that are reported as affected by the manufacturers are actually not affected, or are affected by other vulnerabilities. It might require attackers to tailor their exploits to specific products, increasing the cost of exploitation, and prevent them from using the vulnerability on products that are reported as vulnerable.
Hat tip to JSOF for continuing to follow-up with timely updates on their twitter account: https://twitter.com/JSOF18/status/1279033787154915328
This PR would have made APP_DEBUG no longer the default, but the developers appear to have immediately closed it for some reason: https://github.com/laravel/laravel/pull/5331
Taking a quick look at https://www.jsof-tech.com/ripple20/ , the number of vendor advisories have increased from 2 on the first day to 14 today. Probably worth a fresh evaluation if you haven’t looked since last week to see what technology you have that might be affected.
Based on a quick reading of some of the advisories, a number of vendors that shipped vulnerable versions were not necessarily vulnerable due to how they specifically setup the software. The HP printer advisory stands out to me, given that this target class appears to be the most exposed across various industries: https://support.hp.com/in-en/document/c06640149
This just got more interesting. Apparently a lot of vulnerable targets are HP printers, and they all resolve http://fakeurl1234.com, which given the right circumstances, might allow mass-exploitation of them.
I checked the internet Wayback machine, and it looks like Checkpoint may own this domain (they did in 2018), but it’s not clear who owns it today. It is registered through godaddy as of this writing.
So far, the distribution of
$ProjectRevision HTTP server versions on the internet appears to line up well with actual Treck software releases. Beyond that, the FTP server also seems to be running with the default banner on a lot of hosts, assuming these are not honeypots. See this Shodan query: https://www.shodan.io/search?query=Treck+FTP+server
The Telnet server responds with only the ‘Will Echo’ configuration on connect, so probably not enough for a general fingerprint:
Telnet Will Echo Command: Will (251) Subcommand: Echo ff fb 01
Tom Sellers has a pretty thoughtful counterpoint here, which provides some nice metrics on the actual impact of default passwords: https://twitter.com/TomSellers/status/1468624914508881922