Server Side HTTP Redirection, SMTP Injection, HTTP Parameter Injection, HTTP Parameter Pollution - Notes

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

Server Side HTTP Redirection

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

Vulnerability exists when the APPLICATION SERVER uses an Attacker controllable input and incorporates it into a URL and retrieves it using a back-end HTTP Request.

• Attacker may use the Application Server as Proxy to connect to a Internal Network resource which are not accessible directly
• Attacker may use this to attack 3rd party systems
• Attack may connect to other services on the Application Server itself, circumventing Firewall restrictions & exploiting trust relationships.
• Attacker can use it to include external Attack Scripts

Attack : If you are able to identify a vulnerable parameter

• Try to port scan the internal network using Burp Intruder.
• Try to connect to other services on Application Server using 127.0.0.1

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

HTTP Parameter Injection

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

Vulnerability exists when user supplied "Parameters" are used as "Parameters" to a BackEnd HTTP Request.

• Attacker may Inject additional Parameters ( URL encoded ), which are then submitted to the backend service. This might interfere with the application logic.
• These additional parameters may not cause any error ( Unlike SOAP Injection)
• Attack Requires knowledge of backend parameters or access to Code (Whitebox Testing / 3rd party component)

Example :      from=1234&to=54321&amount=1000%26FundsCleared%3DTrue&Submit=submit

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

HTTP Parameter POLLUTION ( too many parameters)

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

Vulnerability exists because, different web servers behave differently when they receive multiple parameters with the same name. Below are the common behaviors

1. First instance of the parameter is used
2. Last instance of the parameter is used
3. Parameter values are concatenated
4. Parameter values are inserted into an array

Success of Attack depends on how the target server handles multiple parameters

Example

Attacker Submits the following

from=1234&to=54321&amount=1000%26FundsCleared%3DTrue&Submit=submit

After Processing the following is submitted to the back end Service

from=1234&to=54321&amount=1000&FundsCleared=True&FundsCleared=False&Submit=submit

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

Attack against RESTstyle URL Rewriting 

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

When REST Style parameters are used ( where parameters are placed in filepath instead of the query string), the translation processing might be vulnerable to HTTP Parameter Injection & HTTP Parameter Pollution

Example:

/app/user/adam         (RESTStyle URL)  gets translated to the below URL
app/profile.php?mode=view&user=adam   

If the Attacker sets his name as    /adam%26mode=edit, then it gets translated to the following

app/profile.php?mode=view&user=adam&mode=edit

The success of attack depends on how multiple parameters are handled by the server.

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

Email Header Manipulation

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

• Some applications offer a facility to email the support staff.
• The application sends a SMTP message to the email server.
• Vulnerability exists when the message submitted by the user is not filtered or sanitized by the application.
• Email functionality allows the sender to submit his emailID, Subject, Message

PHP mail() command

• constructs the email and performs the SMTP conversation with mail server
• additional_headers parameter specifies the "TO, CC, BCC" by separating each header with a new line.
• Sender ID:      abc@gmail.com%0ABcc:all@website.com

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

SMTP Command Injection

==============================================================================
When the application itself performs the SMTP Conversation, it is possible to Inject SMTP Commands.

• SMTP client issues "DATA" command and then sends the Message Headers & Body.
• To finish the message, a single DOT (.) is sent after a new line (CRLF)

SMTP INJECTION

• Text in Red is the Injected content.
• Injected content is URL-Encoded and Injected in the Subject Header.
• This constructs two email messages
• Email message ends with a DOT after a NEW LINE.

MAIL FROM: abc@gmail.com

RCPT TO: support@gmail.com

DATA

From: abc@gmail.com

To:   support@site.com

Subject: Feedback

Site is not working

.

MAIL FROM: abc@attacker.com

RCPT TO: all@site.com

DATA

From: abc@attacker.com

To:   all@site.com

Subject: ATTACK

This is an Attack

.

Preventing an SMTP Injection

1. Email message should be checked against, regular expressions

2. Subject should not contain new Line

3. Length of Subject should be Limited

4. Alternatively, provide hardcoded subject messages

5. Lines containing a single dot should be disallowed.

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