among-us-exploit

THE LEGENDARY AMONG US EXPLOIT! This stops extensions from updating.

When does this work? -> When you have code execution inside of an extension -> When the extension is not hosted on the webstore (probably admin-forced)

Unfortunately, this narrows it down to quite a few. One extension that does work is Securly Classroom. GoGuardian also used to work around the time Swamp existed. This exploit is more funny than practical.

Why would you want to stop extension updates? A vulnerability like point-blank allowing for code execution could always be patched by the creators of an extension. If you want it to stay unpatched on your Chromebook, you might want to stop it from updating.

What’s the code? chrome.extension.setUpdateUrlData(‘ඞ’.repeat(1024))

If you were running this code on point-blank, you would add opener. to the start of the function.

EXPLANATION: -> There is a very, VERY rarely seen function called chrome.extension.setUpdateUrlData which is available to extensions not hosted on the web store. -> The idea behind this is that extensions could set some kind of identifying value, then process server-side to decide whether users with a certain value should get a certain update.

-> Anyways, even Mozilla has no clue what it does: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/extension/setUpdateUrlData

-> The best “documentation” that could be found on it was just some Chinese blog post: https://blog.csdn.net/weixin_30770783/article/details/96541549 -> Using chrome://net-export, this blog post was confirmed to be correct.

So what is happening with this function?

-> Well, when extensions have to update, they use the URL defined in their manifest (chrome.runtime.getManifest().update_url). -> For GoGuardian, for example, this is: https://ext.goguardian.com/stable.xml

-> But Chrome adds parameters to this, so it becomes something like this: https://ext.goguardian.com/stable.xml?response=redirect&os=cros&arch=x86-64&os_arch=x86-64&nacl_arch=x86-64&prod=chromiumcrx&prodchannel=unknown&prodversion=105.0.0.0 -> Anyways, the setUpdateUrlData function adds a parameter called ap to the URL with the value you specify: https://ext.goguardian.com/stable.xml?response=redirect…&ap=[FUNCTION ARGUMENT]

-> The first question an exploit-finder would ask with this knowledge is “Can you overload the update url server?”

-> And the answer you get is seemingly no, since the function accepts a maximum of 1024 characters and GoGuardian’s CRX server can handle this just fine. But there’s an issue with Chrome’s logic. -> They used the javascript .length property to determine the length of the value passed into the function, while the data is actually sent through a URL, which means it will be URL-encoded.

-> There are plenty of obscure Unicode characters such as “ඞ” (U+0D9E). This is one of the many characters that shows a length of 1 in JavaScript, but when URL-encoded turns into a whopping 9 characters (%E0%B6%9E). -> This means we’re actually sending 9216 characters to the server, which is more than enough to crash GoGuardian’s and probably 99% of other CRX-hosting servers. So yes, this among us exploit is actually practical!

-> Thus, the server returns an error, “Too big request header”, and Chrome is never able to determine whether the extension can be updated or not. -> This means the extension will never update, as this AP parameter persists through pretty much everything you do. So there you have it.

Credits: Bypassi Titanium Network