Summary

I did some research on 0x33c0unt - GHSA-2hqv-2xv4-5h5w and found that the latest version of apktool still has directory traversal on windows on windows.

Because there is path compatibility in windows and this is ignored in the code filtering

so,apktool infers resource files' output path according to their resource names which can be manipulated by attacker to place files at desired location on the windows Apktool runs on

Details

• Apktool infers resource files' output path according to their resource names ([output-dir]/res/[type]/[resource-name]+[ext of (resource-file)] )

• E.g. a resource named "foo" with path of "res/raw/bar", is extracted to res/raw/foo

The previous security guard code was

public static boolean detectPossibleDirectoryTraversal(String entry) {
      if (OSDetection.isWindows()) {
          return entry.contains("..\\") || entry.contains("\\..");
      }
      return entry.contains("../") || entry.contains("/..");
  }

We start by constructing an APK that creates the corresponding /res/raw/aaaaaaaaaaaaa

Generate the APK and then modify it to ../../../poc

Interesting chemistry on top of windows

PoC

use apktool 2.9.2
use windows 11

The poc file escaped because of the path characteristics of windows , the apktool problem still exists!

Impact

As before, exploitation on windows requires an attacker's imagination.

other

A ../../../poc constructed on windows won't go into BrutIO.detectPossibleDirectoryTraversal func

and the filtering rules that I feel need to be tightened up in this section

return entry.contains("../") || entry.contains("/..") || entry.contains("..\\") || entry.contains("\\..");