You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eli Marmor <ma...@netmask.it> on 2003/08/28 08:47:19 UTC

Spam Using SMTP "Over" HTTP-Proxy

Hi,

According to research companies, most of the current spamming is done
using HTTP proxies. Spammers assistant scripts scan the net 24 hours a
day, looking for open proxies, and then use them to spread the spam.

Now everybody asking: how can an HTTP proxy used for sending e-mail ?!

The answer is simple: today, more than 99% of the mail servers are
closed against relay, and open only for incoming messages (for internal
recipiants) or outgoing messages (sent by internal users).

Most of the mail servers, including all of the ISPs, recognize
"internal users" as users who connect to the mail server from IP
classes that belong the organization (for example, IPs that belong to
the ISP in the case of an ISP).

So theoretically, a spammer can't use a mail server of a foreign ISP,
unless he connects to it from an IP that belongs to this ISP.

An open HTTP proxy that belongs to a customer of this ISP can help the
spammer to cheat the mail server of that ISP and let it believe that
this e-mail is sent from an innocent customer of that ISP, and this is
how most of the current spamming is done.

But HTTP proxy is educated to forward HTTP content, not SMTP ?!

This is resolved easily by using "POST"; As you probably know, wrong
headers are ignored by most of the mail servers (including sendmail);
So the spammer connects to port 25 of the mail server as an HTTP
service through the open proxy, send a POST request, and hides the SMTP
content in the body of the posted data. The sendmail ignores the HTTP
headers (and only reports warnings to the sender), and accepts the rest
(i.e. the SMTP commands + the body of the e-mail).

It is VERY easy for mod_proxy of Apache to recognize such sessions and
block them. Before I'm starting such a project, I'd like to know:

1. Is there any existing code and/or module that implements this?
2. Is there any plan to add this to Apache / mod_proxy?  My plan will
   take a long time...
3. Is there anything that can be learned from other proxies (e.g Squid)
   regarding this issue?
4. Can anybody add anything to the details that I wrote or has anything
   else to contribute to the effort?

Thanks,
-- 
Eli Marmor
marmor@netmask.it
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.:   +972-9-766-1020          8 Yad-Harutzim St.
Fax.:   +972-9-766-1314          P.O.B. 7004
Mobile: +972-50-23-7338          Kfar-Saba 44641, Israel

Re: Spam Using SMTP "Over" HTTP-Proxy

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
The issue that the reporter, Jason Robertson, suggested to partially solve
this proble is that we should add another AllowConnect directive, such as
AllowHttpProxy, to restrict the ports that you can use to proxy HTTP traffic.
We already have this restriction available for CONNECT (usually https) traffic.

The point to this is actually a good one.  When you consider that one way
to exploit the proxy issue is to hijack one or more machines to chain the
traffic, and thereby bypass other security restricting the machines allowed
to connect to the proxy.  Also consider that major ISPs allow proxy traffic
from their entire local subnet.

The request for this feature is not unreasonable, but it also should not be
considered an end-all to the issue [more inline];

>> If you look at how restrictive the default AllowConnect directive is, then
>> it isn't unreasonable to consider the reporter's orginal suggestion for some
>> AllowProxy directive as well.  Your suggestion would eliminate port 25,
>> if it behaves as we expect, but that doesn't solve the problem for other ports.
>
>I thought about this, and the idea of an Allow(Forward)Proxy directive
>isn't bad, but I don't think I would want it in the default config.  We
>would be encouraging a policy where a proxy administrator would say "http
>is only allowed on ports 80 and 8080".  And I think most of us agree that
>is silly and doesn't do much to help security.

Then why, exactly, is our default setting for AllowConnect so restrictive?

I think it's entirely appropriate to limit http proxy 'by default' to 80/8080 and
allow the user to expand on that list.  No great hardships here.

Yes it would help with traffic control.  No, it would not prevent folks from
exploiting bad 'send email' cgi scripts that are advertised on 80 or 8080.

One point.  We should *never* deploy a directive that handles proxy GET
differently from proxy POST differently.  Such a distinction would violate 
the RFC with unexpected side effects.  So it's limit-by-port or limit-by-origin
name or IP address.  If the user wants to abuse the LIMIT directive in some
other, interesting ways - that should be an exercise left to the reader :-)

At 02:13 AM 8/28/2003, Cliff Woolley wrote:
>On Thu, 28 Aug 2003, Eli Marmor wrote:
>
>> According to research companies, most of the current spamming is done
>> using HTTP proxies. Spammers assistant scripts scan the net 24 hours a
>> day, looking for open proxies, and then use them to spread the spam.
>
>Correct.  And people continue to submit this to security@apache.org as a
>bug on a fairly regular basis, even though it is due to a misconfiguration
>on their part.

And yes - in 95% of the cases this was their failure:

>All you have to do is configure mod_proxy correctly, which lots of sites
>do not.  In particular, setting "ProxyRequests on" without proper access
>controls will create the kind of bad situation that leads to this problem.
>Most of the time what has happened is that the site admin really only
>wanted to provide a REVERSE proxy (as with ProxyPass), not a forward one.
>"ProxyRequests on" is not required for ProxyPass to work.

All of this is 100% correct, but not the end of the entire issue.

>Someone suggested adding a directive to control which ports the proxy will
>connect to (note there's already a directive that controls this for
>CONNECT requests), but since open HTTP proxies are bad for the internet in
>general (in the anonymous-HTTP-to-third-parties sense as well as the
>backdoor-to-your-SMTP-server sense), it didn't seem worth it to block
>_some_ of the bad behavior when fixed configurations would easily block
>ALL of it -- using already existing directives.

And again - we should document, if we add AllowHttpProxy to list the ports
the user wants to restrict proxy traffic to, we should *highlight* that this will
not prevent their server from being used to proxy web-spam to badly written
CGI scripts.  It doesn't invalidate the usefulness of the directive.

At 08:19 AM 8/28/2003, Joshua Slive wrote:

>ProxyBlock :25
>would probably do it.  But I still haven't tested this, since I don't use
>the proxy myself.
>
>But as Cliff said, "ProxyRequests Off" is the real fix.  I spent a few
>hours doing a substantial rewrite of the proxy documentation to try to
>clarify this issue (not with respect to SMTP, but with respect to open
>proxies in general).

It is not *the* real fix, it is one of several fixes.  The docs improvements
are terrific, thank you Joshua!!!  But there are justifications for a new
directive in conjunction with properly controlling access to the proxy.

Here is my original bugtraq response to Jason's comments;

To: "Jason Robertson" <ja...@ifuture.com>
Subject: Re: Apache 1.3.27 mod_proxy security issue
Cc: bugtraq@securityfocus.com, security@apache.org

The Security Team responded 13 minutes after Jason's initial report,
attempting to explain how he had misconfigured his server.  While we
acknowledge that new directives might be desirable in limited cases, 
the team determined that this is clearly a user configuration error.

The Apache HTTP Server Documentation Project has been working
to improve and further clarify the risks of open proxies, including open
faux-HTTP proxies into SMTP servers.  They actively solicit contributions
to the documentation (preferably with a patch) for any ambiguous or 
insufficiently covered topics;

  http://httpd.apache.org/docs-project/

More details follow;

At 11:52 AM 7/22/2003, Jason Robertson wrote:
>I have found that recently a spammer has been using a mod_proxy 
>configuration, (that was meant to allow for an easier transition to a 
>new naming scheme, as well as changes to a backend software) as a spam 
>relay.  
>The spammer has been using HTTP POST requests to send these messages
>with POST HTTP://mailserver:25/ HTTP/1.1  
>With some research it looks like this is an automated process including 
>the initial scan stage.
>
>When I contacted Apache in regards to this, the response was not very 
>promising. 
>
>This problem would be a simple fix with implementing the AllowConnect 
>configuration option within proxy_http, to prevent outbound 
>connections.  

As described in the default configuration, open proxies are never
recommended [from Apache 1.3.27 conf/httpd.conf-dist];

#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
#<IfModule mod_proxy.c>
#    ProxyRequests On

#    <Directory proxy:*>
#        Order deny,allow
#        Deny from all
#        Allow from .your-domain.com
#    </Directory>

    #
    # Enable/disable the handling of HTTP/1.1 "Via:" headers.
    # ("Full" adds the server version; "Block" removes all outgoing Via: headers)
    # Set to one of: Off | On | Full | Block
    #
#    ProxyVia On

    #
    # To enable the cache as well, edit and uncomment the following lines:
    # (no cacheing without CacheRoot)
    #
#    CacheRoot "@@ServerRoot@@/proxy"
#    CacheSize 5
#    CacheGcInterval 4
#    CacheMaxExpire 24
#    CacheLastModifiedFactor 0.1
#    CacheDefaultExpire 1
#    NoCache a-domain.com another-domain.edu joes.garage-sale.com

#</IfModule>
# End of proxy directives.

If (for the purposes of collecting several machine's collective content)
you are attempting to ProxyPass a number of URI's to different boxes,
you should NOT be enabling ProxyRequests.

The final statements in the ProxyRequests directive documentation are;

http://httpd.apache.org/docs/mod/mod_proxy.html#proxyrequests

  "This allows or prevents Apache from functioning as a proxy server. 
   Setting ProxyRequests to 'off' does not disable use of the <http://httpd.apache.org/docs/mod/mod_proxy.html#proxypass>ProxyPass 
   directive."

  "Warning: Do not enable proxying until you have <http://httpd.apache.org/docs/mod/mod_proxy.html#access>secured your server. 
   Open proxy servers are dangerous both to your network and to the 
   Internet at large."

Access control is briefly illustrated further with additional references in;

http://httpd.apache.org/docs/mod/mod_proxy.html#access

Bill




Re: Spam Using SMTP "Over" HTTP-Proxy

Posted by Cliff Woolley <jw...@virginia.edu>.
On Thu, 28 Aug 2003, Joshua Slive wrote:

> I think we've done pretty-much all we can.  I wouldn't mind putting a
> little note on the httpd.apache.org homepage saying "Have you secured your
> proxy?" and point to the correct docs.

+1.

Additionally, Eli and I have been conversing a bit more off-list, and it
does seem that having some additional blocking mechanism (besides IP-based
access control or password-based authentication) would be needed in some
cases where open HTTP proxy is intended but open SMTP tunneling is not.
Perhaps ProxyBlock will suffice.  Confirmation would be cool.

RE: Spam Using SMTP "Over" HTTP-Proxy

Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 02:41 PM 9/4/2003, Joshua Slive wrote:

>> Seriously, we could add a default deny for outgoing port
>> 25 (smtp) and 6660-6670 (irc) proxied connections.
>> This won't really hurt anyone as I don't see any reasons
>> why anybody would want that. A special "AllowProxyPorts 25 6660-6670"
>> directive could then turn those ports open too.
>> We could even try to limit it to defaultly allowing only
>> the proxying of port 80 and 443 and denying the rest for instance.
>
>Bill Wrowe is a fan of the last idea.  I'm neutral about making it the
>default, but I think it would be good to make it configurable.
>
>You should be specific here, however.  We are talking about a directive
>that would allow *outgoing* proxy connections only on specific ports.  For
>example
>AllowForwardProxy 80 8080 8888

I'm thinking even a patternmatch might not be a bad idea, just crufty as
all can be...

AllowForwardProxy *80

Food for thought.

Bill


RE: Spam Using SMTP "Over" HTTP-Proxy

Posted by Jeroen Massar <je...@unfix.org>.
-----BEGIN PGP SIGNED MESSAGE-----

Joshua Slive [mailto:joshua@slive.ca] wrote:

> On Thu, 4 Sep 2003, Jeroen Massar wrote:
> > Requiring a "IKnowIAmOperatingAOpenProxy" flag that needs to
> > be set explicitly would be a better idea then :)
> 
> That's what the ProxyRequests directive does.  Giving it a silly name
> isn't going to help ;-)

True, nothing much we can do about people not reading the docs :(

> > Seriously, we could add a default deny for outgoing port
> > 25 (smtp) and 6660-6670 (irc) proxied connections.
> > This won't really hurt anyone as I don't see any reasons
> > why anybody would want that. A special "AllowProxyPorts 25 6660-6670"
> > directive could then turn those ports open too.
> > We could even try to limit it to defaultly allowing only
> > the proxying of port 80 and 443 and denying the rest for instance.
> 
> Bill Wrowe is a fan of the last idea.  I'm neutral about making it the
> default, but I think it would be good to make it configurable.
> 
> You should be specific here, however.  We are talking about a 
> directive that would allow *outgoing* proxy connections only on 
> specific ports.  For example
> AllowForwardProxy 80 8080 8888

That could be the default then, if people would require other
ports they would either need to add them or specify "All" if
they are really sure of what they are doing.

We should also convince packagers that they never include the
All option per default or as a simple configuration option.
If someone wants it, let them read the doc, which should contain
the "you are opening up as an open relay" warning.

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/

iQA/AwUBP1hHximqKFIzPnwjEQK6VgCfSJkykyhb+jvWp/ShzWrDcflhFxgAn26c
RKAczDl/QqHK5kk8w8Mcvtqb
=NT/J
-----END PGP SIGNATURE-----


RE: Spam Using SMTP "Over" HTTP-Proxy

Posted by Joshua Slive <jo...@slive.ca>.
On Thu, 4 Sep 2003, Jeroen Massar wrote:
> Requiring a "IKnowIAmOperatingAOpenProxy" flag that needs to
> be set explicitly would be a better idea then :)

That's what the ProxyRequests directive does.  Giving it a silly name
isn't going to help ;-)

> Seriously, we could add a default deny for outgoing port
> 25 (smtp) and 6660-6670 (irc) proxied connections.
> This won't really hurt anyone as I don't see any reasons
> why anybody would want that. A special "AllowProxyPorts 25 6660-6670"
> directive could then turn those ports open too.
> We could even try to limit it to defaultly allowing only
> the proxying of port 80 and 443 and denying the rest for instance.

Bill Wrowe is a fan of the last idea.  I'm neutral about making it the
default, but I think it would be good to make it configurable.

You should be specific here, however.  We are talking about a directive
that would allow *outgoing* proxy connections only on specific ports.  For
example
AllowForwardProxy 80 8080 8888

Joshua.

RE: Spam Using SMTP "Over" HTTP-Proxy

Posted by Jeroen Massar <je...@unfix.org>.
-----BEGIN PGP SIGNED MESSAGE-----

Joshua Slive [mailto:joshua@slive.ca] wrote:

> I don't think that is feasible.  There are MANY ways to do 
> access control in apache.
> 
> Sending a message along the lines of "Your server is 
> configured to proxy requests to arbitrary servers." whenever ProxyRequests is On 
> would be a possibility.

That would indeed help, but how many redhat/debian/... read
the logs when it works ?

Requiring a "IKnowIAmOperatingAOpenProxy" flag that needs to
be set explicitly would be a better idea then :)

Seriously, we could add a default deny for outgoing port
25 (smtp) and 6660-6670 (irc) proxied connections.
This won't really hurt anyone as I don't see any reasons
why anybody would want that. A special "AllowProxyPorts 25 6660-6670"
directive could then turn those ports open too.
We could even try to limit it to defaultly allowing only
the proxying of port 80 and 443 and denying the rest for instance.

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/

iQA/AwUBP1ePfCmqKFIzPnwjEQKGWACffesaa690wCAFBWKxF4ae7IjeICIAn1e5
9dvAvWU3n9iGcLFTeiYxuphu
=Aj1Q
-----END PGP SIGNATURE-----


Re: Spam Using SMTP "Over" HTTP-Proxy

Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 2 Sep 2003, Chris Knight wrote:

> Joshua Slive wrote:
>
> >I think we've done pretty-much all we can.  I wouldn't mind putting a
> >little note on the httpd.apache.org homepage saying "Have you secured your
> >proxy?" and point to the correct docs.
> >
> >
> What about sending a warning message to stderr/error_log upon startup if
> the proxy is not access controlled?

I don't think that is feasible.  There are MANY ways to do access control
in apache.

Sending a message along the lines of "Your server is configured to proxy
requests to arbitrary servers." whenever ProxyRequests is On would be a
possibility.

> ...HTTPS proxying is even worse and could be used to mount a variety of
> TCP attacks.

The AllowConnect directive restricts that.

Joshua.

Re: Spam Using SMTP "Over" HTTP-Proxy

Posted by Chris Knight <Ch...@nasa.gov>.
Joshua Slive wrote:

>I think we've done pretty-much all we can.  I wouldn't mind putting a
>little note on the httpd.apache.org homepage saying "Have you secured your
>proxy?" and point to the correct docs.
>  
>
What about sending a warning message to stderr/error_log upon startup if 
the proxy is not access controlled?

...HTTPS proxying is even worse and could be used to mount a variety of 
TCP attacks.


Re: Spam Using SMTP "Over" HTTP-Proxy

Posted by Joshua Slive <jo...@slive.ca>.
On Thu, 28 Aug 2003, Eli Marmor wrote:
> According to research companies, most of the current spamming is done
> using HTTP proxies.

I find that hard to believe.  I believe a substantial amount of spam comes
this way, but "most" seems unlikely.

> 1. Is there any existing code and/or module that implements this?

ProxyBlock :25
would probably do it.  But I still haven't tested this, since I don't use
the proxy myself.

But as Cliff said, "ProxyRequests Off" is the real fix.  I spent a few
hours doing a substantial rewrite of the proxy documentation to try to
clarify this issue (not with respect to SMTP, but with respect to open
proxies in general).

I think we've done pretty-much all we can.  I wouldn't mind putting a
little note on the httpd.apache.org homepage saying "Have you secured your
proxy?" and point to the correct docs.

Joshua.

Re: [apache-modules] Spam Using SMTP "Over" HTTP-Proxy

Posted by Ivan Ristic <iv...@webkreator.com>.
Eli Marmor wrote:
> Hi,
> 
> ...
> 
> It is VERY easy for mod_proxy of Apache to recognize such sessions and
> block them. Before I'm starting such a project, I'd like to know:
> 
> 1. Is there any existing code and/or module that implements this?
> 2. Is there any plan to add this to Apache / mod_proxy?  My plan will
>    take a long time...
> 3. Is there anything that can be learned from other proxies (e.g Squid)
>    regarding this issue?
> 4. Can anybody add anything to the details that I wrote or has anything
>    else to contribute to the effort?

   Well, of the top of my head, you can stop this spam with mod_security
   and this line (just a crude filter, there are probably other better
   and more effective ways to do it):

   SecFilterSelective REQUEST_URI ":25"

   But I would say that it would be better to change mod_proxy to block
   such requests by default. People who are likely to install and
   use mod_security are unlikely to have their proxies widely open like
   this.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]


Re: Spam Using SMTP "Over" HTTP-Proxy

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:23 PM 8/28/2003, André Malo wrote:
>* szymanski_j wrote:
>
>[smtp over http proxy]
>
>> Problem can come from your module to be linked with external shared
>> libraries.
>
>???

I could not understand your reference, either.  Would you further explain
how DSOs have any relationship with using HTTP proxy for SMTP traffic?

Bill



Re: Spam Using SMTP "Over" HTTP-Proxy

Posted by André Malo <nd...@perlig.de>.
* szymanski_j wrote:

[smtp over http proxy]

> Problem can come from your module to be linked with external shared
> libraries.

???

nd
-- 
Wenn nur Ingenieure mit Diplom programmieren würden, hätten wir
wahrscheinlich weniger schlechte Software.
Wir hätten allerdings auch weniger gute Software.
                                   -- Felix von Leitner in dasr

Re: Spam Using SMTP "Over" HTTP-Proxy

Posted by szymanski_j <sz...@yahoo.com>.
Problem can come from your module to be linked with external shared 
libraries.

Look at:
http://www.megalith.co.uk/manual/dso.html

hope it helps,
cheers,
--jakub

--- In new-httpd@yahoogroups.com, Cliff Woolley <jw...@v...> wrote:
> On Thu, 28 Aug 2003, Eli Marmor wrote:
> 
> > According to research companies, most of the current spamming is 
done
> > using HTTP proxies. Spammers assistant scripts scan the net 24 
hours a
> > day, looking for open proxies, and then use them to spread the 
spam.
> 
> Correct.  And people continue to submit this to security@a... as a
> bug on a fairly regular basis, even though it is due to a 
misconfiguration
> on their part.
> 
> All you have to do is configure mod_proxy correctly, which lots of 
sites
> do not.  In particular, setting "ProxyRequests on" without proper 
access
> controls will create the kind of bad situation that leads to this 
problem.
> Most of the time what has happened is that the site admin really 
only
> wanted to provide a REVERSE proxy (as with ProxyPass), not a 
forward one.
> "ProxyRequests on" is not required for ProxyPass to work.
> 
> Someone suggested adding a directive to control which ports the 
proxy will
> connect to (note there's already a directive that controls this for
> CONNECT requests), but since open HTTP proxies are bad for the 
internet in
> general (in the anonymous-HTTP-to-third-parties sense as well as the
> backdoor-to-your-SMTP-server sense), it didn't seem worth it to 
block
> _some_ of the bad behavior when fixed configurations would easily 
block
> ALL of it -- using already existing directives.
> 
> We've been attempting to conduct a bit of user education by way of
> improved documentation, removed default configurations, and a few 
posts to
> bugtraq, but obviously people still have wide open HTTP proxies due 
to
> old, broken configurations, and will probably continue to do for 
some time
> to come.  :(
> 
> --Cliff


Re: Spam Using SMTP "Over" HTTP-Proxy

Posted by Cliff Woolley <jw...@virginia.edu>.
On Thu, 28 Aug 2003, Eli Marmor wrote:

> According to research companies, most of the current spamming is done
> using HTTP proxies. Spammers assistant scripts scan the net 24 hours a
> day, looking for open proxies, and then use them to spread the spam.

Correct.  And people continue to submit this to security@apache.org as a
bug on a fairly regular basis, even though it is due to a misconfiguration
on their part.

All you have to do is configure mod_proxy correctly, which lots of sites
do not.  In particular, setting "ProxyRequests on" without proper access
controls will create the kind of bad situation that leads to this problem.
Most of the time what has happened is that the site admin really only
wanted to provide a REVERSE proxy (as with ProxyPass), not a forward one.
"ProxyRequests on" is not required for ProxyPass to work.

Someone suggested adding a directive to control which ports the proxy will
connect to (note there's already a directive that controls this for
CONNECT requests), but since open HTTP proxies are bad for the internet in
general (in the anonymous-HTTP-to-third-parties sense as well as the
backdoor-to-your-SMTP-server sense), it didn't seem worth it to block
_some_ of the bad behavior when fixed configurations would easily block
ALL of it -- using already existing directives.

We've been attempting to conduct a bit of user education by way of
improved documentation, removed default configurations, and a few posts to
bugtraq, but obviously people still have wide open HTTP proxies due to
old, broken configurations, and will probably continue to do for some time
to come.  :(

--Cliff