Dark Web Forensics 2

1. Identify any important issue/s that you believe were not addressed (or not addressed adequately) in the literature.  The literature from this report being analysed, didn’t specify how to identify an attack has been already made. Experience has shown me how to identify when a File Upload Attack has happened. From personal experience, when I had found several files with mixed random letters as the file name, I knew these were not files I had uploaded to my webhost. I’m unsure what they were used for though. I deleted them and thought about how I could make my forms more secure.

2. Explain why you view this issue/these issues as important. This is an important issue for web developers to learn so they can protect the website they’ve made. 3. Discuss what you believe to be the most important lesson you have learnt as a result of your literature research. The actual process and the code to which attackers use for File Upload attacks. I can then code my applications more secure. For example, not to use the GET method with php applications, because it can be edited in the url or html document calling the php application.

4. Develop recommendations on how this knowledge will improve the security of your workplace. It will help me build secure websites to protect against this type of attack.

For example: Code forms that only allow uploading certain file types. Limit the file size if that might help it be more specific uploads. Have user authentication – eg username and password at login to use file uploads. Don’t use predictable names for files to be saved and called on the web server. Store uploaded files not in the root folder but in a separate folder away from other files. Scan for malware.

Remove office files from the same folder. Use simple error messages that you can memerise and know what they mean. Following is what I’ve learned to help establish these recommendations. 1. The point of the attacker is to try and gain remote command execution over a back end server by uploading a file or script, for example a php file. Backend scripting can then be used to deface or use the web server for any purpose that only executable scripts are usually allowed to carry out. 2. The first attempt that the attacker uses, is to upload code, then the attacker accesses that file from the url in the browser. Then they can disrupt php applications or even edit data in databases. There are different types of attacks, client side attacks, eg through javascript, backend attacks or html defacement. It depends on the type of file that is uploaded and where it is uploaded to, the permissions of that folder, etc. 3. Some examples of file types that could contain malicious code include .js, .php, .exe, double extensions, such as file.exe.pdf and file.php.docx where malicious code tricks the upload and then can still run on the web server, possibly after being renamed after upload. These all can be file upload vulnerabilities. It is still necessary to have file uploads, they are important for many applications in many industries. 5. Vulnerabilities occur when files are uploaded without validating the content, their name, their type or their size. Not validating uploads means dangerous code and scripts can be uploaded, which can cause an attacker to have remote control where they can take down a website, deface it or disrupt an application or data. If malicious code is uploaded, it can be enough to spread a virus on the web server, for this reason, doing malware scans by the webhost helps protect the system. Antivirus scans can be run on the website itself as well. Other attacks are by http request – eg, by the url in the browser, or called from a html file. 6. “Some of the common web application threats are: · SQL Injection — the objective of this danger could be to bypass login algorithms, sabotage the information, and so on. · Denial of Service Attacks — The objective of this danger could be to deny genuine clients access to the asset. · Cross-Site Scripting XSS — the objective of this risk could be to infuse code that can be executed on the client-side browser. · Cookie/Session Poisoning — the goal of this threat is to modify cookies/session data by an attacker to gain unauthorized access. · Form Tampering — the objective of this danger is to modify form information, for example, costs in web-based business applications so the attacker can get things at a discounted price. · Code Injection — the objective of this danger is to infuse code, for example, PHP, Python, and so on that can be executed on the server. The code can introduce indirect accesses, uncover sensitive data, and so forth. · Defacement– the objective of this risk is to alter the page been shown on a site and diver all page solicitations to a single page that contains the attacker’s message.”(2020, PurpleTeam.)

7. Examples of accessing include a http request: http://website.com.au/somefile.html which could conntain javascript or by accessing a false php file, such as index.php. So its important to analyse the types of files being uploaded. The data that you analyse is called metadata. This helps protect against malicious file uploads.

8. Different types of attacks are as follows: “1. Case-sensitive extension bypass: Web/Mobile application developers may add a blacklist of certain extensions which are harmful according to the developer. But sometimes developers forgot whether their extension security check is case sensitive or not and anyone can bypass security check by making extensions of files as a combination of lowercase and uppercase character to bypass security checks. As a developer, it is good practice to check extension verification and always consider the case sensitivity of file extension. Example: .PDf, .XmL, .Sh, php.

2. Image content Verification bypass: As a security concern developers always check the content of the image to match with one of the valid file types. In PHP there are many functions to validate file one of the function gets getimagesize() this function basically read the file and return the size in case of invalid file returns the error message. There are techniques that can bypass this protection. Consider the following code which uploads a file. PHP

An attacker can bypass such checks by embedding PHP code inside the comment section of the JPG file and after that uploading file with a .php extension, this can easily bypass the checks mentioned in the above code. There are more techniques also available for File verification bypass as a developer always takes care of all these bypasses during implementing the feature of file upload.

Pixel Flood Using Malicious Image File: This is sub attack under the File Upload Vulnerability, this attack mainly exploits the method of image parsing. During performing this attack malicious user takes a valid JPG or JPEG file with the original dimension then the attacker change the dimension of the image to a very large scale like 1000000 ×1000000 by using some automated tool by uploading such a large file image parser allocate very large memory to it and results into server crash or out of memory situation.

Malicious zTXT field of PNG files: The PNG file format contains a section, called zTXT, that allows Zlib compressed data to be added to a PNG file. The technique here is that a large amount of repeated data, such as a series of zeros, are created, weighing over 70MB, and then are DEFLATE compressed through zlib, resulting in compressed data of a few KBs. This is then added to the zTXT section of any regular PNG file. Sending repeated requests of this kind causes similar memory exhaustion as we’ve seen in the previous two examples. This issue affected the Paperclip gem as well.

Malicious GIF file – frame flood: This technique is similar to the previous technique, a malicious GIF is used to allocate a large amount of memory, and eventually, uses a large amount of server memory. A GIF file contains a set of animations in the form of various image frames. Instead of flipping the pixels, we add a very large amount of GIF frames, say 45,000-90,000. When parsing each frame, memory is allocated and eventually chokes up the server.

How To Avoid File Upload Vulnerability: Always check the extension of files with their case sensitivity. Filter the content of the file before uploading it to the server. Don’t give the executable permission to upload the file. Always store the uploaded file in the non-public directory.” (2022, Geeks for Geeks.)

Conclusion:

This is the understanding behind my recommendations – strong validation on file uploads is necessary to avoid file upload vulnerabilities and attacks.

References: Artykov, D. PurpleTeam 2020. Exploiting file upload vulnerabilities in web applications Accessed on 2/9/22.

Geeks for Geeks, 2022. File Upload Vulnerability of Web Applications Accessed on 2/9/22.