De-serialization vulnerability in 3rd Party Library to RCE — MobileHackingLab(Android) ‘Config Editor’ Write-up

Ajmal Moochingal
4 min readJan 17, 2024

--

Exploiting De-serialization vulnerability in a 3rd party Android library leading to RCE.

Random image — generated by DALL-E

This post contains the solution to the lab challenge. If you’d like to try the lab first, try it over here : https://www.mobilehackinglab.com/course/lab-config-editor-rce

Objective

The challenge objective clearly says the following :

‘Successfully execute remote code through the exploitation of a vulnerability in a third-party library’

Got to look into the app for further analysis.

Discovering the Vulnerability

I tried running the app first, it look like a yaml parser.

I looked into the manifest file if there’s anything interesting.

The app just have different schemes registered for opening a yaml file datatype. The registered intent would allow the yaml parsing to be invoked through an intent call. The challenge hint says to look for a 3rd party library. Not sure if this is a Java dependency itself, or a native library.

I came across a java library called snakeyaml in the format of a usual Android Java dependency. Inspecting MainActivity.java it look like this library is the one which parses yaml. I searched on Google for any potential exploitable vulnerabilities. CVE-2022-1471 - De-serialization of untrusted data leading to RCE. Looks like the one which we would want in the challenge.

I attempted to find the version of snakeyaml in the APK, but did not succeed. So I decided to try the PoC for CVE-2022–1471 which I found on github. https://github.com/1fabunicorn/SnakeYAML-CVE-2022-1471-POC

As per the PoC, the above yaml if opened should trigger a HTTP request to http://192.168.0.102:8000 . But nothing happened. I looked into logcat and found the following error:

exception=Class not found: javax.ScriptEnginemanager - this look like the De-serialization is indeed working but javax.ScriptEnginemanager class may not be accessible by default by Android apps 🤔

I spent some good time searching for possible gadgets to get Code execution. But didn’t find anything useful. Later I decided to take one more look in the decompiled code and I found this : LegacyCommandUtil.java

So, the challenge author have created a Util Class for making it easier to executing commands. All I need to do now is invoke this class’ constructor.

I opened the above yaml file. App did not throw any error this time.

The app’s data folder — /data/data/com.mobilehackinglab.configeditor/ has become world readable & writable which means the exploit worked.

Final Thoughts

According to Marshalsec’s research, snakeyml’s De-serialization vulnerability is capable of invoking Java constructors easily. A documented attack vector is through using ScriptEngine for downloading and executing jar file with the payload.

Since ScriptEngine is not available in Android by default, what gadget could be used to convert De-serialization to a code execution is an interesting problem 🤔 . In the lab challenge it was straight forward because of the embedded command execution util.

Reference:

  1. SnakeYAML CVE-2022–1471 PoC — https://github.com/1fabunicorn/SnakeYAML-CVE-2022-1471-POC
  2. Research by Marshalsec on different possible Java De-serialization vulnerabilities : https://github.com/mbechler/marshalsec/blob/master/marshalsec.pdf

--

--