busterb (304)

Last Login: September 10, 2020
Assessments
92
Score
304
1st Place

busterb's Contributions (112)

Sort by:
Filter by:
3

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.

5

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.

6
Ratings
Technical Analysis

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.

5
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

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.

3
Ratings
Technical Analysis

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.

3
Ratings
Technical Analysis

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.

4
Ratings
Technical Analysis

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.

2
Ratings
  • Attacker Value
    Very High
Technical Analysis

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.

1

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.

4
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very Low
Technical Analysis

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

3
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

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

1

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.

https://blog.scadafence.com/ripple20-mixed-results-in-scadafences-exploitability-lab-tests

Hat tip to JSOF for continuing to follow-up with timely updates on their twitter account: https://twitter.com/JSOF18/status/1279033787154915328

1

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

HT to https://twitter.com/hanno/status/1277580935328915457

1

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

2

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.

https://twitter.com/Yannayli/status/1273525317374787585

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.

https://attackerkb.com/comments/8e0d9578-a0f5-4c35-ab98-b26a6901a13f

1

More Fingerprinting

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
1

Fingerprinting Notes

The demo for Treck from August 2006, which can be found at http://www.treck.com/TreckDemo.zip, appears to contain a copy of Treck 4.2.2.13. That seems to jive with version 4.2 being released in February 2006: https://treck.com/treck-tcpip-version-4-2-released-feburary-2006/

If you look at the HTTP server banner that comes from the demo app, you’ll notice that it contains a ProjectRevision tag in the Server: field:

HTTP/1.1 200 OK
Date: Wed, 17 Jun 2020 19:20:42 GMT
Server: $ProjectRevision: Last Checkpoint: 4.2.2.13 $
Content-Type: text/html
Content-Length: 284

That seems to be the version of Treck that is embedded in the Server field. If we take a look at Shodan results for this, we find a bunch of printers and other weird devices: https://www.shodan.io/search?query=ProjectRevision%3A

I think at least some subset of devices can be fingerprinted by looking for this banner. There is already a fingerprint in Rapid7’s Recog, though it has a note that it’s not clear what this fingerprint means. https://github.com/rapid7/recog/blob/master/xml/http_servers.xml#L2389

Asked the Recog guys if we could get a distribution of versions out of Sonar to correlate. Anyone else agree on this?

7
Ratings
Technical Analysis

This may be interesting to exploit when one has a particular device in mind, and it provides some sort of useful access or control, but there is not going to be an apocalypse of Ripple20 exploits for a few reasons:

  • Every target device has to have a tailor-made exploit written for it, outside of a DoS.
  • There is no low-hanging fruit here for actual code execution. Those hundreds of vendors are going to have hundreds of ways they integrated this thing, though you may find some commonalities when folks use the same board support package (BSP) for reference designs.
  • Getting malformed packets into a target device remotely is a lot harder than you’d think these days. Often times, this might as well be considered a local attack, since a lot of edge and intermediate devices will discard many of the malformed packets involved here. That’s why I’m tagging ‘Requires physical access’, because it’s practically the case.

There’s a reason why devices like this have been off-limits for vuln scans and penetration tests for years. It’s because the vendors and users knew their stacks were fragile. This is just reality the infosec world is finally catching up. This isn’t the first exploration of an embedded stack with problems, and it will most definitely not be the last. Whether this makes a change in the industry is a bigger question.

1

Looking at the actual fix, this is even less interesting than I originally thought. It’s a too-large memcmp, which even when the over read is possible, is not guaranteed unless the strings compared are almost identical so that the memcmp gets to the end. And assuming everything aligns, you’re likely to either have nothing happen (because the heap has allocated extra space in the memory page anyway), or at worse you’ll get a crash. See https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=posix/regexec.c;h=084b1222d95b62eb2930166060174ef78cb74b02;hp=91d5a797b82e2679ceab74238416de06693e46ea;hb=583dd860d5b833037175247230a328f0050dbfe9;hpb=2bac7daa58da1a313bd452369b0508b31e146637

This bug was found with ASAN enabled, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34142 and given its longevity, was unlikely to have ever been hit naturally in the wild.

1
Ratings
Technical Analysis

This continues to bury SGX as an actual security mechanism users should be interested in. For leaking keys where you have local access, this is useful for Intel CPUs manufactured in the last 5 years. For general purpose exploitation though, this is less likely to be useful, and the overall risk of using this mechanism still leaves many developers who might use this feature suspicious as they ever were.

The huge performance degradation of RDRAND also isn’t great, though the real problem is for virtual hosting providers where a malicious process or VM can kill overall memory bus performance. https://www.phoronix.com/scan.php?page=news_item&px=RdRand-3-Percent

There are some funny secret-squirrel uses here for the mitigation, as it enables a totally different side-channel problem, but nothing you’d likely see more as a novelty: https://twitter.com/Kryptoblog/status/1270601775184334849

2
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very Low
Technical Analysis

A buffer overread in a very specific part of the glibc regex engine is something, but nothing really by itself. A read might potentially give an attacker a memory leak, but given the number of vendors who haven’t patched I don’t really believe the ‘network’ vector or the high criticality granted from the NVD CVSS. Red Hat’s assessment is more in line: https://access.redhat.com/security/cve/cve-2019-9169

To fully address this vuln, literally every Linux installation on the planet would have to be patched, which just isn’t going to happen.

1

Bumped the value and exploitability ratings here since the PoC got published showing the chain in action. Nice work! https://github.com/ZecOps/CVE-2020-0796-RCE-POC

The kept exploitability medium since there are still a few gotchas to keep in mind, such as it being tough to achieve reliability with > 1 core (when is the last time you bought a computer with 1 core?). You’ll likely see this more for exploiting VMs than, say, your average laptop or enterprise server. On the other hand, none of that prevented mass exploitation of BlueKeep, so be prepared for similar spray-and-pray type campaigns.

Due to the nature of the exploitation, the POC works best for targets running on a computer (or a VM) with a single logical processor. Targets with more than one logical processor running in VirtualBox should be supported as well, but the POC is less reliable in this case.

1

I had a buddy that used to leave one screw loose on his Thinkpad intentionally, so if he ever noticed it was tightened, it would be a sign that someone had tampered with it. Or am I thinking of a Neal Stephenson novel?

3
Ratings
  • Attacker Value
    High
  • Exploitability
    Medium
Technical Analysis

Edit: After writing this @adfoster-r7 pointed out that Zecops has a writeup on exactly how to chain this with SMBGhost. How apropos! https://blog.zecops.com/vulnerabilities/smbleedingghost-writeup-chaining-smbleed-cve-2020-1206-with-smbghost/

Note that if you were already patched against CVE-2020-0796, the current PoCs aren’t going to be impactful to you, so the urgency is lower than if you’re a couple of months out of date. If you’re patching already, no need to panic.

Whenever we see SMB memory corruption leaks, the cry is always ‘oh, if only we had an information leak, we could make this so much more reliable’. Well, assuming someone figures out the details, this could be the information leak folks are looking for to make SMBGhost and other vulnerabilities more reliable to exploit. Not a big deal by itself, but I imagine folks are already trying to figure out how to use this to an advantage. It might not take long given the existence of public SMBGhost PoCs already.

2
Ratings
Technical Analysis

Sure it’s an authenticated vuln, but being able to just switch user accounts sounds like a fun way to cause havoc, especially for long-term persistence type scenarios. Though I guess the average pentest is all about just getting the actual credentials in the first place, but this might be useful for real APT scenarios, especially since it affects the last three major releases.

Don’t know much details of the actual ‘specially crafted request’, so it’s hard to say exactly how exploitable this would be, and you do need creds in the first place. Probably nifty for insider jobs.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very Low
Technical Analysis

This is more embarrassing for Microsoft than something to worry about from an attacker. I’m curious though what data folks didn’t expect Microsoft to get from something called ‘Windows Diagnostics and Feedback’. I always just assumed it was minidumps in the first place, so plenty was already disclosed. Tricky line to draw in the sand.

1
Ratings
  • Attacker Value
    Low
Technical Analysis

This is a primitive that could be useful to complete another attack chain in conjunction with other vulnerabilities. Something to keep in your back pocket when you’re trying to exploit other corruption bugs perhaps.

2
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Medium
Technical Analysis

A new uPnP protocol bug seems to pop up every year or two, looking back on it folks have known it was a bad idea to expose these to the Internet forever, and that uPnP is itself not a great idea from a security PoV. Will likely exist for a long time given the number of devices in existence, so expect it to be used mostly for DDOS operations like @kevthehermit suggests.

2
Ratings
Technical Analysis

It’s too early to really parse exactly what Microsoft means by ‘an authenticated attacker’ since this could mean a read-only guest user or something else entirely. It’s probably not all that interesting to get RCE on a target you can already log into unless there’s some sort of more restricted access that you want to privesc. I suspect we’ll see this one being leveraged more for LPE than RCE once the details are available, though there may also be lower hanging fruit as well.

1
Ratings
Technical Analysis

This vuln. appears to allow any authenticated user on a Windows system to modify the configuration settings for OpenSSH, which would allow for configuring it in such a way that could allow for a privilege escalation for an inbound user via SSH. OTOH, if you are already authenticated, you could just login yourself and perform an LPE much the same way as SMBGhost was used for LPE CVE-2020-0796

2
Ratings
Technical Analysis

This isn’t going to be useful to a pen tester other than a report note, so don’t expect this to get a lot of interest to anyone who is trying to not get noticed. This will be useful I think as a nation-state level attack or in ransom-ware type scenarios, but there are plenty of other DoS techniques out there as well.

3
Ratings
  • Attacker Value
    Very High
  • Exploitability
    High
Technical Analysis

This at first glance sounds a lot like Heartbleed in severity. If an attacker can leak reused buffers from the heap from an SSL firewall, there is bound to be keying material in those leaked buffers, providing very similar outcomes to heartbleed over time. The question will be what specific content can be leaked, how many times it can be run (you’ll need to do this a lot to probably happen on ‘interesting’ buffers, but who knows?), and how quickly you can get new buffers. This covers a wide range of versions, including at least 4 unsupported versions, which means it will likely be discoverable in the wild for some time.

3
Ratings
Technical Analysis

The sophos subreddit reveals some insight on why these firewalls were listening on their WAN ports in the first place. In addition the the admin interface, there’s a ‘user portal’ you can enabled, and even that may not be required for exploitation at least anecdotally:

https://www.reddit.com/r/sophos/comments/g7x3n9/xg_firewall_vulnerability_notification_action/
https://www.reddit.com/r/sophos/comments/g7tax1/sophos_xg_sql_injection_attack_kb135412_released/

Kind of a smart (and annoying for security analysis :) move for Sophos is they made getting the old software near impossible as soon as they found out about the problem. Contrast with Citrix, which left vulnerable versions of Netscaler up in AWS and other locations available for download long after mass-exploitation had started. Handy for research, but a lot of folks also continued to be popped long after the info was public

3

Thanks for the exposure info. It really isn’t subtle about announcing its presence is it?

3
Ratings
Technical Analysis

I came across this in a twitter thread here which highlights that, while it is true that many devices can be reverse engineered / cracked / taken apart / reprogrammed, etc. that in itself is not a vulnerability, it’s a feature! Simply having a debug port available inside of a consumer device is not any different than having an OBD-II port in a car. That’s what it’s there for. Having such a connection does make it easier to find more impactful attack vectors, lowering the barrier for security researchers to find other issues. You want folks to find bugs in your backend, certificate pinning, update protocol, etc.

In a related example, the smart toy mentioned in these advisories also had a root-shell enabled if you cut the stuffed animal apart and plug into the USB port on the circuit board. But the real interesting stuff was in the API gateway being remotely hijackable due to poor validation.

9
Ratings
Technical Analysis

The vmdir VCenter process appears to expose internal data via an unauthenticated, unencrypted LDAP service. See Metasploit module PR for exploitation details: https://github.com/rapid7/metasploit-framework/pull/13253 . Given that this vuln appears to not exist in a ‘fresh’ install, this looks like a legacy configuration option that should have been disabled much earlier. Possible that importing an old configuration might reenable this.

Since my original assessment, we found that this vulnerability also allows anyone with unauthenticated network access to create arbitrary users in vCenter, allowing for full unauthorized access to the vCenter environment and the virtual machines within.

Blocking LDAP port 389 may be an intermediate mitigation.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Medium
Technical Analysis

How do you get someone to autenticate with an untrusted PPPD peer these days? I just don’t think the vector for attack is easy for any attacker, and if you are in a position to sit there, like in a DSLAM, you have access to a lot of other evil possibilities.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very Low
Technical Analysis

Another in the long line of speculative side-channel attacks, this increases the effectiveness of existing attacks, but is also disabled by similar mitigations. Unlikely to be used in any practical way by an attacker, there are many more sources of low-hanging fruit.

6
Ratings
Technical Analysis

A fairly standard policy of disabling preview windows is a good mitigation for this vulnerability. Since this appears to have been found in the wild, but I’m lowering this from original assessment, due to it being patched in the latest April 2020 PT, and there wasn’t a particular rush to fix it out of band.

Tencent has an analysis of the vulnerabilities based on the PT diffs: https://mp.weixin.qq.com/s/RvTZWvcXiXsI7xB6L9RWIg

From the MSRC advisory, this has limited impact on Windows 10.

For systems running supported versions of Windows 10 a successful attack could only result in code execution within an AppContainer sandbox context with limited privileges and capabilities.

2
Ratings
  • Attacker Value
    Low
  • Exploitability
    Very Low
Technical Analysis

This appears to now be exploited in the wild: https://www.us-cert.gov/ncas/current-activity/2020/06/05/unpatched-microsoft-systems-vulnerable-cve-2020-0796

RCE PoC: https://github.com/chompie1337/SMBGhost_RCE_PoC

I wanted to note there’s a public DoS PoC here: https://github.com/eerykitty/CVE-2020-0796-PoC
Another one is here: https://gist.github.com/asolino/45095268f0893bcf08bca3ae68a755b2

Here’s the research on RCE as well, which confirms it was challenging to exploit! Hopefully everyone is patched by now: https://ricercasecurity.blogspot.com/2020/04/ill-ask-your-body-smbghost-pre-auth-rce.html

And another example using maybe a different infoleak (not many details there yet):
https://twitter.com/ZecOps/status/1252288104435761154

And, today with everyone Coronavirus sequestered, you’re unlikely to inflict any sort of at-scale exploitation if everyone’s at home on a host-isolated VPN and literally inaccessible from a mass networking PoV in an office. Hey, maybe working from home is good for security!

1

I wonder if simply ignoring deauth frames would be enough to also mitigate this, as in the stayauth option on OpenBSD:: https://man.openbsd.org/ifconfig

3
Ratings
Technical Analysis

The TL;DR from the technical whitepaper found here: https://www.welivesecurity.com/wp-content/uploads/2020/02/ESET_Kr00k.pdf

If there are outbound TX queue packets for certain common WiFi devices, and a disassociation management packet is sent, the device will clear the encryption key to all zeros, and send the remaining packet data in the queue with that hardcoded key. If an attacker can send diassociate packets and then listen for any residual data frames, they can decrypt whatever traffic remains in the TX queue on those devices, which may be a few hundred packets depending on the data rate involved.

While this seems like a real risk, I’m firmly in the camp that relying on the physical layer in the first place for data protection is misguided, and that really end-to-end security is still the only way to – Wifi has proven over and over to be a weak security boundary. By the time this is wide-spread fixed, we’ll all be using DNS-over-HTTPS by force from browsers anyway. So, from an end-point consumer PoV, this isn’t a big deal. Not any worse that connecting to that unencrypted hotel network you may have used earlier.

Some potential future vuln predictions here: https://twitter.com/vanhoefm/status/1232738451587555328

Thinking through situations where an attacker might find this useful would be in physically accessing business-local OT networks, like point-of-sale, manufacturing, or other squishy-on-the-inside networks. Expect to see this show up in the next Wifi Pineapple release or in your next pen test physical engagement report.

1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

Expect that this may be the first in a string of OpenSMTP vulnerabilities (now that there’s increased scrutiny, not because I have any kind of insider knowledge), but that the results of this vulnerability will probably be an improvement in OpenSMTP’s design as a result, since bug classes like this tend to get the OpenBSD developers working hard to find general solutions in subsequent releases.

3
Ratings
  • Attacker Value
    High
  • Exploitability
    Very High
Technical Analysis

Just a quick note the Tenable blog has a number of useful resources here, which also links to a few other PoC scripts:

https://www.tenable.com/blog/cve-2020-1938-ghostcat-apache-tomcat-ajp-file-readinclusion-vulnerability-cnvd-2020-10487

2
Ratings
Technical Analysis

This is enabled by default in 2012 servers. It seems some folks have gotten RCE with this, though there are no public exploits. Further research may show this as being easier than it is at first assessment. https://social.technet.microsoft.com/wiki/contents/articles/10973.configuring-udp-support-on-the-rd-gateway-in-windows-server-2012.aspx

1
Ratings
Technical Analysis

As a privilege escalation does still need an initial vector onto the phone, so requires either another exploit or additional tradecraft. This is unlikely to work in conjunction with a Chrome exploit today because many phones run a 64-bit kernel + 32-bit Chrome, perhaps for this very reason!.

After testing the Metasploit module it took a considerable amount of specific targeting effort to get just the right model, and because the phone has a feature/bug that made it difficult to downgrade firmware (and the phone likes to upgrade on its own very easily), targeting this after disclosure may be very difficult.

However, if you can find this bug or a similar one on a common phone that is past applying security updates, it could be useful for privesc from a malicious app. But I think the issue that plagues a lot of Android binary exploitation vulns is the lack of generality and there being lower-hanging fruit.

3
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Medium
Technical Analysis

It looks like the base software is installed as part of a Centos 7 system. Customizations are found in the ‘hardening’ directory on the installer ISO file.

atlantis-post-install.sh looks interesting, as it sets up all of the services and unpacks the custom file satellite-install.tgz

Hasty diff between 201910 and 202001

$ diff -u /mnt/hardening/atlantis-post-install.sh atlantis-post-install.sh 
--- /mnt/hardening/atlantis-post-install.sh	2019-11-20 13:01:24.000000000 -0600
+++ atlantis-post-install.sh	2020-01-29 22:03:41.000000000 -0600
@@ -68,7 +68,8 @@
 firewall-offline-cmd --zone=user --add-service=ssh
 firewall-offline-cmd --zone=user --add-rich-rule='rule family=ipv4 port port=443 protocol=tcp reject'
 firewall-offline-cmd --zone=user --add-rich-rule='rule family=ipv6 port port=443 protocol=tcp reject'
-# dmz zone already exists
+# dmz zone already exists (ssh service is inherited - we remopve it here)
+firewall-offline-cmd --zone=dmz --remove-service-from-zone=ssh
 firewall-offline-cmd --zone=dmz --add-rich-rule='rule family=ipv4 port port=80 protocol=tcp reject'
 firewall-offline-cmd --zone=dmz --add-rich-rule='rule family=ipv4 port port=443 protocol=tcp reject'
 firewall-offline-cmd --zone=dmz --add-rich-rule='rule family=ipv4 port port=8443 protocol=tcp reject'

Interestingly the docker layers that appear to be part of the build leak a number of internal Cisco resource names:

    curl http://timaeus.cisco.com/devKey \u003e ~/.ssh/id_rsa \u0026\u0026     chmod 0600 ~/.ssh/id_rsa \u0026\u0026     eval `ssh-agent` \u0026\u0026     ssh-add \u0026\u0026     ssh-keyscan -p 7999 -t rsa bitbucket-eng-sjc1.cisco.com \u003e\u003e ~/.ssh/known_hosts \u0026\u0026     bundle install --with cerberus --without development test alpha \u0026\u0026     rm -rf ~/.ssh \u0026\u0026     bundle config --global frozen 1;"},{"created":"2019-11-21T05:24:36.571974064Z","created_by":"|0 /bin/sh -c sed -i '/jessie-updates main/d' /etc/apt/sources.list"},{"created":"2019-11-21T05:26:54.698408023Z","created_by":"|0 /bin/sh -c apt-get update \u0026\u0026 apt-get install -y postgresql-client"},{"created":"2019-11-21T05:26:55.987328112Z","created_by":"|0 /bin/sh -c ln -sf /dev/stdout /usr/src/log/sidekiq.log"},{"created":"2019-11-21T05:26:56.230921929Z","created_by":"/bin/sh -c #(nop) COPY file:31a545d2f5f434f3e031ea7c4fd4af19d67f5fb40e217c1ed1ef665da663abce in /usr/local/bin/ "},{"created":"2019-11-21T05:26:56.391769508Z","created_by":"/bin/sh -c #(nop)  CMD [\"/bin/sh\" \"-c\" \"/bin/bash /usr/local/bin/startup.sh\"]","empty_layer":true}],"os":"linux","rootfs":{"type":"layers","diff_ids":[

Other internal creds seem to be baked into the app as well, even in the current version. This app looks worthy of future explorations, especially for the other secrets it contains. I’m just not sure how much install footprint it has in the real world, at least I’ve never worked for a company that would be the target market for this app.

2

I wonder if versions after R2 2017 SP1 that were upgraded from previous versions randomly generate an encryption key anyway. You’d think they would have at least implemented logic to detect the default being in use and to automatically change it to a random version. That would make later versions not vulnerable anyway.

6
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

This is a low-risk, high-gain vulnerability, exploiting a path inclusion (which is basically on the same impact as the Citrix ADC (Netscaler) path traversal bug). Though it’s probably less likely to find these sitting on the public internet.

PoC from Jin Wook Kim
@wugeej

https://twitter.com/wugeej/status/1222762164626186242

[PoC] Juniper Junos Space Local File Inclusion (CVE-2020-1611)

- GET Param:
 (1) Set "Format" to "txt"
 (2) Set "FileUrl" to a local path

- /ect/passwd
GET /mainui/download?X-CSRF=Y581SFvK....53107455361&FileUrl=/etc/passwd&Format=txt&nod... HTTP/1.1
2
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

Based on other WebLogic vulnerabilities and the rich ecosystem of offensive tools against it, I have a good idea this will be useful without doing a whole lot of specific research. Mitigation strength is place at medium simply because WebLogic is a rich target, and extra care will need to be made by the user to ensure that awareness of future vulnerabilities and health of an installation is closely monitored.

1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

This looks just as useful as CVE-2015-3884 for deploying a web shell, and easy to check for exploitability. I’m not sure if this is authenticated though, so it’s unclear if this is useful without some level of additional access. The CVSS score indicates that it does not require additional privileges, so I guess not?

I didn’t find any of these at first glance sitting on the bare internet with Shodan.

1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

If Serpico is used to provide reports on pentesting results, this could be a problem for customers as there would be plenty of sensitive data that an attacker could use to leverage as a free pass into customer environments (assuming they had not been remediated).

1
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Low
Technical Analysis

This is a client-side exploit, which would require spoofing an existing server. If an exploit surfaced, this might be useful for targeting admins, or even other attackers. Would make an interesting addition to a ‘hack back’ honeypot.

1

crypt32.dll is so uniquitous though, I’m sure there are a non-trivial number of apps that assumed that their certificate pinning was safe enough to provide protection against MitM. Think about how many EDR agents there are out there that talk to a bunch of non-public DNS hostnames for the local command-and-control hub, maybe using MDNS, etc. for that name – and then run code and commands they download. I think we’re going to see a lot of novel attacks utilizing this as a springboard just when folks thought it was safe-ish to trust airport wifi again.

4
Ratings
Technical Analysis

I’m not so sure that @todb-r7’s assessment is completely correct, this affects all the things that validate certs, including TLS in browsers, powershell, etc. So kinda impactful beyond just local code execution, this could be a vector for all kinds of other spoofing.

More info in swiftonsecurity’s thread regarding how this pivots into RCE: https://threadreaderapp.com/thread/1217159419533893633.html

The method that should be affected here is https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certgetcertificatechain courtesy of https://twitter.com/hackerfantastic/status/1217211301375696896

Open source software that uses or exposes this method: https://codesearch.debian.net/search?q=CertGetCertificateChain&literal=1

The exposure of user-defined eliptical curves in TLS certificates created a window of opportunity for this bug to appear, which may have been mitigated if the underlying specification was simpler as well, especially with regards to seldom-used features like this. One may want to look ahead to similar bugs in other dark corners of a TLS implementation near you!

1

I guess it’s good that it doesn’t affected Windows 7 and 2008 R2 – guess we should stay on those huh :)

3
Ratings
  • Attacker Value
    Low
Technical Analysis

The discussion here https://lwn.net/Articles/806546/ shows some of the problems fixing this generally, which really means disabling the weak host model as a mitigation. This is likely perfectly fine for single-ended hosts, which are likely the most vulnerable targets in the first place.

4
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

This configuration issue could really affect any version, since it’s just someone having left the debug option on in the default config.
Metasploit has had a general scanner for this misconfiguration since 2012 in auxiliary/scanner/misc/java_rmi_server and 2011 in modules/exploits/multi/misc/java_rmi_server. Just noticed https://github.com/rapid7/metasploit-framework/pull/12565 which might be useful as well.

Shodan only shows maybe one host on the internet exposing this port in something that could plausibly look like JMX. The next great internet work this will not be: https://www.shodan.io/search?query=port%3A18983

I’m giving this a high attacker utility but also a low urgency to patch, because the patch is almost irrelevant here. If you’re using the default solr config, your solr install probably doesn’t work anyway! The patch isn’t really required to fix this configuration bug,, and you could be vulnerable with or without updating to a newer version. Even if you patch, if you have the a bad config, it’s not necessarily going to auto-update either. Any authenticated vuln scan is probably going to produce misleading results about whether you’re actually vulnerable or not, unless it checks your config file. Doing a remote scan is much better.

The mitigation is really just making sure you don’t deploy a config that leaves unauth RMI servers on a network, but nothing really stops you from shooting yourself in the foot either. Note that Solr’s own docs tell you how to enable this bit, but also it says to not use it in production. https://lucene.apache.org/solr/guide/7_0/using-jmx-with-solr.html

1
Ratings
  • Attacker Value
    High
Technical Analysis

Since this is being exploited in the wild, and affects a wide range of Internet Explorer versions, it looks like it will have some longterm success in targeted phishing and malvertizing campaigns. IE might be down to just 2% of usage, but it’s the only option out of the box on most WIndows Server versions, so it’s at least easy-ish to be running a vulnerable version until you can get patches applied or download a different browser first.

Probably only urgent to patch if you actually use it.

2

I wonder what the exposure of this version is 4 years later. Probably fairly low for an opportunistic public attack at least: https://w3techs.com/technologies/details/ws-tomcat/all/all

1
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Very High
Technical Analysis

Authentication bypass on medical software in general is a big utility to both an attacker and a liability for medical professionals using the software.

Where is may be less applicable in utility is simply in where it is used. The list of labs that do use this software is listed straight on the software’s website which hopefully allowed them to communicate the importance of patching before this vulnerability was announced (and hopefully they applied additional compensating controls in the process): http://blis.cc.gatech.edu/index.php

1

Do we have enough info here to perform a remote check for exploitable machines (is there a way to test without causing a crash)?

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very Low
Technical Analysis

This requires authentication via a remote shell in order to be effective. If an adversary is on your Metasploit Pro machine such that they can access the key in the first place, it’s already game-over. So, having the web-server certificate key (which is by default a fake cert anyway) is unlikely to be a high risk for a Metasploit Pro user.

4
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Low
Technical Analysis

Based on the technical analysis by Kaspersky, this is a very effective exploit, and is able to leverage an info leak, heap grooming, and the malware deployed via watering-hole injection on a Korean-language news portal, establishes persistence via a dropped file on disk.

An attacker does need to leverage a few items in advance for this and any client-side attack, that is a watering hole injection or some other delivery method. Chrome’s quick patching mechanism means these vulns typically have a short shelf life, though the inability to force users to actually update is a limiting factor.

1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very Low
Technical Analysis

Effort to execute is high now because it’s so hard to find vulnerable web browsers that can even run Java applets in 2019. But if you have a target audience, this was obviously a good vuln in 2012.

1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

This is fairly trivial to exploit since there is an excellent Metasploit module for it. This software, when you find it, is likely to contain important business data, which can be valuable to an attacker.

1
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Low
Technical Analysis

Probably not that interesting of a bug for an attacker. Basically you can DoS a BIND server. I sort of think most folks using BIND in a critical environment are likely using the ISC releases anyway. It is telling that the bug in this backport appears to have taken a year to discover.

4
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

It’s not clear often this particular configuration is deployed; you may find that you’re not vulnerable in particular if you’re not using the specific configuration (just because you’re using PHP 7 or nginx, that’s not sufficient to be exploited). But, you should at least check the configuration even if you don’t patch, since the exploit itself is reliable, trivial, and easy to spray.

It appears there are possibly other ways to exploit earlier versions of PHP with this same bug: https://twitter.com/TheHackersNews/status/1188171528090746880?s=20

3

Other related vuln possibilities could be auditing everything that checks UID_MAX / GID_MAX to see if seteuid/setegid failures are detected.

useradd doesn’t detect a problem on Linux but adduser does

/usr/sbin/useradd -d /home/bcook-max -g bcook -s /bin/bash -u 4294967295 bcook-max
useradd: invalid user ID '4294967295'

vipw is fine with this uid, but su fails

# grep max /etc/passwd
bcook-max:x:4294967295:1000::/home/bcook-max:/bin/bash
~
# su - bcook-max
su: cannot set user id: Invalid argument
5
Ratings
  • Attacker Value
    Low
  • Exploitability
    Very High
Technical Analysis

While this is easy to exploit and low risk to the stability of the target system, it is post-exploitation, and highly dependent on a relatively uncommon and paranoid type of configuration where an administrator is actively monitoring trusted or untrusted users on a multi-user system. There may be some way to leverage this as a primitive for a different kind of exploit chain, but more often than not users are allowed to just pivot into root directly, or specific privileged executables are escalated with setuid rather than sudo.

Someone somewhere has a that golden target, and is having a field day. Everyone else had root anyway :)

2
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very Low
Technical Analysis

As I understand it, most kubernetes clusters will require auth or a foothold to reach in the first place. Why would you bother with a DoS attack at that point? Much more attacker value to be had in exploiting the cluster in ways that don’t bring it down.

Compare authenticated:
https://www.shodan.io/search?query=kubernetes+401

And unauthenticated searches:
https://www.shodan.io/search?query=kubernetes+%21401

1
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Very Low
Technical Analysis

It’s probably just as important to choose terminal emulators that have minimal feature sets if you are doing administration work in the first place. iTerm2 in particular has a lot of features that are internally labeled as insecure, so it probably makes sense to evaluate if you are actually using those features and if you need them.

A maybe growing thread on exploitation: https://twitter.com/TheColonial/status/1182032288785166336

Also here’s where to disable some of the other features by answering ‘Yes’ to this setting.

image

1
Ratings
  • Attacker Value
    High
  • Exploitability
    Medium
Technical Analysis

Noticed this while looking into recent iTerm vulnerabilities and thinking about how to exploit iTerm’s builtin image rendering and file download capabilities. This seems to have the ability to cause havoc especially on machines that cannot upgrade to newer OSes due to hardware obsoleting by Apple. Curious if there might be other things to look at in NSImage as well.

Marking utility a little lower just because this is a couple-year old vuln.

3
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Very High
Technical Analysis

The Metasploit module for this against Exim (exim_gethostbyname_bof) was pretty useful in 2015, though there are lots of other ways to exploit Exim that kind of show that things haven’t changed a whole lot since then. Hopefully there will be more systematic ways to guard against heap overflows in general on the OS these days, even if it’s at a performance loss (asan?).

1
Ratings
  • Attacker Value
    Low
  • Exploitability
    High
Technical Analysis

Implementing a crash for this is pretty easy. Implementing an exploit may be tricky given the diversity of heap configurations, though if you targeted one distro or container it’s probably easier.

Note, this vulnerability was also fixed before it was reported as a result of deeper analysis of user-controlled variables in Exim as a whole. Future releases of Exim may be much harder to exploit as a result of this general effort. See this note from Exim maintainer ‘Comet’ on areas they need help with in the future: https://lwn.net/Articles/801265/

3
Ratings
  • Attacker Value
    Very High
Technical Analysis

DNS over HTTPS is good for individual network privacy: it circumvents filters, nobody can see what you’re browsing passively. If I was in a hotel or public wifi, it’s definitely what I would expect my browser to use! But, it’s bad for aggregate user privacy as browsers are rolling it out by default with their own DNS providers. Now Cloudflare, Google, or one of a few big resolvers see what you’re browsing actively (since there are few local recursive resolvers). On the other hand, the privacy ship with respect to the big providers has probably sailed anyway.

DoH provides more security guarantees than other DNS security solutions, e.g. DNSSec ensures authentication and integrity but not confidentiality. But it has similar limitations that prevent it from being usable as a system-wide resolver. Verifying certificates requires accurate time, so you have to fall back to regular DNS when setting time via NTP, for instance. There’s no ‘just encrypt’ option with for DNS-over-HTTPS/TLS. So you have to accept sometimes it’s still going to fail-open if other properties can’t be met.

DoH is probably great for not standing out in network traffic: I can lookup domains without being noticed, and malware is beginning to use it as well, Since it’s not easily distinguished in network traffic, adversaries can also avoid standing out. Wannacry was initially stopped by blackholing a domain over DNS. Identifying and sinkholing C2 domains now becomes harder. DNS has been a useful exfiltration and C2 technique for a while, since it exploits obscurity. DNS-over-HTTPS is even better, since it adds confidentiality over common infrastructure. There are some reference tools on this topic showing how this is accomplished.

5
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

As the world’s most popular forum software, this is a big target, and that this vulnerability was an 0-day when it was first found is also extremely useful as an attacker. When exploited, the vulnerability allows an attacker to execute PHP code on any vBulletin server without requiring user authentication. It works with the default installation, meaning every vBulletin site was vulnerable at one point.

1
Ratings
  • Attacker Value
    High
  • Exploitability
    Low
Technical Analysis

sdfsadf

3
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very Low
Technical Analysis

Capability problems with exploitation: an attacker needs a payload to do something other than a DoS. Shellcode for embedded OSes like this needs to be customized for each firmware version and device, which causes problems. This significantly increases the cost for an attacker to do something other than a DoS since it has to be customized to the target. High utility for an advanced actor who has the capability to develop custom payloads and a particular target in mind. Low utility for a low-skilled actor who wants to ‘spray and pray’.

Mitigations: folks should limit opportunities by having strong malformed-packet filtering at the network level. Routers and switches should not be based on VxWorks at the edge.

https://www.blackhat.com/presentations/bh-usa-09/LINDNER/BHUSA09-Lindner-RouterExploit-SLIDES.pdf

Another interesting issue with this vulnerability lies around getting the malformed packets from the edge of a network into the core of the target device. Each device needs independent analysis to determine the risk. An edge device would be riskier than a core, one. In this particular case, it’s really surprising however that VxWorks did not just isic, which has been around for years and years to find a vulnerability like this: http://isic.sourceforge.net/

Note: when validating the Urgent/11 scanner here: https://github.com/ArmisSecurity/urgent11-detector we found that it was unlikely to be effective across even a minimal security boundary of a standard router between network segments. We had a hard time testing it since the malformed packets were discarded by several commodity and not specially-configured kit.

5
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

A classic vulnerability. Like small pox, you’d wish it was actually eradicated by now, but it still pops up occasionally in legacy systems.

1
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Medium
Technical Analysis

This vulnerability is neat, but it’s also in a library that has stopped upstream development for some number of years, and more recently Debian/Ubuntu completely expunged it from their repositories. A bigger risk is when software embeds a copy (because upstream is dead) that never gets updated, leading to zombie vulnerabilities rising up from the grave of an obsolete video decoder.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Medium
Technical Analysis

This vulnerability had been in Metasploit Framework for some time, but requires an attacker to achieve some level of social engineering to be effective. Basically, don’t import random things into Metasploit Framework!

1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Low
Technical Analysis

This bug is interesting because it was being used in the wild to install software without user permissions: https://krebsonsecurity.com/tag/cve-2019-0797/. It had intrinsic value to attackers already. Whether you are really at risk depends on whether you like to run malicious binaries. Do you?

6
Ratings
  • Attacker Value
    High
  • Exploitability
    High
Technical Analysis

What a pain to make it work generally across different versions! The work put into this will be foundational for future exploit development around RDP and Windows kernel exploitation in general.

4
Ratings
  • Attacker Value
    Medium
  • Exploitability
    High
Technical Analysis

A SOP bug requires the attacker to inject a resource into one domain, and be listening on another. Such a vulnerability would need to be combined with a web application vulnerability like XSS, and would be less useful from a standalone PoV as something like a Metasploit module. But with the right target audience and web application, this is a nice primitive.

5
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

This is bound to have many vulnerable installations that may persist for some time, since webmin tends to be used by novice admins.

1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Technical Analysis

Looks like a good source of additional data for further exploitation.

4
Ratings
  • Attacker Value
    Very High
Technical Analysis

Affects every version of Windows from Windows 7 to Windows 10. A DVC, or Dynamic Virtual Channel, packet needs to be sent with a specially-crafted uncompressed field field value larger than an integer, causing an overflow, according to MalwareTech’s writeup here: https://www.malwaretech.com/2019/08/dejablue-analyzing-a-rdp-heap-overflow.html

1
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Medium
Technical Analysis

This looks like it will be a useful vuln for a while, and probably more related things to find in custom SSL VPN stacks.

6
Ratings
  • Attacker Value
    Low
  • Exploitability
    Medium
Technical Analysis

Possibly a source of other vulnerabilities in the internal webserver, worth a look at least to see if there is anything else that could be exploited.

Note, it appears that now there are private Zoom PoC’s exploiting the webserver for remote code execution, though this appears to require the user to have uninstalled Zoom first leaving the web server behind. This is likely due to something in the clawback reinstaller not validating or accepting an attacker-controlled resource for the installer binaries.

1
Ratings
  • Attacker Value
    High
  • Exploitability
    Very Low
Technical Analysis

 This need some sort of vector to trick the user. Probably not that hard via watering hole attack somewhere that vmware user congregate.

0
Ratings
  • Attacker Value
    Low
  • Exploitability
    Very Low
Technical Analysis

This wasn’t vulnerable in OpenBSD, because it didn’t free the memory the chip was writing memory to back to the kernel. On Linux boxes running a kernel < 2016, this could be RCE over wireless, and was proven to be a DoS, but for only a short time since the Grub mitigation that put the chip to sleep helped a lot.

Basically depends on a lot of circumstances, on hardware that is increasingly aging and irrelevant.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    High
Technical Analysis

Documentation updated to discuss security risk, MS does not consider this a privilege boundary.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Low
Technical Analysis

Details

Kernel type confusion noted via code review, but no direct exploit. Probably fixed later.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Medium
Technical Analysis

Rubygems has a vulnerability that allows for arbitrary code execution while a gem is being installed. However, it’s unclear how this is any worse than either using the malicious gem itself, or using the ability of gems to compile and execute arbitrary build instructions in the first place. It is interesting to be able to name a gem a particular way to create code execution. But you have to convince someone to install your gem in the first place. I presume that rubygems.org now prevents malicious gems from being published, but it would be interesting to see.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very Low
Technical Analysis

Attacker requires too much control in advance for this to be useful.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    High
Technical Analysis

UAF, probably fixed in next major version.

2
Ratings
  • Attacker Value
    High
  • Exploitability
    Very High
Technical Analysis

Many versions were vulnerable, and the vulnerability was in a well-used API. The exploit took some time to develop due to a need for a deep understanding of Drupal internals (see blog post in references).

1
Ratings
  • Attacker Value
    Medium
  • Exploitability
    Low
Technical Analysis

XSS always requires extra effort in a pentest, it depends on the actual app being targeted, the user behaviors, privileges of users, etc. This will likely need a custom payload to be useful as well, leverage a browser exploit, etc.

1
Ratings
  • Exploitability
    Very Low
Technical Analysis

This is not an exploit by itself, but useful primitive that could be used with something else for an info leak.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    High
Technical Analysis

No known exploitable services in the wild

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    High
Technical Analysis

Required disabling builtin protections on ancient SW versions, EIP is always NULL.

1
Ratings
  • Attacker Value
    Low
  • Exploitability
    Low
Technical Analysis

Details

This is possibly another ‘getsystem’ technique for UAC bypass.
The effort required to exploit this vulnerability is higher because it requires
a particular set of circumstances that are not universal.

From the report:

My 2c: You’re already an admin, it’s not letting you do anything you couldn’t already do, it’s just not giving you a heads up (UAC warning).

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very High
Technical Analysis

Project zero reason for closure: Info not valuable (attacker can view and control power settings).

1
1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very High
Technical Analysis

Not exploitable other than for crashing a browser, probably not that useful though.

1
Ratings
  • Attacker Value
    Low
  • Exploitability
    Very Low
Technical Analysis

The details are pretty heavily documented on robotattack.org, so no need to reproduce them here. If you haven’t updated your TLS stack to only support perfect forard secrecy (that is, you haven’t updated it in the last 10 years), you’re hosed. But you already were anyway.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Very Low
Technical Analysis

Vendor reason for not patching immediately: Attacker requires too much control in advance.

1
Ratings
  • Attacker Value
    Low
  • Exploitability
    Very Low
Technical Analysis

ASLR Bypass, vendor says they would fix in next versions.

1
Ratings
  • Attacker Value
    Very Low
  • Exploitability
    Low
Technical Analysis

Unrealistic privilege escalation scenario, fixed in AOSP 2 years ago, but maybe usable in older versions.

0
Ratings
  • Attacker Value
    Low
  • Exploitability
    High
Technical Analysis

Allows Admin to load unsigned driver, but that is already possible other ways.