Category Archives: Bugs

This is another bug which i’ve found long ago while i was bored.
This could be a problem for IZArc users if they were targeted. If not, it’s not really serious.
I had written it previously in my old blog but i’m slowing moving some of the stuff over as i’m discontinuing the other blog.

[ Summary: ]
This article is on the following bug found in IZArc v4.1.8 – v4.1.9,
The bug had been assigned the CVE identifier CVE-2014-2720.

[ Details: ]
I’ve created a zip file using WinRar containing putty.exe.
I’ve changed the filename at offset 0x460AE to putty.jpg as shown in the image below.

When i am modifying the offset at 0x460AE, I am basically modifying the Central Directory entry.
This is done so that it will appear on IZArc as “putty.jpg” instead of “putty.exe”.

Opening the newly modified zip file in IZArc version 4.1.9, we will see something like this.

This seems like a “File extension spoofing”.
While after decompression the user will get the real file name, putty.exe.
However, if the user double click “putty.jpg” instead. “putty.exe will execute as an application instead of executing using user’s imager viewer.

However if attackers were to use RTLO (Right to Left Order) in unicode: U+202E.
So, U+202E converts to 0xE280AE.
With a simple RTLO, we can reverse the right side of the filename, so “puttygnp.exe” looks like “puttyexe.png”.

This will pose a problem to all users of IZArc.
To date, according to download.com by CNET. IZArc had 2,153,572 downloads.

To make this a more comprehensive blog entry, the following are the tests which i did during this bug finding process.
It may be useful to list all of the different cases and their security properties.

This is a valid spoofing attack. However, it is exactly the same
problem as test case 1. The attack methodology (using a “graphics image” file extension in the Central Directory entry) is the same.
The only part that is different is the real filename in the original unmodified ZIP file.

The people at mitre.org had been patient with me and very helpful while i am reporting this bug.
Probably other file archive tools have similar problems as well.
I’ve attached the files for Test Cases 1,3 & 5 for reference.IZArc_POC

This is just a simple vulnerability research advisory where i talk on ALZip for Android ZIP Archive Extraction Directory Traversal & Local File Inclusion Vulnerability.
Since vendor don’t want to reply me for 3 months and i personally don’t think it’s severe.
Here goes…

[ Summary: ]
An archive extraction directory traversal vulnerability has been found in ALZip for Android.
When exploited, this vulnerability allows an anonymous attacker to write files to arbitrary locations within the SD card of the user’s Android device.

[ Details: ]
This advisory discloses an archive extraction directory traversal vulnerability in ALZip for Android.
When exploited, this vulnerability allows an anonymous attacker to write files to arbitrary locations within the SD card of the user’s Android device.

When extacting compressed files from an archive, the extraction functionality does not properly sanitise compressed files that have directory traversal sequences in their filenames.
By tricking a user to extract a specially crafted archive containing files with directory traversal sequences in their filenames, an attacker can write files to arbitrary locations within the SD card of the user’s Android device, possibly overwriting the user’s existing files.

For example, a malicious archive can contain a compressed file with the following filename:

IMPORTANT: Ensure that the /storage/sdcard0/Download/ directory exists on your Android device in order for the POC to work.
Extract the POC ZIP archive into the /storage/sdcard0/Download/ directory. i.e. tap and hold on to the POC ZIP file until the action selection pop-up appears, then select the “Extract” option.

Finally select “Extract here” option

When the extraction completes, navigate to the /storage/sdcard0/ directory. You’ll notice that pwnies.txt has been extracted into /storage/sdcard0/pwnies.txt instead of into /storage/sdcard0/Download/pwnies/pwniestxt.

Hence, by tricking a user to extract or download a specially-crafted archive, an attacker can potentially exploit this issue to write files into arbitrary locations within the SD card in the user’s Android device, or to overwrite files in known locations within the SD card.

For example, an attacker who is aware of the filenames of the user’s photo in the /storage/sdcard0/ directory can exploit this vulnerability to overwrite the user’s photo files.
But i doubt anyone knows the filenames.

Another bug was found manually via reversing the application and in the same time via Drozer due to exposed content provider.
But for simplicity sake, i will write about the method using Drozer
So what this means is that you can read the contents of any file in the victim(s)’ Android device if you got a specially crafted apk that abuses the exported content provider of ALZip.

The reason for this bug is that you expose the content provider.
A content provider can provide access to the underlying file system.
This allows apps to share files, where the Android Sandbox would otherwise prevent it.
Since we can reasonably assume that “files” is a file system backed content provider and that the path component represents the location of the file that we want to open.

So in drozer if you run the following command.

Shell

1

run app.provider.readcontent://com.estsoft.alzip.files/../../../../../../../../etc/hosts

You will get back the contents of /etc/hosts

But this particular bug is not critical since /etc/hosts is world readable anyway.
It’s only serious if your app stores critical info about user or have a SQLite database.

[ POC/Test Code: ]
You can download the PoC here and follow the instructions as described in this blog post..