Category Archives: Bugs

[ VXSecurity.sg Vulnerability Research Advisory : IZArc file extension spoofing ]

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.

[ Tested Versions: ]
IZArc version 4.1.8 – 4.1.9

[ Tools Used: ]
HexEdit

[ 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.
izarc.0x01

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.
izarc.0x02

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.
izarc.0x03

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.

Test Case 1:
============

Central Directory entry filename = putty.jpg
Local file header filename = putty.exe
File content = Microsoft EXE format
The user sees: putty.jpg
If the user clicks: putty.exe is executed

Test Case 2:
============

Central Directory entry filename = putty.jpg
Local file header filename = putty.jpg
File content = Microsoft EXE format
The user sees: putty.jpg
If the user clicks, user’s default JPEG viewer is launched instead.
This is safe behavior.

Test Case 3:
============

Central Directory entry filename = putty\xE2\x80\xAEexe.png
Local file header filename = putty\xE2\x80\xAEexe.png
File content = Microsoft EXE format
The user sees: puttygnp.exe
If the user clicks, puttygnp.exe is executed
This is normal behavior as user will see that this is an executable.

Test Case 4:
============

Central Directory entry filename = puttyexe.png
Local file header filename = putty\xE2\x80\xAEexe.png
File content = Microsoft EXE format
The user sees: puttyexe.png
If the user clicks, puttygnp.exe is executed

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.

Test Case 5:
============

Central Directory entry filename = putty\xE2\x80\xAEgnp.exe
Local file header filename = puttygnp.exe
File content = Microsoft EXE format
The user sees: puttyexe.png
If the user clicks, puttygnp.exe is executed

This is also same as test case 1.

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

Below is the timeline of my disclosure.

Timeline:
=========

Date Discovered: 24 March 2014 – Vulnerability Discovered.
Vendor notified: 24 March 2014 – Initial Vendor Notification, no reply.
Vendor notified: 01 April 2014 – Second Vendor Notification, no reply.
Advisory posted: 05 May 2014 – No response from Vendor, published.
Version checked: 30 July 2015 – Bug still exists in new version

Thanks & Regards
Jacob Soo

[ VXSecurity.sg Vulnerability Research Advisory : ALZip for Android ZIP Archive Extraction Directory Traversal & Local File Inclusion Vulnerability ]

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.

[ Tested Versions: ]
ALZip Android Version 1.0.21 – 1.0.22

[ Tools Used: ]
Drozer

[ 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:

[ PoC: ]
1.) Copy the PoC.ZIP archive into the /storage/sdcard0/Download/ directory of your Android device.

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.

alzip.01

Finally select “Extract here” option

alzip.02

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.

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..

[ Disclosure Timeline : ]
01-04-2015 – Vulnerabilities Discovered.
01-04-2015 – Vulnerabilities Details Sent to Vendor.
01-04-2015 – No Reply From Vendor.
13-05-2015 – 2nd Email Sent to Vendor
13-05-2015 – No Reply From Vendor.
01-07-2015 – Public Release.

Thanks & Regards
Jacob Soo