Popular JWT cloud security library patches “remote” code execution hole

Popular JWT cloud security library patches “remote” code execution hole

Original text by Paul Ducklin

JWT is short for JSON Web Token, where JSON itself is short for JavaScript Object Notation.

JSON is a modernish way of representing structured data; its format is a bit like XML, and can often be used instead, but without all the opening-and-closing angle brackets to get in the way of legibility.

For example, data that might be recorded like this in XML…

<?xml version="1.0" encoding="UTF-8"?>
<data>
   <name>Duck</name>
   <job>
      <employer>Sophos</employer>
      <role>NakSec</role>
   </job>
</data>

…might come out like this in JSON:

{"name":"Duck","job":{"employer":"Sophos","role":"NakSec"}}

Whether the JSON really is easier to read than the XML is an open question, but the big idea of JSON is that because the data is encoded as legal JavaScript source, albeit without any directly or indirectly executable code in it, you can parse and process it using your existing JavaScript engine, like this:

The output string undefined above merely reflects the fact that console.log() is a procedure – a function that does some work but doesn’t return a value. The word Sophos is printed out as a side-effect of calling the function, while undefined denotes what the function calculated and sent back: nothing.

The popularity of JavaScript for both in-browser and server-side programming, plus the visual familiarity of JSON to JavaScript coders, means that JSON is widely used these days, especially when exchanging structured data between web clients and servers.

And one popular use of JSON is the JWT system, which isn’t (officially, at any rate) read aloud as juh-witt, as it is written, but peculiarly pronounced jot, an English word that is sometimes used to refer the little dot we write above above an 

i
 or 
j
, and that refers to a tiny but potentially important detail.

Authenticate strongly, then get a temporary token

Loosely speaking, a JWT is a blob of encoded data that is used by many cloud servers as a service access token.

The idea is that you start by proving your identity to the service, for example by providing a username, password and 2FA code, and you get back a JWT.

The JWT sent back to you is a blob of base64-encoded (actually, URL64-encoded) data that includes three fields:

  • Which crytographic algorithm was used in constructing the JWT.
  • What sort of access the JWT grants, and for how long.
  • A keyed cryptographic hash of the first two fields, using a secret key known only to your service provider.

Once you’ve authenticated up front, you can make subsequent requests to the online service, for example to check a product price or to look up an email address in a database, simply by including the JWT in each request, using it as a sort-of temporary access card.

Clearly, if someone steals your JWT after it’s been issued, they can play it back to the relevant server, which will typically give them access instead of you…

…but JWTs don’t need to be saved to disk, usually have a limited lifetime, and are sent and received over HTTPS connections, so that they can’t (in theory at least) easily be sniffed out or stolen.

When JWTs expire, or if they are cancelled for security reasons by the server, you need to go through the full-blown authentication process again in order to re-establish your right to access the service.

But for as long they’re valid, JWTs improve performance because they avoid the need to reauthenticate fully for every online request you want to make – rather like session cookies that are set in your browser while you’re logged into a social network or a news site.

Security validation as infiltration

Well, cybersecurity news today is full of a revelation by researchers at Palo Alto that we’ve variously seen described as a “high-severity flaw” or a “critical security flaw” in a popular JWT implementation.

In theory, at least, this bug could be exploited by cybercriminals for attacks ranging from implanting unauthorised files onto a JWT server, thus maliciously modifying its configuration or modifying the code it might later use, to direct and immediate code execution inside a victim’s network.

Simply put, the act of presenting a JWT to a back-end server for validation – something that typically happens at every API call (jargon for making a service request) – could lead malware being implanted.

But here’s the good news:

  • The flaw isn’t intrinsic to the JWT protocol. It applies to a specific implementation of JWT called 
    jsonwebtoken
     from a group called Auth0.
  • The bug was patched three weeks ago. If you’ve updated your version of 
    jsonwebtoken
     from 8.5.1 or earlier to version 9.0.0, which came out on 2022-12-21, you’re now protected from this particular vulnerability.
  • Cybercriminals can’t directly exploit the bug simply by logging in and making API calls. As far as we can see, although an attacker could subsequently trigger the vulnerability by making remote API requests, the bug needs to be “primed” first by deliberately writing a booby-trapped secret key into your authentication server’s key-store.

According to the researchers, the bug existed in the part of Auth0’s code that validated incoming JWTs against the secret key stored centrally for that user.

As mentioned above, the JWT itself consists of two fields of data denoting your access privileges, and a third field consisting of the first two fields hashed using a secret key known only to the service you’re calling.

To validate the token, the server needs to recalculate the keyed hash of those first two JWT fields, and to confirm the hash that you presented matches the hash it just calculated.

Given that you don’t know the secret key, but you can present a hash that was computed recently using that key…

…the server can infer that you must have acquired the hash from the authentication server in the first place, by proving your identity up front in some suitable way.

Data type confusion

It turns out that the hash validation code in 

jsonwebtoken
 assumes (or, until recently, assumed) that the secret key for your account in the server’s own authentication key-store really was a cryptographic secret key, encoded in a standard text-based format such as PEM (short for privacy enhanced mail, but mainly used for non-email purposes these days).

If you could somehow corrupt a user’s secret key by replacing it with data that wasn’t in PEM format, but that was, in fact, some other more complex sort of JavaScript data object…

…then you could booby-trap the secret-key-based hash validation calculation by tricking the authentication server into running some JavaScript code of your choice from that infiltrated “fake key”.

Simply put, the server would try to decode a secret key that it assumed was in a format it could handle safely, even if the key wasn’t in a safe format and the server couldn’t deal with it securely.

Note, however, that you’d pretty much need to hack into the secret key-store database first, before any sort of truly remote code execution trigger would be possible.

And if attackers are already able to wander around your network to the point that they can not only poke their noses into but also modify your JWT secret-key database, you’ve probably got bigger problems than CVE-2022-23539, as this bug has been designated.

What to do?

If you’re using an affected version of 

jsonwebtoken
update to version 9.0.0 to leave this bug behind.

However, if you’ve now patched but you think crooks might realistically have been able to pull off this sort of JWT attack on your network, patching alone isn’t enough.

In other words, if you think you might have been at risk here, don’t just patch and move on.

Use threat detection and response techniques to look for holes by which cybercriminals could get far enough to attack your network more generally…

…and make sure you don’t have crooks in your network anyway, even after applying the patch.

Remote code execution bug discovered in the popular JsonWebToken library

Remote code execution bug discovered in the popular JsonWebToken library

Original text by Pierluigi Paganini

The open-source jsonwebtoken (JWT) library is affected by a high-severity security flaw that could lead to remote code execution.

The open-source JsonWebToken (JWT) library is affected by a high-severity security flaw, tracked as CVE-2022-23529 (CVSS score: 7.6), that could lead to remote code execution.

The package is maintained by Auth0, it had over 9 million weekly downloads as of January 2022 and it is used by more than 22.000 projects.

The flaw was discovered by Unit 42 researchers, it can be exploited by threat actors by tricking a server into verifying a maliciously crafted JSON web token (JWT) request. 

“By exploiting this vulnerability, attackers could achieve remote code execution (RCE) on a server verifying a maliciously crafted JSON web token (JWT) request.” reads the advisory published by Palo Alto Networks. “With that being said, in order to exploit the vulnerability described in this post and control the secretOrPublicKey value, an attacker will need to exploit a flaw within the secret management process.”

JsonWebToken is an open-source JavaScript package that allows users to verify/sign JSON web tokens (JWT). 

The flaw impacts JsonWebToken package version 8.5.1 or an earlier version, the JsonWebToken package version 9.0.0 addressed the issue.

“For versions <=8.5.1 of jsonwebtoken library, if a malicious actor has the ability to modify the key retrieval parameter (referring to the secretOrPublicKey argument from the readme link) of the jwt.verify() function, they can gain remote code execution (RCE).” reads the advisory published on GitHub. “You are affected only if you allow untrusted entities to modify the key retrieval parameter of the jwt.verify() on a host that you control.”

Vulnerabilities in open-source projects are very dangerous, threat actors could exploit them as part of supply chain attacks that can impact any projects relying on them.

“Open source projects are commonly used as the backbone of many services and platforms today. This is also true for the implementation of sensitive security mechanisms such as JWTs, which play a huge role in authentication and authorization processes.” concludes Palo Alto. “Security awareness is crucial when using open source software. Reviewing commonly used security open source implementations is necessary for maintaining their dependability, and it’s something the open source community can take part in.”

Below is the timeline for this vulnerability:

  • July 13, 2022 – Unit 42 researchers sent a disclosure to the Auth0 team under responsible disclosure procedures
  • July 27, 2022 – Auth0 team updated that the issue was under review
  • Aug. 23, 2022 – Unit 42 researchers sent an update request
  • Aug. 24, 2022 – Auth0 team updated that the engineering team was working on the resolution
  • Dec. 21, 2022 – A patch was provided by the Auth0 engineering team

CVE-2022-36923 ManageEngine OpManager getUserAPIKey Authentication Bypass

CVE-2022-36923 Detail

origianl text by 4er 

Intro:

ManageEngine offers enterprise IT management software for your service management, operations management, Active Directory and security needs.

CVE-2022-36923 ManageEngine OpManager getUserAPIKey Authentication Bypass
CVE-2022-35405 Zoho Password Manager Pro XML-RPC RCE
CVE-2022-28219 Zoho ManageEngine ADAudit Plus XXE to RCE
CVE-2021-44077 Zoho ManageEngine ServiceDesk Plus Pre-Auth RCE
CVE-2020-10189 Zoho ManageEngine Desktop Central deserialize RCE

According to ZDI’s announcement , the vulnerability exists


<strong>com.adventnet.me.opmanager.server.util.RMMUtil#getUserAPIKey</strong>

The key point is how to get to this position.

Search the xml configuration file to find

The route is 

/RestAPI/getAPIKey
, try to construct the request packet

Prompt missing parameters, see the log to report an error

The IAMSecurityException breakpoint hits its constructor and traces back up, and finally 

com.adventnet.iam.security.ParameterRule#checkForAllowedValueRegex
found that an exception was thrown because the parameter regular matching was incorrect.

The final construction parameter successfully returns 200

look back now

<strong>com.adventnet.me.opmanager.server.util.RMMUtil#getUserAPIKey</strong>


    public String getUserAPIKey(HttpServletRequest request, HttpServletResponse response) throws IOException {
        String userName = request.getParameter("username");
        String domainName = request.getParameter("domainname");
        if (userName != null &amp;&amp; domainName != null) {
            try {
                Long userId = MickeyLiteUtil.getUserId(userName, domainName);
                String apiKey = (new APIKeyGenerator()).checkAndGenerateApiKey(userId, -1L);
                response.setContentType("text/plain");
                PrintWriter out = response.getWriter();
                out.println(apiKey);
                out.flush();
                return null;
            } catch (Exception var8) {
                var8.printStackTrace();
                return null;
            }
        } else {
            return null;
        }
    }

MickeyLiteUtil.getUserId()

You need to give a correct domainName, it depends on what value is in the AaaLogin table in the database.

View database jdbc link

<strong>C:\Program Files\ManageEngine\OpManager\conf\database_params.conf</strong>

The password is encrypted and found in the bin directory

<strong>bin\encrypt.bat</strong>


call .\setCommonEnv.bat

set CLASS_PATH="%SERVER_HOME%\lib\framework-tools.jar"

IF "%1"=="" GOTO SHOW_SYNTAX

"%JAVA%"  -Dserver.home="%SERVER_HOME%" -cp %CLASS_PATH% com.zoho.framework.utils.crypto.CryptoUtil %*
GOTO END_ENCRYPT

:SHOW_SYNTAX
"%JAVA%" -Dserver.home="%SERVER_HOME%" -cp %CLASS_PATH% com.zoho.framework.utils.crypto.CryptoUtil "showUsage"

:END_ENCRYPT

Call the CryptoUtil class for encryption

Write a class directly to call the decrypt function

cryptTag is 

<strong>EnDecryptUtil.getCryptTag()</strong>
obtained by

Parse the persistence-configurations.xml file to get the CryptTag attribute and view the file content

Attempt to 

<strong>MLITE_ENCRYPT_DECRYPT</strong>
decrypt unsuccessfully, and then found that an external entity was introduced at the top of the xml file

Finally 

<strong>conf\customer-config.xml</strong>
found the CryptTag in the file

The algorithm is AES256. After decryption, link to the database and check the AaaLogin table.

The domainName is obtained 

<strong>-</strong>
, and the final request package is as follows

Get restapi from this

The rce method looked at the restapi documentation. There is a workflow that can be used for rce, but there is a problem with accessing through restapi.

<strong>OpManagerServerClasses.jar!/com/adventnet/me/opmanager/server/api/OpManagerAPIServlet.class:354</strong>

If your api is 

<strong>APIUtil.getInstance().isInternalAPI()</strong>
an internal api, the isAPIClient in the session will only be assigned when you log in, so this place isApiclient is false, and NmsUtil.isRMMEdition is false, causing an exception to be thrown 
APIError.internalAPI(request, response)
then all internal apis cannot be called.

The 

conf\OpManager\do\RestApi.xml
key APIs that define the workflow are 
<strong><em>EXPOSED_API=TRUE</em></strong>
the internal APIs.

At this point, the rce is broken. I traced back the 

isInternalAPI()
function and found that all the APIs are in the database 
<strong><em>OpManagerDB.public.restapioperation</em></strong>
table. After filtering 
<strong>exposed_api='true'</strong>
, a total of 955 APIs can be accessed through restapi.

I looked at it and saw that nothing was added, deleted, modified, and checked. I hope someone who is destined can dig out a rce.

Replenish

My colleague looked at the cve injected by the other two commands of opmanager and found that it should be possible to string rce together. see colleagues’ articles

ZOHO ManageEngine OpManager Two RCEs

The writing is rubbish, the wording is frivolous, the content is simple, and the operation is unfamiliar. The deficiencies are welcome to give pointers and corrections from the masters, and I am grateful.


CVE-2022-36923 Detail

Current Description

Zoho ManageEngine OpManager, OpManager Plus, OpManager MSP, Network Configuration Manager, NetFlow Analyzer, Firewall Analyzer, and OpUtils before 2022-07-27 through 2022-07-28 (125657, 126002, 126104, and 126118) allow unauthenticated attackers to obtain a user’s API key, and then access external APIs.


Zoho ManageEngine OpManager, OpManager Plus, OpManager MSP, Network Configuration Manager, NetFlow Analyzer, Firewall Analyzer, and OpUtils before 2022-07-27 through 2022-07-28 (125657, 126002, 126104, and 126118) allow unauthenticated attackers to obtain a user’s API key, and then access external APIs.

Y4er

Zyxel addressed a critical RCE flaw in its NAS devices

mportant RCE Vulnerability Impacts Zyxel NAS Units — Firmware Patch Launched

original text by Pierluigi Paganini

Networking equipment vendor Zyxel addressed a critical vulnerability impacting its network-attached storage (NAS) devices.

Zyxel addressed a critical vulnerability, tracked as CVE-2022-34747, impacting its network-attached storage (NAS) devices.

The CVE-2022-34747 (CVSS score: 9.8) flaw is classified as a format string vulnerability that resides in Zyxel NAS326 firmware versions prior to V5.21(AAZF.12)C0. An attacker can exploit the vulnerability to achieve unauthorized remote code execution via a crafted UDP packet.

“A format string vulnerability was found in a specific binary of Zyxel NAS products that could allow an attacker to achieve unauthorized remote code execution via a crafted UDP packet.” reads the advisory published by the vendor.

Below is the list of affected models and the firmware patches released by the company.

AFFECTED MODELAFFECTED VERSIONPATCH AVAILABILITY
NAS326V5.21(AAZF.11)C0 and earlierV5.21(AAZF.12)C0
NAS540V5.21(AATB.8)C0 and earlierV5.21(AATB.9)C0
NAS542V5.21(ABAG.8)C0 and earlierV5.21(ABAG.9)C0

The vulnerability was reported to Zyxel by Shaposhnikov Ilya.

In May 2022, Zyxel released security updates to address multiple vulnerabilities affecting multiple products, including firewall, AP, and AP controller products.

Below is the list of the four vulnerabilities, the most severe one is a command injection flaw in some CLI commands tracked as CVE-2022-26532 (CVSS v3.1 7.8):

  • CVE-2022-0734: A cross-site scripting vulnerability was identified in the CGI program of some firewall versions that could allow an attacker to obtain some information stored in the user’s browser, such as cookies or session tokens, via a malicious script.
  • CVE-2022-26531: Multiple improper input validation flaws were identified in some CLI commands of some firewall, AP controller, and AP versions that could allow a local authenticated attacker to cause a buffer overflow or a system crash via a crafted payload.
  • CVE-2022-26532: A command injection vulnerability in the “packet-trace” CLI command of some firewall, AP controller, and AP versions could allow a local authenticated attacker to execute arbitrary OS commands by including crafted arguments to the command.
  • CVE-2022-0910: An authentication bypass vulnerability caused by the lack of a proper access control mechanism has been found in the CGI program of some firewall versions. The flaw could allow an attacker to downgrade from two-factor authentication to one-factor authentication via an IPsec VPN client.

Networking device maker Zyxel is warning customers today of a new critical remote code execution (RCE) vulnerability impacting three models of its Networked Attached Storage (NAS) products.

The vulnerability is tracked as CVE-2022-34747 and has received a CVSS v3 severity score of 9.8, rated critical, but not many details have been disclosed.

“A format string vulnerability was found in a specific binary of Zyxel NAS products that could allow an attacker to achieve unauthorized remote code execution via a crafted UDP packet,” explains the advisory.

Security researcher Shaposhnikov Ilya discovered the vulnerability on June 2022. As a result, Zyxel gradually released security updates for the impacted models over the following months.

The NAS devices vulnerable to this flaw are NAS326, NAS540, and NAS542, all still within their active support period.

The vulnerable firmware versions are V5.21(AAZF.11)C0 and earlier for NAS326, V5.21(AATB.8)C0 and earlier for NAS540, and V5.21(AATB.8)C0 or older for NAS542.

The vendor has already released security updates for the impacted devices in the form of firmware updates, with links to the downloads in the security advisory.

Alternatively, you can visit Zyxel’s official download portal, enter your device model, and download the latest firmware update listed in the results.

Remote code execution flaws allow many different attacks, including bypassing the need for user authentication, elevation of privilege, or any other limiting prerequisite.

The vulnerability could be abused to steal data, delete data, or deploy ransomware on Internet-exposed NAS devices.

While all scenarios are dire, ransomware is the most common, as it gives the threat actors the best way to monetize a successful attack.

Only yesterday, we reported that QNAP patched a zero-day vulnerability over the weekend that was used in a new wave of DeadBolt ransomware attacks.

In February, the same group also targeted ASUSTOR devices by leveraging an exploit for a previously unknown flaw. 

Thus, DeadBolt is competent enough to find undocumented security gaps, let alone exploit known vulnerabilities.

Other ransomware gangs actively targeting NAS devices are Checkmate and eChoraix, both very active in 2022.

QNAP is warning customers of ongoing DeadBolt ransomware attacks that started on Saturday by exploiting a zero-day vulnerability in Photo Station.

The company has patched the security flaw but attacks continue today.

«QNAP® Systems, Inc. today detected the security threat DEADBOLT leveraging exploitation of Photo Station vulnerability to encrypt QNAP NAS that are directly connected to the Internet,» explains the security notice.

The attacks were widespread, with the ID Ransomware service seeing a surge in submissions on Saturday and Sunday.

A surge in DeadBolt submissions to ID Ransomware
Source: BleepingComputer

QNAP releases patches for a zero-day flaw

QNAP released Photo Station security updates 12 hours after DeadBolt began using the zero-day vulnerability in attacks, urging NAS customers to immediately update Photo Station to the newest version.

The following security updates fix the vulnerability:

  • QTS 5.0.1: Photo Station 6.1.2 and later
  • QTS 5.0.0/4.5.x: Photo Station 6.0.22 and later
  • QTS 4.3.6: Photo Station 5.7.18 and later
  • QTS 4.3.3: Photo Station 5.4.15 and later
  • QTS 4.2.6: Photo Station 5.2.14 and later

Alternatively, QNAP suggests users replace Photo Station with QuMagie, a safer photo storage management tool for QNAP NAS devices.


“We strongly urge that their QNAP NAS should not be directly connected to the internet. We recommend users to make use of the myQNAPcloud Link feature provided by QNAP, or enable the VPN service.” - QNAP.

Applying the security updates will prevent the DeadBolt ransomware and other threat actors from exploiting the vulnerability and encrypting devices. However, NAS devices should never be publicly exposed to the Internet and instead placed behind a firewall.

QNAP customers can find detailed instructions on applying the available updates and setting up myQNAPcloud in the security advisory.

Finally, it is recommended to use strong passwords on all NAS user accounts and take regular snapshots to prevent data loss in the case of attacks.

DeadBolt: the NAS ransomware bane

The DeadBolt ransomware gang has been targeting NAS devices since January 2022, using an alleged zero-day vulnerability on Internet-exposed NAS devices.

The ransomware operation conducted further attacks on QNAP devices in May and June 2022.

DeadBolt ransom notes
Source: BleepingComputer

Earlier in February, DeadBolt began targeting ASUSTOR NAS devices using a zero-day vulnerability they attempted to sell to the vendor for 7.5 Bitcoin.

In most of these attacks, DeadBolt demanded a payment of just over a thousand USD from impacted users in exchange for a working decryptor.

However, other NAS ransomware groups demand more significant amounts from their victims.

The Checkmate ransomware targeted QNAP NAS products in July, demanding victims pay $15,000.