Lucene search
Packet StormPACKETSTORM:12170HistoryAug 17, 1999 - 12:00 a.m.
smtp.acct.probing.txt
1999-08-1700:00:00
Packet Storm
packetstormsecurity.com
66
`http://www.l8r.com/nwa/nwa1.htm
Network Abuse Information
SMTP Server abuse
Software: GeoList Pro
Author: www.earthonline.com
SPECIAL UPDATE:
03/08/99 GeoList Pro is being pulled from distribution. Details can be found at EarthOnline's Site. (Use the URL above).
Jump to Updates
Original Posting: 03/03/98
A few words from the authors of the program... (with a few of my comments):
"GeoList Professional, the first of itΒs kind in targeted email verification. The program, created with a internal name list, queries Internet mail servers to
validate for a matching email address. Internet Service Providers (ISP's), may not have seen this type of email verification, and may presume it to be
bulk email." (maybe because it's an abusive and a non RFC way of doing it? What happened to using VRFY ?)
"It is important that you realize: Using multi-threaded products like GeoList to query mail servers across the Internet is not a standard practice." (looks
like they are admitting it is abusive!)
"Most ISP's mistake this activity as sending multiple messages through their servers." (Maybe this is due to the poor programming?)
"The result of complaints to your ISP usually leads to the loss of your account. In no way is GeoList Professional relaying any messages through any
servers, it is only validating email addresses which is a standard feature built into most email servers, but rarely used." (Umm you might want to re-check the
RFC to see the "proper" way to VRFY an email address!)
Then they go on to say that you need to accept the use policy of a few sites that house email addresses but do not mention that they should abide by the
use policy of the domains they scan.
Here is a break-down of what the program does and some info on how to help prevent your server from being abused
Effects: Connects to SMTP server and "pretends" to be sending a message. It uses a dictionary of names to add to a domain to see if it generates an
error. If it does not it "assumes" it is a valid email address.
Signature: The email address it uses when it connects to the SMTP server was first seen as "[email protected]" and has now been seen as
[email protected]. In a newer version it has been changed to [email protected].
New Problem: In the newer version the makers of the software have "Hard Coded" over 4200 domains into the program to be used for scanning. This
invites it's users to abuse those 4200+ domains with their poorly written software.
Example from SMTP log:
02:24 16:22 SMTPD(00360110) [209.86.182.86] MAIL FROM:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user <[email protected]
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user <[email protected]
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user <[email protected]
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user <[email protected]
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user <[email protected]
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user <[email protected]
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user <[email protected]
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user <[email protected]
02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO:<[email protected]>
02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user <[email protected]
To block these attempts you will need to add the email address listed above to a kill list to deny email coming from those addresses.
Unknowns: It is unknown if the users have the ability to change those email addresses used as the MAIL FROM as I have not run the program on any of
my machines (which requires registration). I have a good feeling it is not changeable. If they do have that ability none of them have been smart enough to
change it yet, and if they don't it would have been alot wiser for the makers to use their own domain instead of abusing someone else's domain.(but then
again they probably don't want to put up with the complaints?!)
GeoList Features as quoted from the program help file:
"Geolist has incorporated special anti-blocking measure that will reconnect your Internet provider when it detects that your current IP address is being
blocked from one of the search engines." (or domains maybe ? I would consider this abuse features built in. If the IP was being blocked it was probably for good reason)
"This software is to be used only in a lawful manner in compliance with any laws, regulations or rules applicable to the user or use of the software.
Applicable laws vary according to country, state, province, territory, city etc. It is entirely the responsibility of the user to know the applicable laws
pertaining to them. Laws can change. If you are uncertain, please check with a competent attorney." (what about usage policy's that providers have set on the use of
their equipment? Didn't they design the software to comply with the laws? If so why hard code over 4200 domains into the program?)
03/07/99 Preperations are being made to post some usefull links and information on how to possibly combat this type of attack on SMTP server. I feel
there has been some good discussion in the list-serv regarding this. There have been other discussions as well and may result in splitting the list serv
into two different subscriptions to make it easier for those trying to communicate etc.
03/07/99 Many have asked what my motivation was for this site and for notifying people.
Basically to inform people of the problem and why it is happening. Many people had seen it
happening and where clueless as to what was causing it. The owner of savings.com was taking the
brunt of it as many thought it had something to do with him.
In one case (prior to sending the message out) one ISP called us to report a user on our system
that was trying to relay mail through his system with the program. He was unaware that in fact it
was not trying to relay but instead scanning for valid email address (this was learned after
contacting the user on our system to find out what he was doing). The reason that he called us was
that the scanning was locking up his system and he was continously having to reboot the system
so that his ISP could continue function.
I felt this is a very abusive program and that those most likely to be affected by it (the domains
hard coded into the program) should know about it.
-paul
03/07/99 Many have asked for copies of the program etc. If you do a search on HotBot or other search engines(I used HotBot) searching for the words
EarthOnline and Geolist will result in many lsitings of "many" sites that are vendors or distributors of the product. Many of those sites have downloads
available and some of them contain older versions of the program. I would reccomend this as your best solution for finding a copy of the program if needed.
03/04/99 It appears they now have a version glp34.exe and the glp33.exe is no longer available. This new version requires you to enter a email address
instead of using it's default (from what I can tell so far) They have also encrypted the domain names that are hard coded into the program. (It would
appear they know they have a problem and are now trying to hide it, if not why encrypt it?)
03/04/99 On 03-03-99 One of the machines I admin was hit with either the same program or a different program and 75% of the log (which amounted to
20meg) was due to abuse by this program or similar program. The email address used was random chars @MSN.COM. So either it's a different program
or they are using the new version.
03/04/99 A List_Serv has been setup for those that wish to discuss this with others that have been abused by this program and others and discuss ways
to prent these attacks or trying to control them etc. To subscribe send a email message to [email protected] with the following line:
subscribe smtpabuse your_name
Substituting your_name with your name of course.
If you have any comments or would like additional information posted on this site or know of similar programs feel free to email them to [email protected].
Depending on the response and feedback I may expand this site to include other problem software or other network abuse notices.
----------------------------------------------------------------------
Date: Mon, 8 Mar 1999 12:13:22 -0700
From: Brett Glass <[email protected]>
To: [email protected]
Subject: SMTP server account probing
Several ISPs throughout the Net are reporting an attack described at
http://www.l8r.com/nwa/nwa1.htm
In this attack, an SMTP server is probed for common names, presumably
so that spam can the be targeted at them. The attacking machine
connects and issues hundreds of RCPT TO: commands, searching a long
list of common user names (e.g. susan) for ones that don't cause
errors. It then compiles a list of target addresses to spam.
Unfortunately, the attack -- besides allowing the perpetrator to spam
users -- also brings SMTP servers to their knees. This happens most
often if the server maintains lists of user names in a database where
looking up a name requires substantial disk activity or computational
overhead.
Some people whose domain names have been hard-coded into a commercial
program designed to implement this attack have responded with outrage,
e.g.
http://www.junk.org/earthonline/
I'm surprised that I haven't seen this one on the Bugtraq list yet.
--Brett Glass
----------------------------------------------------------------------
Date: Wed, 10 Mar 1999 11:24:30 -0800
From: Frank Miller <[email protected]>
To: [email protected]
Subject: SMTP Abuse - Extracted domains from glpro.exe application
Per request, the following URL lists domains hardcoded into the glpro.exe
application (version 3.3 trail).
ftp://ftp.apaynet.com/pub/glpro/glpro.txt
In summary, the glpro.exe application performs, as discussed, a dictionary
based 'attack' upon MTA's (RCPT/MAIL) in order to obtain a list of addresses
for UCE's. Approximately 4000 + domains (including isi.edu!!) was noted.
Take care,
Frank Miller
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 13:14:06 -0500
From: David Gale <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
On Mon, 8 Mar 1999, Brett Glass wrote:
> Several ISPs throughout the Net are reporting an attack described at
>
> http://www.l8r.com/nwa/nwa1.htm
Using /usr/dict/words on my linux box and the TCL code below I ran this
attack against a sendmail (8.9.2) mailserver which uses virtual user
tables and a lengthy aliases database.
The result was the load went up slightly and log entries consumed some
disk space. All in All, Minimal threat to service. I would not call this a
DOS attack in our configuration.
#!/usr/bin/tclsh
set infile [open /usr/dict/words r]
set sock [socket someserver.example.com 25]
puts $sock "HELO remotehost.example.com"
puts $sock "MAIL FROM: [email protected]"
while {[eof $infile] != 1} {
gets $infile input
puts $sock "RCPT TO: $input"
flush $sock
gets $sock output
if {[string range $output 0 2] != "550"} {
puts "Valid Username! $input"
}
}
close $sock
exit
DG.
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 08:57:32 -0800
From: Frank Miller <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
The following is from the company (earthonline.com) that wrote the
commerical software
that performed the dictionary attack against MTA's. I do have copies of the
software
and can generate a list of 'hard coded' ISP's that were probed, if desired.
Dear ISP and Fellow Internet User,
GeoList Professional has been removed from the
Earthonline Product Line.
If used as it was intended, this product would
have created email address lists that would
have proven highly targeted to a specific state
or region.
Although GeoList is only one of many different
programs that verify state related email
addresses on the market, we find it appropriate
for the good of the Internet Community, that we
pull this product from our shelves.
GeoList was designed for the individual or
business looking for a target market in
specific states or regions. Initially this
program was developed for an online political
campaign. The candidates campaign staff
requested the ability to target their specific
region. GeoList, utilized in this market,
proved effective; for this reason Earthonline
released it as a targeted lead generation
product.
The subsequent mis-use of GeoList Professional
by certain companies and individuals has
reportedly made it difficult on the ISPs. As
GeoList validates a list of user names and
matches them with email addresses in the given
state, it was our intent to target email
addresses for any give "region specific"
campaign.
It is undetermined how end-users were using
this product. However, we have had reports of
customers using this product as a non-targeted
spam list collection tool. Earthonline stands
behind targeted email notification and
solicitation of targeted lead lists. However,
we do not condone or promote spam as a way to
market products or services. Our products are
intended as a cost effective way for companies
and organizations to email their customers, and
clients, with new product offerings, updates,
and/or informative news.
GeoList Professional has reportedly been used
"not as intended" - and although we could limit
the sales of the product to certain individuals
and companies, we choose not to sensor those
customers of our products. However, with
reports of how the GeoList product is being
used; It is our decision to make GeoList a
discontinued product as of March 08, 1999.
As the technology within GeoList is not
proprietary to Earthonline, the discontinuation
of this product will not be the discontinuation
of other products in the marketplace that
promote similar functionality.
If you should have direct questions, or
comments regarding this notice, email to:
[email protected]
- Earthonline Administration
----------------------------------------------------------------------
http://www.junk.org/earthonline/
Close EarthOnline Campaign
EarthOnline Hate and Destruction Page - 1999-03-08
You HATE spam, please help us!
EarthOnline is a company made of stupid and dangerous lamers.
Have a look at their site (if it's up between two nukes) : http://www.earthonline.com/
It is not a new business.
They WILL NOT LISTEN you, they will rather add a line to deny you a web connection if you try to explain them they are wrong.
They make lame software, intended for bulk e-mailing.
They KNOW it is for sending SPAM. They KNOW it is ABUSE.
Their software VIOLATES laws, by using UNAUTHORIZED ways to retrieve e-mail addresses.
Their softwares ABUSES Internet servers resouces. Read this : http://www.l8r.com/nwa/nwa1.htm
Their softwares can even CRASH mail servers - qualifying it as some kind of DENIAL-OF-SERVICE crackware. Programs sold by
Earthonline are just as nefast as viruses, exploits, trojans, or other networks-scans-for-dummy-crackers.
They ARE AWARE of this, and they continue to sell their crap, for more than one year (probably more, but I only know them for one year).
It is a PYRAMIDAL SCHEME.
A quote from http://www.earthonline.com/newweb/vfaq.htm :
We do not assume any responsibility for products being delivered (whether electronically or otherwise) into a foriegn country, that are
considered illegal. Please investigate your local laws before purchasing and selling questionable products or items.
THAT'S ENOUGH !!! LET'S ALL BLOW THEM UP
Please note that most proposals below are illegal. You engage YOUR OWN responsibility. The author of the page denies any responsibility on what YOU
will do.
ILLEGAL - use any mailbombing software against them. Try these addresses :
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
STRONGLY ILLEGAL - use any TCP/IP nuke you can find on the net against them. As long as their web is down spammers won't buy this
crap. Try these ips :
SUPPORT 209.20.201.81
NS12 209.20.201.76
VENDOR 209.20.201.68
MIDAS 209.20.201.75
MAIL 209.20.201.80
They are under Winblows NT (This is the only thing I love with NT : bastards use it).
They (or their provider ?) seem to own other domains :
EOLCORP.COM
CLUBSOFTWARE.COM
LYLEANDAUDREY.COM
CELLDATA.COM
ILLEGAL - use any FTP/SMTP/POP3/DNS/HTTP nuke you can find. Use denial-of-service progs. Open stale sockets. SYN flood them.
Mailbomb, mailbomb, mailbomb. Nuke them.
FTP server software : (unknown)
SMTP server software : IMail 4.06 768-1
DNS server software : (unknown)
POP3 server software : IMail 4.06 1148-1
HTTP server software : Microsoft-IIS/4.0
port_139 : open (enjoy!)
LEGAL and ENCOURAGED - Send complaints to their connectivity providers. Denounce their resellers to domain admins - chance are that
resellers accounts will be closed. I did it on other spamware resellers and it worked. Lawsuit them, if you can.
Resellers page : http://www.earthonline.com/VendSites/default.asp
Sample list :
[closed] http://www.uslink.net/~nikken/home/
[partially deleted] http://www.e-earth.com/earthonline
[up] http://www.totalbiz-solutions.com/eolproducts.htm
[up] http://www.ltgcomm.com/product_center.htm
[up] http://www.emailkings.com/
[up] http://www.theemailshop.com/products/earthonline/products.htm
[up] http://www.informationmart.com/Software/BulkEmail/products.htm
[up] http://www.email123.com/
[closed] http://www.emailhouse.com/
[up] http://www.meandaur.com/earthonline/index.htm
LEGAL - According to D. L. G. :
Contact the Washington State Attorney General. While WA's anti-spam law isn't the greatest, it does exist, and these idiots have coded their
software in violation of several of its points, and according to the Internic reg, they're based out of Washington.
I urge you to do so if you can prove they made illegal use of your domain name (i.e. you are in their internal list).
http://www.wa.gov/ago/junkemail/complaint.html
NOT LEGAL - If you are in the US, phone them and yell. Blow their fax. Or make them lose time, by any means. MAKE THEIR LIFE
IMPOSSIBLE !!! These guys are impatient. If we can poison their life long enough they will give up and find another less harming business.
Phone numbers : (425)865.9000 ;
Fax numbers : 425.865.9100 ;
Snail mail :
EOL Corporation
7981 168th Ave. NE
Building 4
Redmond, WA 98052
Your are encouraged to mirror this page. Advertise about it (don't spam newsgroups, thanks).
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 09:36:04 -0800
From: John E. Martin <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
>In this attack, an SMTP server is probed for common names, presumably
>so that spam can the be targeted at them. The attacking machine
>connects and issues hundreds of RCPT TO: commands, searching a long
>list of common user names (e.g. susan) for ones that don't cause
>errors. It then compiles a list of target addresses to spam.
This is a good reason for sendmail users to add the following to their .cf
files:
O PrivacyOptions=goaway
This will prevent VRFY and EXPN commands from functioning at all and
releasing correct addresses.
>Unfortunately, the attack -- besides allowing the perpetrator to spam
>users -- also brings SMTP servers to their knees. This happens most
>often if the server maintains lists of user names in a database where
>looking up a name requires substantial disk activity or computational
>overhead.
While the 'goaway' option may not prevent the program from continuing to
verify addresses, it will keep your users address from being picked up by
the program.
Perhaps someone with better sendmail experience could come up with an idea
to automatically disconnect connections that are issuing more than 25 VRFY
statements at a time?
Cheers,
John E. Martin
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 20:58:25 +0300
From: GvS <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
Hi there!
On Mon, 8 Mar 1999, Brett Glass wrote:
BG> In this attack, an SMTP server is probed for common names, presumably
BG> so that spam can the be targeted at them. The attacking machine
BG> connects and issues hundreds of RCPT TO: commands, searching a long
BG> list of common user names (e.g. susan) for ones that don't cause
BG> errors. It then compiles a list of target addresses to spam.
The most common protection method against this attack is to restrict
the number of recipients per message as defined in sendmail.cf:
O MaxRecipientsPerMessage=NN
It doesn't protect from name probing, but protects from overhead in
conjunction with O ConnectionRateThrottle and O MaxDaemonChildren
options.
BG> I'm surprised that I haven't seen this one on the Bugtraq list yet.
I do not think it's bugtraq issue really. This attack can easily be
prevented with configuration methods.
SY, Seva Gluschenko, just stranger at the Road.
GVS-RIPE: Cronyx Plus / RiNet network administrator.
--- IRC: erra
* Origin: Erra Netmale ([email protected]) [http://gvs.rinet.ru/]
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 13:51:28 -0700
From: Brett Glass <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
At 09:36 AM 3/9/99 -0800, John E. Martin wrote:
>While the 'goaway' option may not prevent the program from continuing to
>verify addresses, it will keep your users address from being picked up by
>the program.
>
>Perhaps someone with better sendmail experience could come up with an idea
>to automatically disconnect connections that are issuing more than 25 VRFY
>statements at a time?
Unfortunately, the program was designed to defeat the "goaway" option by
using RCPT TO: commands instead of VRFY commands. What's needed is
the ability to kill the connection after more than two or three recipient
names have generated errors.
--Brett
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 16:08:32 -0500
From: [email protected]
To: [email protected]
Subject: Re: SMTP server account probing
On Tue, 09 Mar 1999 09:36:04 PST, you said:
> Perhaps someone with better sendmail experience could come up with an idea
> to automatically disconnect connections that are issuing more than 25 VRFY
> statements at a time?
Wrong solution. They'll just reconnect and try another 25. All you've bought
then is an extra fork() of the sendmail daemon every 25 pokes. Remember,
these people don't give a s**t if they waste your resources...
Maybe what's needed is a new ioctl on a socket, so you can do this:
if (vrfy_cnt > 25) {
ioctl(net_socket,SO_NOSENDFIN);
clkose(net_socket);
}
so you can free up the socket at YOUR end, and intentionally fail to
send the FIN packet, so the OTHER end gets to wait for a timeout.
Yes, yes, yes, I *KNOW* it's Evil and Against The RFCs. But it's tempting. ;)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 23:45:46 +0000
From: Alan Cox <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
> Maybe what's needed is a new ioctl on a socket, so you can do this:
>
> if (vrfy_cnt > 25) {
> ioctl(net_socket,SO_NOSENDFIN);
> clkose(net_socket);
> }
How about adding a firewall rule for the site concerned ? Thats programatically
similar and has the advantage they wont be back until you get bored enough
to remove the block
----------------------------------------------------------------------
Date: Wed, 10 Mar 1999 10:08:06 +1100
From: Nick Andrew <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
Forwarding a message from Brett Glass:
> Unfortunately, the program was designed to defeat the "goaway" option by
> using RCPT TO: commands instead of VRFY commands. What's needed is
> the ability to kill the connection after more than two or three recipient
> names have generated errors.
Just modify your SMTP daemon to return the appropriate error code for
all RCPT TO requests after #25. They can continue to probe forever but all
probes will return false. It might be a good idea to also put a short
delay into the responses to probes (like 1 second).
If the other end actually tries to send a message after doing all this
probing, route the message to /dev/null (or drop it in a directory for
later examination).
Larger sites may wish to alter the threshold at which defence actions are
initiated.
Nick.
--
Zeta Internet SP4 Fax: +61-2-9233-6545 Voice: 9231-9400
G.P.O. Box 3400, Sydney NSW 1043 http://www.zeta.org.au/
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 17:04:30 -0800
From: Brian Behlendorf <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
On Tue, 9 Mar 1999, Brett Glass wrote:
> At 09:36 AM 3/9/99 -0800, John E. Martin wrote:
>
> >While the 'goaway' option may not prevent the program from continuing to
> >verify addresses, it will keep your users address from being picked up by
> >the program.
> >
> >Perhaps someone with better sendmail experience could come up with an idea
> >to automatically disconnect connections that are issuing more than 25 VRFY
> >statements at a time?
>
> Unfortunately, the program was designed to defeat the "goaway" option by
> using RCPT TO: commands instead of VRFY commands. What's needed is
> the ability to kill the connection after more than two or three recipient
> names have generated errors.
I would recommend against doing this. There are many legitimate large
mailing lists out there that are very likely to use multiple RCPT headers
in a single transaction to save bandwidth, and the odds of getting more
than two or three bounces from closed accounts are fairly good, so this
would break valid SMTP conversations. Besides, the address harvesters
will simply reopen a second connection.
Brian
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 18:24:06 -0500
From: Stefan Monnier <monnier+lists/bugtraq/news/@TEQUILA.CS.YALE.EDU>
To: [email protected]
Subject: Re: SMTP server account probing
>>>>> "Brett" == Brett Glass <[email protected]> writes:
> Unfortunately, the program was designed to defeat the "goaway" option by
You mean "fortunately":
I'm actually quite pleased to have such a good example of why turning
off VRFY and EXPN buys you nothing.
Stefan
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 15:08:39 -0800
From: Keith Woodworth <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
On Tue, 9 Mar 1999, John E. Martin wrote:
>>>In this attack, an SMTP server is probed for common names, presumably
>>>so that spam can the be targeted at them. The attacking machine
>>>connects and issues hundreds of RCPT TO: commands, searching a long
>>>list of common user names (e.g. susan) for ones that don't cause
>>>errors. It then compiles a list of target addresses to spam.
>>
>>This is a good reason for sendmail users to add the following to their .cf
>>files:
>>
>>
>>O PrivacyOptions=goaway
>>
>>
>>This will prevent VRFY and EXPN commands from functioning at all and
>>releasing correct addresses.
>>
The goaway option will also, if I'm not mistaken, also screwup anyone who
does ETRN to collect mail. Fetchmail is one program that uses ETRN I
believe.
Keith
----------------------------------------------------------------------
Date: Wed, 10 Mar 1999 09:18:25 +0800
From: Jose C. Oon <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
.....snip.....
> Unfortunately, the program was designed to defeat the "goaway" option by
> using RCPT TO: commands instead of VRFY commands. What's needed is
> the ability to kill the connection after more than two or three recipient
> names have generated errors.
This is a good idea where a predetermined number of errors in RCPT
should warrant the sendmail process to abort and terminate. But on
the other side, it'll interrupt normal mail messages delivery, hence,
causing lots of retries. Default of 3-5 days.
I'd suggest to add some intended delays, for instance:
when there's a RCPT error, the attacked sendmail daemon will
delay say 30 seconds, before it accepts another RCPT TO or other command.
Of course eventually the sendmail will time out and drop the
connections when necessary.
--Joseph
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 15:20:44 -0600
From: Ryan Permeh <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
This is a good idea, but the problem with this program is that it acts like
it were sending mail to a user, not using the VRFY command, but the RCPT
to: command, as any normal mail user agent would.
I have been playing around with an idea that would send false rcpt to
errors after a certain number of failures. This would, at the very least,
not give the program any more information than the first couple rcpt to:,
until a certain number of bad rcpt to:'s happen.
there are other ways of doing this, that are not apporpriate for this use,
that limit the total number of RCPT to:'s accepted. this can be done (at
least in 8.9.3) using the :
O MaxRecipientsPerMessage
directive in the sendmail.cf file.
Ryan Permeh
At 09:36 AM 3/9/99 -0800, you wrote:
>>In this attack, an SMTP server is probed for common names, presumably
>>so that spam can the be targeted at them. The attacking machine
>>connects and issues hundreds of RCPT TO: commands, searching a long
>>list of common user names (e.g. susan) for ones that don't cause
>>errors. It then compiles a list of target addresses to spam.
>
>This is a good reason for sendmail users to add the following to their .cf
>files:
>
>
>O PrivacyOptions=goaway
>
>
>This will prevent VRFY and EXPN commands from functioning at all and
>releasing correct addresses.
>
>>Unfortunately, the attack -- besides allowing the perpetrator to spam
>>users -- also brings SMTP servers to their knees. This happens most
>>often if the server maintains lists of user names in a database where
>>looking up a name requires substantial disk activity or computational
>>overhead.
>
>While the 'goaway' option may not prevent the program from continuing to
>verify addresses, it will keep your users address from being picked up by
>the program.
>
>Perhaps someone with better sendmail experience could come up with an idea
>to automatically disconnect connections that are issuing more than 25 VRFY
>statements at a time?
>
>Cheers,
>John E. Martin
>
Ryan R Permeh E-MAIL: [email protected] [email protected]
IS Engineer WEB : http://www.rconnect.com http://www.response.net
Rural Connections / HELP : [email protected]
Response Inc. FAQ : http://www.rconnect.com/help
SALES : [email protected] [email protected]
------------------------------------------------------------
120 First Street NE PHONE : (507) 281-5005
Rochester, MN 55906 FAX : (507) 281-9272
----------------------------------------------------------------------
Date: Tue, 9 Mar 1999 18:48:44 -0800
From: James Lick <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
On Tue, 9 Mar 1999, David Gale wrote:
> Using /usr/dict/words on my linux box and the TCL code below I ran this
> attack against a sendmail (8.9.2) mailserver which uses virtual user
> tables and a lengthy aliases database.
The way your code is implemented, you send a RCPT and wait for a response
before sending the next RCPT. Due to latency, this algorithm is very
inefficient and results in not much load on the server. The "attack" in
question does not pause between RCPT commands, but rather sends them as
fast as possible and looks at the results later. Also it tries quite a
bit more the few thousand words in /usr/dict/words.
Jim Lick
----------------------------------------------------------------------
Date: Wed, 10 Mar 1999 21:42:44 +0100
From: Alexander Bochmann <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
Hi,
...on Tue, Mar 09, 1999 at 04:16:13PM -0600, Scott Fendley wrote:
> Couldn't you just compile sendmail with tcp_wrapper support, and have a
> script parsing your logs so that if someone manages to get n # of pokes at
> your system then their Ip address and/or DNS server will be placed in the
> hosts.deny.
Perhaps Spamshield could be enhanced to solve this problem.
http://www.abest.com/~kai/spamshield.html
Even if the detection is adapted, it would probably only work after the first
attack though, as it seems sendmail doesn't log the attacking hosts name
before the connection is closed when no data is sent.
Alex.
----------------------------------------------------------------------
Date: Wed, 10 Mar 1999 14:30:25 -0700
From: Tobias J. Kreidl <[email protected]>
Reply-To: Tobias J. Kreidl <[email protected]>
To: [email protected]
Subject: Re: SMTP server account probing
Scott Fendley said on Tue, 09 Mar 1999 16:16:13 -0600:
> Couldn't you just compile sendmail with tcp_wrapper support, and have a
> script parsing your logs so that if someone manages to get n # of pokes at
> your system then their Ip address and/or DNS server will be placed in the
> hosts.deny. Then as an admin you remove those that need to be removed
> after the problem user has been properly slapped or you could possibly run
> an automatic removal of k # of hours (or days).
I did this a year or so ago, using a shell script. Via a cron job, it can look every
10 minutes or however often you wish and if it sees an incoming mailbox exceeding a
certain size that has received email more than N times from a particular user, it
automatically puts an entry into /etc/hosts.allow (and since sendmail is run through
inetd, the effect is instantaneous). In this case, hosts.deny is empty, but you could
readily make the appropriate change to use hosts.deny, if desired.
It's one way to protect against mail bombings, as well. Right now, the code checks
if the mailbox (inbox) has exceeded a certain size before parsing for repetitive senders,
but it'd be trivial to change the code to skip the mailbox size checking by making
MAXSIZE equal to 1. Note that for systems with lotsof users and big inboxes, the
checking process can take up considerable time and CPU resources. Another caveat is that
if you have also "friendlies" that send from the same sending host, they, too,
will be blocked. This could be devastating for, say, email coming from somewhere like
aol.com, so I'd be very careful if and whether you actually use this code. Or, follow
Scott's suggestion of removing the entry periodically to keep legitimate email
>from bouncing. I wrote this more as an exercise and as a proof of concept and so it's
not been thoroughly exercised and may contain various "gotchas" I haven't even thought
about.
Tobias J. Kreidl, PhD
Email: [email protected]
#!/bin/sh -
#
# mailmonitor -- check if incoming mail boxes exceed a limited size; if so,
# check if mail originated from more than N from the same address, and if
# so, then block that host from being able to send mail until manually
# edited out. Tested under Solaris 2.X and freeBSD 2.X.
#
# TK 97-Jan-17
# updates: TK 97-Jan-20/21 (initial version)
#
# TK 97-Jan-27: Add list of host exceptions.
#
# TK 98-Apr-11 -- Use "From: " instead of "From " in search. Otherwise,
# MAILER-DAEMON can dominate in the "From " line. Grep out any possible
# trailing ">" in address.
#
# To do:
# Consider option to flush all mail in /var/spool/mqueue containing
# that entry.
# Add an option to skip checking specific accounts.
#
# Copyright (c) 1998 by Tobias Kreidl. Feel free to distribute this
# code provided this acknowledgment header remains. The user assumes all responsibilities
# for any use of this code and by using it, releases the author of any liabilities
# or other problems that might result from use of the code either "as is" or after
# any modifications are made to it.
#
PATH=/usr/bin:/usr/sbin:/usr/local/bin; export PATH
unalias rm
# name of this program (important for grepping purposes)... preferably,
# the same full path name as put in the cron entry...
PNAME="/usr/local/bin/mailmonitor"
# limit in bytes:
MAXSIZE=4000000
# limit of messages from one user:
MAXNUM=20
# full path to hosts.allow file:
HAFILE="/etc/hosts.allow"
# list of exceptions for receiving bulk mail (if none, set to "");
# separate the list items with spaces.
# You can exclude hosts you trust here, as well as possibly the
# machine itself on which this runs.
EXCEP="root@localhost mylocalmachine.mydomain.com"
# whom to send mail message reports to:
MAILTO="root, [email protected]"
#
# see if running -- never ever run more than one version of this
# routine at the same time !!!
PS="/bin/ps"
switch="-ax"
flag=`uname`
number="3"
if [ $flag = "SunOS" ] ; then
switch="-ef"
number="2"
fi
test=`$PS $switch | grep -v grep | grep $PNAME | wc -l`
if [ $test -gt $number ] ; then
echo "Another version of this routine is already running! Abort..."
exit 0
fi
uqname () {
# subroutine to return list of unique non-local email addresss of the
# mail in a user's inbox. Returned variable is UNAMES, which overwrites
# any previous definition.
name=$1
UNAMES=""
LOC="/var/mail"
UNAMES=`grep "^From:"' ' $LOC/$name | grep @ | awk '{print $2}' | sort | uniq`
}
mailcount () {
# subroutine to check frequency of occurrence of non-local email senders
# inputs: acount name, email_address_of_sender
LOC="/var/mail"
COUNT=0
name=$1
email=$2
# COUNT=`grep "^From $email" $LOC/$name | wc -l`
COUNT=`grep "^From: $email" $LOC/$name | wc -l`
}
# set initially so that multiple informational messages are not sent out
newinfo="no"
list=`/bin/cat /etc/passwd | awk -F: '{print $1}'`
for name in $list
do
# check size
echo "$name"
if [ -f /var/mail/$name ] ; then
size=`ls -l /var/mail/$name | awk '{print $5}'`
home=`grep "^$name:" /etc/passwd | awk -F: '{print $6}'`
# debug --
echo "home dir is: $home"
else
size=0
fi
if [ $size -gt $MAXSIZE ] ; then
# debug --
echo "Too big -- size is $size"
echo "" >>/tmp/LISTmonit$$
echo "email for $name overflowed with $size bytes: " >>/tmp/LISTmonit$$
# check box for multiple messages...
uqname $name
for addr in $UNAMES
do
mailcount $name $addr
# check for exceptions
test=`echo $EXCEP | grep -i $addr`
if [ XYZ$test = "XYZ" ] ; then
# process
if [ $COUNT -gt $MAXNUM ] ; then
# debug
echo "$addr has sent $COUNT messages."
echo "$addr has sent $COUNT messages." >> /tmp/LISTmonit$$
# see if already denied -- note syntax of string MUST be
# sendmail: this.organization.org: DENY
# for this to work consistetly!
sender=`echo $addr | awk -F@ '{print $1}'`
hostname=`echo $addr | awk -F@ '{print $2}'`
# eliminate possible trailing ">" 98-Apr-12
hostname=`echo $hostname |awk -F\> '{print $1}'`
echo "hostname is: $hostname"
test=`grep "sendmail: $hostname:" $HAFILE | grep DENY | awk -F: '{print $2}'| awk
'{print $1}'`
# debug --
echo "search yields: $test"
if [ XYZ$test = "XYZ" ] ; then
# this is a new entry...
newinfo="yes"
da=`date`
string="sendmail: $hostname: DENY # ($sender) $da"
# edit
/bin/ed $HAFILE <<EOF
0a
$string
.
w
q
EOF
else
# was already in the file
echo "host entry $hostname already denied..."
fi
# no, not an excessive number of messages from that user
fi
else
# address was an exception
echo "The address $addr is an exception ($COUNT messages received)"
fi
done
# looped through all excessively large mailboxes
fi
# looped through all mail users
done
# track and inform...
if [ $newinfo = "yes" ] ; then
# inform
LIST=`cat /tmp/LISTmonit$$`
da=`date`
/usr/ucb/mail -s "Mail OVERFLOWED" $MAILTO <<EOF
The incoming mailbox for the following account(s) exceeded the
limit of $MAXSIZE bytes on $da.
The following users have sent more than $MAXNUM messages...
$LIST
Entries have been made, denying sendmail access to the pertinent hosts
(the file $HAFILE should be reviewed for accuracy). Note that these
denials will remain until these entries are manually deleted.
This is an automated response.
EOF
else
# no need to send out mail -- nothing has changed
echo "No changes detected..."
fi
# clean up
rm -f /tmp/LISTmonit*
# or use "rm -f /tmp/LISTmonit$$" if you wish
exit 0
----------------------------------------------------------------------
Date: Thu, 11 Mar 1999 19:31:21 -0500
From: Peter W <[email protected]>
To: [email protected]
Subject: sendmail 8.9.3 patches to curb RCPT harvesters
Aleph One wrote:
> I am killing the spam address harvesting thread unless someone posts some
> actual code.
Per Joseph's suggestion. Use these patches against sendmail 8.9.3 and add
O RCPTFailDelay=30
to sendmail.cf to make sendmail sleep() for 30 seconds before reporting any
"550" errors. Set the value to 0 for "normal" behavior.
Note that RFC 1123 suggests RCPT responses be returned in less than 5 minutes
(if they're verified immediately -- 1123 allows verification of RCPT to be
deferred and notes that a "250" response does not guarantee the address is
legit). Eric Allman argues in doc/op/op.ps that sending SMTP agents ought to
wait an hour. Choose wisely.
This quick modification should at least frustrate current** RCPT abuse tools,
give admins more time to notice the failures in the maillog and react, and not
confuse mailers that legitimately send multiple RCPT commands to known
addresses.
-Peter
** Eventually I think sys admins would want to defer all RCPT verifications
until after the DATA transmission, erroring with 554 if there is a single
invalid RCPT address, to make SMTP username-harvesting visible. SMTP senders
would need to be sure they heeded RFC 1123 section 5.2.7 regarding the meaning
of a 250 response to RCPT.
--
Q: How could China track down and punish dissidents more effectively?
A: The new Pentium III chip! http://www.privacy.org/bigbrotherinside/
Intel doesn't care about your privacy. Join the boycott today.
$ diff -C 2 sendmail.h.orig sendmail.h
*** sendmail.h.orig Thu Mar 11 07:57:42 1999
--- sendmail.h Thu Mar 11 08:06:51 1999
***************
*** 1293,1296 ****
--- 1293,1298 ----
EXTERN int MaxMimeHeaderLength; /* maximum MIME header length */
EXTERN int MaxMimeFieldLength; /* maximum MIME field length */
+ EXTERN int RCPTFailDelay;
+ /* delay before report user does not exist to inbound SMTP commands */
extern int errno;
$ diff -C 2 readcf.c.orig readcf.c
*** readcf.c.orig Thu Mar 11 07:57:52 1999
--- readcf.c Thu Mar 11 08:15:29 1999
***************
*** 1532,1535 ****
--- 1532,1537 ----
{ "MaxHeadersLength", O_MAXHDRSLEN, FALSE },
#endif
+ #define O_RCPTFAILDELAY 0xab
+ { "RCPTFailDelay", O_RCPTFAILDELAY, FALSE },
{ NULL, '\0', FALSE }
};
***************
*** 2211,2214 ****
--- 2213,2220 ----
case O_MAXCHILDREN: /* max # of children of daemon */
MaxChildren = atoi(val);
+ break;
+
+ case O_RCPTFAILDELAY: /* delay before reporting user does not exist */
+ RCPTFailDelay = atoi(val);
break;
$ diff -C 2 err.c.orig err.c
*** err.c.orig Thu Mar 11 08:05:41 1999
--- err.c Thu Mar 11 08:12:58 1999
***************
*** 526,529 ****
--- 526,532 ----
eb += 4;
spaceleft -= 4;
+
+ if ((num != NULL) && (strncmp(num, "550", 3) == 0) )
+ sleep(RCPTFailDelay);
/* output the file name and line number */
----------------------------------------------------------------------
Date: Sat, 13 Mar 1999 01:47:58 -0500
From: Tim Pierce <[email protected]>
To: [email protected]
Subject: Re: sendmail 8.9.3 patches to curb RCPT harvesters
On Thu, Mar 11, 1999 at 07:31:21PM -0500, Peter W wrote:
> Aleph One wrote:
>
> > I am killing the spam address harvesting thread unless someone posts some
> > actual code.
>
> Per Joseph's suggestion. Use these patches against sendmail 8.9.3 and add
>
> O RCPTFailDelay=30
>
> to sendmail.cf to make sendmail sleep() for 30 seconds before reporting any
> "550" errors. Set the value to 0 for "normal" behavior.
According to the reports I'm seeing, GeoList Pro does not wait for a
response from the server -- instead, it streams the RCPT TO commands
continuously and then reads the results at the end of transmission.
If that is the case, it doesn't sound like this patch will have any
effect.
--
Regards,
Tim Pierce
RootsWeb Genealogical Data Cooperative
system obfuscator and hack-of-all-trades
----------------------------------------------------------------------
Date: Sat, 13 Mar 1999 10:59:16 -0500
From: Peter W <[email protected]>
To: [email protected]
Subject: Re: sendmail 8.9.3 patches to curb RCPT harvesters
Tim Pierce wrote:
> On Thu, Mar 11, 1999 at 07:31:21PM -0500, Peter W wrote:
> > Per Joseph's suggestion. Use these patches against sendmail 8.9.3 and add
> >
> > O RCPTFailDelay=30
> >
> > to sendmail.cf to make sendmail sleep() for 30 seconds before reporting any
> > "550" errors. Set the value to 0 for "normal" behavior.
>
> According to the reports I'm seeing, GeoList Pro does not wait for a
> response from the server -- instead, it streams the RCPT TO commands
> continuously and then reads the results at the end of transmission.
> If that is the case, it doesn't sound like this patch will have any
> effect.
(1) It will slow down your server's responses to GeoList, et al. Set the delay
to 60 seconds and a 5000 word attack could take 83 hours to send the responses
they need (assuming they don't run parallel attacks, and sendmail already has
means to limit such attacks).
(2) sendmail logs the RCPT failure notices via syslog as soon as it sends them
to the client.
Which is why I said the changes would "frustrate current RCPT abuse tools, give
admins more time to notice the failures in the maillog and react". If the
attacker thinks it's worthwhile to wait for the response codes, and you're not
watching your log files, then you're right, these changes won't help you much.
Also I said "current... tools" because a more intelligent harvester could
compare the delay rates of "250" and "550" responses and learn when to time out
and assume the RCPT failed. To get around this you'd need to make a simple
change so that sendmail had a deliberate delay before *all* RCPT responses; that
doesn't seem warranted yet, and would slow legitimate mail delivery. See my
previous post for comments on RFC 1123 and deferring verification.
-Peter
--
Q: How could China track down and punish dissidents more effectively?
A: The new Pentium III chip! http://www.privacy.org/bigbrotherinside/
Intel doesn't care about your privacy. Join the boycott today.
----------------------------------------------------------------------
Date: Sat, 13 Mar 1999 11:36:32 EST
From: Andy Church <[email protected]>
To: [email protected]
Subject: Re: sendmail 8.9.3 patches to curb RCPT harvesters
>> Per Joseph's suggestion. Use these patches against sendmail 8.9.3 and add
>>
>> O RCPTFailDelay=30
>>
>> to sendmail.cf to make sendmail sleep() for 30 seconds before reporting any
>> "550" errors. Set the value to 0 for "normal" behavior.
>
>According to the reports I'm seeing, GeoList Pro does not wait for a
>response from the server -- instead, it streams the RCPT TO commands
>continuously and then reads the results at the end of transmission.
>If that is the case, it doesn't sound like this patch will have any
>effect.
It should work fine, because (1) sendmail won't process anything while
it's sleep()ing, and (2) GeoList will stop sending data when the socket
buffer fills up (because sendmail isn't reading from it).
--Andy Church
[email protected]
http://achurch.dragonfire.net/
----------------------------------------------------------------------
Date: Sat, 13 Mar 1999 13:36:47 +0100
From: [email protected]
To: [email protected]
Subject: Re: SMTP server account probing
On Wed, Mar 10, 1999 at 02:30:25PM -0700, Tobias J. Kreidl wrote:
...
> echo "" >>/tmp/LISTmonit$$
> echo "email for $name overflowed with $size bytes: " >>/tmp/LISTmonit$$
> # check box for multiple messages...
...
> # clean up
> rm -f /tmp/LISTmonit*
> # or use "rm -f /tmp/LISTmonit$$" if you wish
> exit 0
hehe.. not to be too sarcastic.. but on big boxes this wouldn't only lead to
high cpu usage but under certain circumstances also to root compromise..
typo
----------------------------------------------------------------------
Date: Sun, 14 Mar 1999 15:46:52 +0000
From: Kerb <[email protected]>
To: [email protected]
Subject: GLPro.exe spam fix
This is not a complete fix, but it will work until something better comes along.
Take a look at http://www.cana.net/~kerb/sendmail.html for all the details.
-Kerb
If your domain was one of the 4200+ domains hard coded into that new spam program that hits your mail server for active email address, this will fix it. It is a ruleset that
goes in your /etc/sendmail.cf file. I have tested this on my machine running sendmail 8.8.7-20.
Scheck_mail
R$* $: $>3 $1 focus on the host
R$* <@ $+. > $* $1 <@ $2> $3 strip trailing dots
R$* <@ $+ > $* $: $2 isolate the host
R$ . $+ $+ $: $2 strip subdomains
Rwhynot.com $#error $@ 5.7.1 $: "We don't accept mail from you, asshole."
Do this once more for "@savings.com". There are a few versions of this program going around, and so far the reported "MAIL FROM" addresses have been
[email protected], [email protected], and recently, [email protected]. I am guessing that you the reader are not admin on either of those domains, so it would be a
good idea to add this into your sendmail.cf, after all, why should users on savings.com and whynot.com be sending mail FROM your mail server?
Note: This does NOT stop them from dumping the requests on you and sucking up resources, but it DOES keep them from getting valid addresses. Here is a sample
SMTP session with my server:
MAIL FROM:<[email protected]>
553 <[email protected]>... We don't accept mail from you, asshole.
RCPT TO:<root@localhost>
503 Need MAIL before RCPT
And it stops them there... they can get no further. It appears that these MAIL FROM addresses are HARD-CODED into the program, although I cannot confirm that.
As long as they are, you can keep blocking them as they appear. Or better yet, if you know the sendmail configuration well enough to block all MAIL FROM's that do
NOT match your system, then block it there.
This code is by no means a complete fix, but it does stop them from getting any valid email addresses whatsoever. That is the good news. The bad news is that it
doesn't stop them from dumping requests on you and sucking up bandwidth and resources. If you know enough about sendmail configuration to tweak the above code to
automatically disconnect them (or maybe intentionally "forget" to send the FIN packet and make them have to wait for their end of the socket to time-out [idea a la
BugTraq!]) when they try using a MAIL FROM with whynot.com or savings.com, please E-Mail me! [email protected]
`