gwillcox-r7 (500)

Last Login: December 06, 2021
1st Place

gwillcox-r7's Latest (20) Contributions

Sort by:
Filter by:
Technical Analysis

This is an interesting vulnerability in the Ai-Bolit AV scanner functionality of CloudLinux Inc Imunify360 running Ai-Bolit prior to AI-Bolit 31.1.2-1, Interestingly whilst it was stated that 30.8.8-1, 30.8.9-1, 30.10.3-1, 31.0.3-1, and 31.1.1-1 were affected, in my testing the Ubuntu dpkg files that were available on CloudLinux’s servers only contained versions 30.10.3-1 and later, and surprisingly only 30.10.3-1 actually contained the vulnerability. All later versions were found to be patched. Older versions were not found on the server so it was not possible to obtain a copy of these affected versions, however it is likely they were also affected and the patch was either introduced with 31.10.3-1 or was introduced with 31.1.2-1 and then backported to versions 30.10.3-1 and later.

Note that the software used to be at as ai-bolit_30.10.3-1_amd64.deb however it appears it has since been removed. If you need a copy of this file please feel free to reach out.

Working from the original PoC at we can see that the vulnerability occurs due to an unserialize() call within deobfuscateDecodedFileGetContentsWithFunc($str, $matches) where the line $resCode = implode(' ', @unserialize(base64_decode($matches[5]))); is executed, which first base64 decodes the 5th match, which contains a subset of the attacker controlled file that is being scanned, Base64 decodes it, and then passes it, unchecked, into a call to unserialize().

Tracing back we can see that there is a regex in the Obfuscator class associated with the ID decodedFileGetContentsWithFunc(). This is the regex that is used to scan the file, and then if any patterns are found that match this regex, then deobfuscateDecodedFileGetContentsWithFunc() is called to deobfuscate the file.


After a lot of time spent manually going through the regex using I was able to recreate a file that would trigger the regex and result in deserialization:

function func1($param){ $asdf = "cool";$asc = str_split($foobar);$word = array_flip($asc);$food = 0;$cored="";$bored=preg_replace("asdf", "", $deda);do {$asdf = $asdf[$acfd[$foa++]];$asdf = $asdf[$acfd[$foa++]];$asdf = $asdf[$acfd[$foa++]];$asdf = $asdf[$acfd[$foa++]];$coolio=($joko << 2) | ($foko >> 4);$cood = (($aed & 15) << 4) | ($ave >> 2);$aesd = (($ke & 3) << 6) | $hes;$hec = $hek . chr($jok);if ($asdf != 64) {$foobd = $coor . chr($foj);}if ($hdo != 64) {$fed = $asdf . chr($ase);}} while ($asdfas < strlen($ddhdh));return $asdfe;} function func2(){$corlan = @file_get_contents(asdfasdf()); $variable1 = "INSERTTHEPAYLOADHEREBASE64ENCODED"; $variable1 = @unserialize(func1($variable1)); function func3($faccc=NULL){foreach (func2() as eval($fjdjd);}}} func3();

Note that most names are junk however anything with variable1 or func1 is specifically named as such (the string “variable” or “func” followed by a number) as they need to be the same name everywhere they are used. This is due to the regex using some of the results from earlier checks later on in its code, so the names of these functions or variables must remain the same otherwise the regex won’t match.

Now whilst deserialization attacks can result in RCE, arbitrary file deletion, or otherwise remember that it really depends what classes are available to the end user. In my experiments I found the following classes were available when the unserialize() call was made:


Unfortunately of these I was mainly only able to find cases where deserializing an object would cause file deletion. In cases where file creation was possible, it was either in a fixed location with a nonexecutable extension, or more often than not the content of the file would be a fixed string which wasn’t useful for the purposes of exploitation.

The most promising class appeared to be CloudAssistedFiles which could cause a CURL request to be made, however it appears that the URL, as well as the contents of the request could not be controlled, so unfortunately there would not be any way to retrieve data from the server from what I could tell.

Arbitrary file deletion can be achieved via the Logger class and the $log_file parameter of the __construct function.

At the end of the research I was not able to form a useful payload for this vulnerability. In my opinion, given what I saw so far, the most likely possibility for exploitation would be that someone used the exploit chain to delete something like .htaccess and then abuse that to bypass a file upload filter or similar.

However this is highly dependent on the application and a variety of other factors, vs this being a bug that can be installed purely by virtue of having Ai-Bolit AV scanner installed.

A final important note is that CloudLinux Inc Imunify360 is, by default, configured to check for updates automatically once daily. This means its very likely that most installations in the wild are up to date, and I personally noticed this when trying to find servers with Imunify360 installed, as most of these servers were running up to date versions of Imunify360 or one of its respective components.

Technical Analysis

An unauthenticated command injection bug in WD My Book Live and WD My Book Live Duo devices that gives root level access to the device and all the data stored on it. This has been actively exploited in the wild and there is no plan from the manufacture to fix this bug since it only affects WD My Book Live devices which they state where introduced to the market in 2010 and recieved their final update in 2015. Your best bet is to migrate your data and then get rid of this device somehow.

It is also important to note that this auth bypass occurs due to a refactoring of the authentication code where appropriate access checks were not applied. You can read more on this at

Technical Analysis

From what I can tell this is likely a relatively easy exploit given that one resets the entire device via an unauthenticated request. This essentially allows the attacker to reset the device and erase all data on the storage device without any authentication at all. This could be used to ransom off targets and threaten to destroy their data if they don’t comply, then use the bug to exploit the storage devices and wipe all their data if they didn’t pay up.

Of less value to attackers since they would likely just end up erasing a client’s data however given how protective of data most companies are, I can imagine this most likely being used in ransom schemes as mentioned above. Less likely to be used to actually steal data unless by resetting the device you can somehow get other devices to resync the data to the drive and have the attacker now have full access to the box.

Otherwise its good to note this has been exploited in the wild and there is no plan to patch this bug since the firmware went out of date in 2015 and the manufacture has stopped updating the firmware for this device with no plans to supply any changes even for security related issues. Your best bet is to migrate your data and get a more modern device. More info on the refactoring of the code that lead to this bug can be found at

  • Attacker Value
  • Exploitability
Technical Analysis

This is an interesting bug that allows one to exploit a bug in the mod_proxy add on module of Apache HTTP server 2.4.48 and earlier to perform a server side request forgery (SSRF) attack and force the server to make requests on the attacker’s behalf. It was discovered by the Apache HTTP security team whilst analyzing CVE-2021-36160.

This is already being exploited in the wild as noted at with evidence that in at least one case, attackers were able to obtain hash values of user credentials from victim systems via this attack.

There is also evidence that this might affect Cisco products that bundle Apache HTTP Servers with them as noted at however investigation is still ongoing on this matter by Cisco at the time of writing, with the only product confirmed as not being vulnerable listed as Cisco Virtual Topology System.

In general SSRF vulnerabilities are very valuable to attackers as they not only allow access to the internal network of a target, but they can disguise their requests as coming from a legitimate web server that the network trusts. This often means that there is more trust placed in these requests which sometimes means less security checks are placed on them.

It is also important to note that whilst this vulnerability does require the mod_proxy module to be loaded, this is an very common module for most servers and so it is likely to be loaded, increasing the likelihood that an outdated Apache server is vulnerable to this attack.

In short, this bug is being exploited in the wild, allows unauthenticated attackers a way to make trusted requests to internal endpoints, and has been used to steal hashed credentials in a real world attack. Whilst true impact will likely depend on the way the target network is configured and what vulnerabilities are on the systems accessible via the target web server, this vulnerability alone is already providing attackers a lot more insight into a target network through a very common server setup, and therefore should be patched as soon as possible.

Technical Analysis

The patch bypass for this vulnerability is now being exploited in the wild as noted at I have not labeled this bug as exploited in the wild though as the code noted below by @kevthehermit is an exploit for a variant of this bug, not this bug itself, however it is important to note that the bugs are related and no patch exists yet for the variant at the time of writing (November 24th 2021).

Technical Analysis

Bug in Linksys X3000 1.0.03 build 001 currently being exploited in the wild by the BotenaGo botnet which is targeting routers to build its botnet out. Likely trying to use this bug to build a network of zombie routers similar to the Mirai botnet and then use that along with amplification attacks to perform DoS attacks.

More info available at

Technical Analysis

A PoC for this vulnerability is now available at

Technical Analysis

Interesting bug in that this is a high value exploit against Palo Alto Network’s GlobalProtect VPN, which allows unauthenticated attackers to gain root level code execution on target systems. That being said, attackers must have access to the GlobalProtect interface to exploit this issue. However this is just if we consider this bug on its own. They also mention that researchers at Randori managed to find a way to combine this bug with a HTTP Smuggling attack to turn this into a fully working RCE exploit. For this reason I’ve rated this as a 4/5 on value: it does require some additional bugs but its super useful: going from no access on the network to full root level access on a VPN controller is a dream come true for a lot of attackers, particularly when exploitation is meant to be pretty easy.

The technical details mention that this is a classic stack based buffer overflow into a fixed size stack buffer, and that whilst ASLR is present on non-virtualized devices that does make exploitation a bit harder, most virtualized devices do not have ASLR enabled, making exploitation significantly easier. They also mention that they did not yet exploit MIPS based systems due to their big-endian architecture, and although this is likely due more to unfamiliarity than technical complexity, it is something to consider.

I can see this being particularly useful on internal engagements given the supposed relative ease of exploitation, and also by APTs. Widespread exploitation may occur if one can figure out the HTTP Smuggling attack mentioned; once that gets figured out publicly I imagine this will be a ripe target for exploitation given its relative easy and extremely high value.

More details will supposedly be given out by Randori on December 14th, although it is worth noting this bug was patched quite a while ago. See the Twitter thread at and where it was noted that the fixed version was released way back in September 2020 with PanOS 8.1.17. Unfortunately it is a bit hard to note some of this and there has been some confusion due to the release notes not containing full information, and only later being updated to note that this issue was patched within them.

Technical Analysis

This is now being exploited in the wild by the Necro botnet as was reported at

Technical Analysis

This is now being exploited in the wild by the Necro botnet as was reported at

Technical Analysis

Public analysis of this vulnerability is available along with an initial PoC at The bug appears to be a bug in IOMobileFrameBuffer/AppleCLCD which was exploited in the wild. This attack surface is accessible from sandboxes which means that it was likely combined with another vulnerability such as a WebKit vulnerability in the wild to form a complete chain and gain kernel level access. However no information is available from what I can tell on what other vulnerability might have been used in the in the wild exploit chain.

To be more specific the patch appears to affect IOMFB::TableCompensator::BilerpGainTable::new_from_data() and some related new_from_data type functions that attempt to allocate a buffer that is used to store table content sent by the user. However most of the operands are fully controlled by the user and the calculation of the buffer size is done in 32 bit not in 64 bits so it is easy to overflow or underflow the buffer size calculation.

Specifically the vulnerable line within the IOMFB::TableCompensator::BilerpGainTable::new_from_data() function was v_chunk = kalloc_ext((unsigned int)(12 * v15 * v14 + 4 * (v14 + a3))); which appears to be casting a result to a unsigned 32 bit integer, when the variable v14 is of size int64, v15 is a int that is directly controlled by the attacker, and a3 is another int also controlled by the attacker. By passing this line certain sizes an attacker could cause kalloc_ext to allocate a undersized buffer which can then be overflowed when data is later copied to it, resulting in a heap overflow in the iOS kernel, which if successfully exploited, would grant the attacker kernel level privileges.

Whilst there is no full exploit out right now, the common opinion in the community is given the evidence of exploitation in the wild and the fact that an existing PoC already exists, it is likely just a matter of time and researcher’s efforts before this vulnerability is made into a public working exploit by some developer. Definitely patch this one if your organization runs iOS devices or if jailbroken iPhones are a concern to your organization, though realize it will likely take some time before a fully working exploit is released to the public.

Technical Analysis

Exploitation in the wild of this bug has been noted as reported by Google at The bug details are available at but are still classified to the public until more people have patched.

The bug in question is a Use-After-Free vulnerability in the V8 JavaScript rendering engine of Google Chrome prior to 94.0.4606.71. It was reported by an anonymous user on 2021-09-24. Use-After-Free vulnerabilities in V8 are not all that uncommon and are frequently used in the wild to attack Chrome users, as was observed with this particular bug. They often give an attacker access to the user’s desktop considering that the V8 engine is not sandboxed, although according to, there are plans by Google to potentially look at sandboxing the V8 engine in the future.

All in all given the severity of this bug, the lack of sandboxing of the V8 engine, the history of exploitation of V8 bugs in the past giving a rich knowledge base for attackers to work from, and the fact that this bug has been exploited in the wild already, I would highly recommend patching this bug as soon as possible.

If this is not possible then JavaScript should be disabled on all untrusted sites using a plugin such as NoScript or by disabling JavaScript execution within the settings of Chrome itself to avoid exposing oneself to this vulnerability until patches can be deployed.

Technical Analysis

More info will be available at when this bug gets declassified however for now indicates that this is a Medium severity bug caused by an information leak within Core itself. It was discovered by Clément Lecigne from Google TAG, with technical assistance from Sergei Glazunov and Mark Brand from Google Project Zero and was first discovered on 2021-09-21.

The fact that Google TAG discovered this combined with the fact this was exploited in the wild means that its likely Google found this exploit via in the wild exploitation and TAG noticed these exploitation attempts, verified it was a 0day vulnerability, and then notified Google so that they could issue a fix. What is interesting though is that there is no mention of a related 0day exploit that was combined with this vulnerability, which I imagine would be needed in order to make a full exploit.

Most likely this vulnerability would be used to leak information needed for form a full exploit, and would likely be useful for bypassing certain security mitigations that may otherwise prevent the exploit from working normally.

On its own this vulnerability is therefore of Medium to Medium-Low severity, however given its use in exploits in the wild I’d recommend still patching this to make sure that you are protecting your organization against threats that have been proven to have been successfully exploited in real world scenarios. Just be aware that this might sit lower on your priority list than vulnerabilities that can get RCE on their own.

Technical Analysis

Hmm so this is quite an interesting one. This is similar to CVE-2021-36963 and CVE-2021-38633, both of which are marked as low complexity for being exploited and which will likely get you SYSTEM access, however if you look at the advisory for this bug at it is the only one where the “Exploit Code Maturity” is marked as “Functional” in other words Microsoft has verified that code exists to exploit this vulnerability and it works under most scenarios.

Again this is still only local privilege escalation so this isn’t triggerable remotely, hence why the severity is high due to M.S saying this is easy to form an exploit for and the fact that functional exploit code exists according to M.S, however it isn’t Very High since you still need access to an account on the target to exploit this.

Given that this gives SYSTEM level code access and its not hard to make an exploit for it according to Microsoft I would patch this sooner rather than later along with CVE-2021-36963 and CVE-2021-38633. I am still investigating this deeper to figure out what was patched but here is the list of functions within clfs.sys that I believe were patched as part of fixing this bug:

00012	1c00299b4	private: long CClfsBaseFilePersisted::CreateContainer(struct _UNICODE_STRING const &,unsigned __int64 const &,unsigned long,unsigned char,unsigned char,class CClfsContainer * &)	1c0028824	private: long CClfsBaseFilePersisted::CreateContainer(struct _UNICODE_STRING const &,unsigned __int64 const &,unsigned long,unsigned char,unsigned char,class CClfsContainer * &)	0.990	62	61	Perfect match, same name
00013	1c0029d74	public: long CClfsContainer::Create(struct _UNICODE_STRING &,unsigned __int64 const &,struct _CLFS_FILTER_CONTEXT const &,void * const,unsigned char,unsigned char &)	1c0028bdc	public: long CClfsContainer::Create(struct _UNICODE_STRING &,unsigned __int64 const &,struct _CLFS_FILTER_CONTEXT const &,void * const,unsigned char,unsigned char &)	0.950	50	49	Perfect match, same name
00024	1c0031a68	public: long CClfsBaseFile::GetSymbol(long,unsigned char,struct _CLFS_CLIENT_CONTEXT * *)	1c00308c8	public: long CClfsBaseFile::GetSymbol(long,unsigned char,struct _CLFS_CLIENT_CONTEXT * *)	0.950	14	17	Perfect match, same name
00026	1c0032550	ClfsCreateLogFile	1c00313d0	ClfsCreateLogFile	0.910	169	164	Perfect match, same name
00025	1c0032420	public: long CClfsBaseFile::GetSymbol(long,unsigned long,struct _CLFS_CONTAINER_CONTEXT * *)	1c0031290	public: long CClfsBaseFile::GetSymbol(long,unsigned long,struct _CLFS_CONTAINER_CONTEXT * *)	0.870	17	20	Perfect match, same name
00047	1c004f3d8	private: long CClfsBaseFilePersisted::ExtendMetadataBlockDescriptor(unsigned long,unsigned long)	1c004e238	private: long CClfsBaseFilePersisted::ExtendMetadataBlockDescriptor(unsigned long,unsigned long)	0.740	41	46	Perfect match, same name

More details to come when I get the analysis finished some more.

So far that the function Feature_Servicing_2103c_ClfsStatusPrivilegeNotHeld_31093721__private_IsEnabled() was removed from the new build of clfs.sys, and also from the CClfsBaseFilePersisted::CreateContainer call where it was called from. Now it directly checks the return code from CClfsContainer::Create(_UNICODE_STRING &,unsigned __int64 const &,_CLFS_FILTER_CONTEXT const &,void * const,uchar,uchar &) to see if it returned the status code STATUS_PRIVILEGE_NOT_HELD whereas before it would check the return code of Feature_Servicing_2103c_ClfsStatusPrivilegeNotHeld_31093721__private_IsEnabled() for this status.

Technical Analysis

Contrary to what the title says this is not a elevation of privilege vulnerability. As noted at and at this is actually an authentication bypass vulnerability that allows one to bypass the Windows lockscreen by taking advantage of a URL link within the page.

This link appears when one tries to log into an Microsoft connected account and hits the “I Forgot My PIN” link, attempts to sign in to a Microsoft account with an invalid password, hits the back link that appears at the top left of the page, then at the sign on page, hits the question mark icon that appears next to “Sign in with a security key”,

This will display a dialog with the title “Sign in with security key” that has a URL link called “Learn how to set this up”. Clicking on this link after enabling Narrator shows that this link actually opens an “How do you want to open this?” prompt. However this prompt is hidden which is why Narrator is used to tell us which elements we are hovered over.

As mentioned in, this can then be used to open Edge, and then via Edge open the Settings window, at which point we can then open Explorer, and finally open a command window where we can execute arbitrary commands.

The risk of this vulnerability overall is still somewhat low. Due to the number of steps which must be taken using soely Narrator, unless someone automates the key presses (something that is entirely possible) you will still have to do a lot of listening and keypressing to get the vulnerability to work, and any one listening in to you attacking the PC will likely find it rather odd what you are doing.

Additionally you only gain privileges as a local user. This vulnerability does not grant you permissions as a administrative user or any privileged user on the system, and whilst you can use other EOP vulnerabilities that take advantage of the NT AUTHORITY\Authenticated Users the user will be granted, you are still reliant on other EoP vulnerabilities not being patched on the target system for you to get SYSTEM level access.

Overall this is a medium-low severity bug with a high degree of exploitability.

Technical Analysis

So this is a pretty interesting bug in the Linux Kernel from versions 5.7.x to 5.13-rc4. It occurs due to kernel/bpf/verifier.c having a function named adjust_scalar_min_max_vals which is responsible for adjusting the minimum and maximum values an eBPF register can represent, which is used as part of eBPF bounds tracking of registers to make sure that when users submit eBPF programs for the kernel to run, they don’t end up going out of bounds and leaking kernel memory or doing other nasty stuff.

adjust_scalar_min_max_vals has a few switch statements for various types of operations, such as BPF_AND, BPF_OR, BPF_SUB, etc. For the purpose of this we will focus just on the AND vulnerability but the OR vulnerability was also introduced at the same time, and the BPF_XOR vulnerability was introduced with 5.10-rc1 of the Linux kernel.


I have rated the exploitation of this vulnerability as fairly difficult as whilst chompie1337 did push out a PoC for this bug which we have used to transform it into a Metasploit module, and this is fairly platform agnostic, the actual exploitation details involve a lot of fairly advanced concepts and many steps to get successful code execution to work.

That being said the value of this is high as pretty much any Linux system you can think of is going to have eBPF enabled unless they have explicitly disabled it via sudo sysctl kernel.unprivileged_bpf_disabled=1 which will prevent unprivileged users from being able to load eBPF programs. This setting however is not default and will need to be applied to each affected machine so I’d imagine some people will either not be aware of this, or will end up deploying machines and forget that this setting needs to be set at some point, opening up the door for exploitation of this and similar issues.

When executing BPF_AND’s switch code, as can be seen at, Of particular note is the call to scalar32_min_max_and and the lines at

In this case the code will call tnum_subreg_is_const(src_reg->var_off); to check if the source register’s lower 32 bits are known, and tnum_subreg_is_const(dst_reg->var_off); to check if the destination register’s lower 32 bits are known. If both the source register’s lower 32 bits are known and the destination register’s lower 32 bits are known, then it assumes that scalar64_min_max_and will be called (it will) and that its safe to skip updating the registers for the known 32 bit values.

However here lies a problem, as if we look at scalar_min_max_and, which is the official name for scalar64_min_max_and, we see something odd in its code at Specifically it uses tnum_is_const(src_reg->var_off); and tnum_is_const(dst_reg->var_off); to determine if the full contents of the 64 bit source and destination registers are known. Only if the full 64 bit content of the registers are known, does it then mark the destination register as having a known value.

This leads to an edge case where if the operation involves registers where the upper 32 bits are unknown but the lower 32 bits are known, then we can make eBPF improperly verify the register as the 32 bit version of the call will assume the 64 bit version of the call will have properly validated the register’s contents, however in reality the register will not be verified since its upper 32 bits are still unknown.

The patch fixes this by ensuring that scalar32_min_max_and and related affected functions now call __mark_reg32_known on the destination register before returning if the lower 32 bits of the destination and source registers are known. The contents of this function can be seen below:

/* Mark the unknown part of a register (variable offset or scalar  * value) as known to have the value @imm.
static void __mark_reg32_known(struct bpf_reg_state *reg, u64 imm)
    reg->var_off = tnum_const_subreg(reg->var_off, imm);
    reg->s32_min_value = (s32)imm;
    reg->s32_max_value = (s32)imm;
    reg->u32_min_value = (u32)imm;
    reg->u32_max_value = (u32)imm;

Essentially this code will ensure that all the signed and unsigned minimum and maximum versions of the register are properly set, ensuring the correct bounds will be conserved when calling the final boundary updating functions are called to determine the 64 bit value, whereas before when calling the __update_reg_bounds, __reg_deduce_bounds and __reg_bound_offset functions within adjust_scalar_min_max_vals, a condition could occur whereby due to some internal logic on how to calculate these values, there could be a case where the bounds would be incorrectly determined.

More details on exactly how this is done can be found in the The Vulnerability section of chompie1337’s excellent paper at, but suffice to say its possible to make a register with a maximum 32 bit value of 0 and a minimum 32 bit value of 1, thereby severely messing up the logic of the bounds tracker.


Please provide additional information for your rating where possible by adding a comment explaining why you decided to rate this as Medium specifically.


Considering other users considered this to be a higher risk vulnerability, please provide more details on why you think this is a low risk vulnerability for comparison.


Stating its rating (exploitability & attacker value) without providing additional details is not useful to end users. Please provide more details when creating future assessments as I’ve noticed you’ve provided similar one line assessments for at least 2-3 other vulnerabilities as well.


Expanding on this a bit but with it should be noted that heavy exploitation of this vulnerability was noted by CISA in 2020 by APT groups.