How i found a 1500$ worth Deserialization vulnerability

4 min readAug 28, 2018

Note before you start.
This is not a so called “great writeup”. I m writing this because many of you were In-boxing/messaging me for writeup ,so here it is .

SO i m gonna start this writeup as a story .

This was about 7:00 PM and last day of my broadband service expiry date, so i thought why not hunt for vulnerabilities and eat every bit of the remaining data.

I logged in my bugcrowd account.

and was thinking

and going through some programs , i got my eye on a program which is ******(private, so can’t name it) , lets call it “Redacted.com” and was less tested .

so i looked into its scope, and turn to be only one scope and other one is redirecting me to main domain.

There was a login page, simple and classy look.

I looked at my “Wappalyzer addon” and all i can see is a

javascript framework : Prototype 1.6.1

which remind me of jboss… (which i ignored for no reason)

Also i tried registering it but you have to wait for the backend team to review and approve that, so without thinking i fired “burp suite”

and was playing with login and i saw this in the request

<input type=”hidden” name=”javax.faces.ViewState” id=” javax.faces.ViewState”" value=”rO0ABXVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAAAAAJwdAAML2xvZ2luLnhodG1s…………..<snipt>” autocomplete=”off” />

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

UPDATED

If the captured traffic data include the following patterns may suggest that the data was sent in Java serialization streams

“AC ED 00 05” in Hex
“rO0” in Base64
Content-type = ‘application/x-java-serialized-object

i found a another deserialization vuln. , this one is was encoded in gzip(base64) , it somewhat starts with

“H4sIAAAAAAAAAJ”

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

well, this cleared my doubt , the website is using Java Server Faces (JSF)

and i was like Hmmm…..

next step was testing the Hidden value which was encoded in base64 and on decoding it i found the Serialized java values and were not even encrypted .

which on digging more i found this information for those who don’t know .

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.

Now,