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 "savior@savings.com" and has now been seen as info@savings.com. In a newer version it has been changed to tandy@whynot.com. 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: 02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO: 02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO: 02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user 02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user 02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user 02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO: 02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user 02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user 02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user 02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user 02:24 16:22 SMTPD(00360110) [209.86.182.86] RCPT TO: 02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user 02:24 16:22 SMTPD(00360110) [209.86.182.86] ERR 954access.net invalid user To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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: user@example.com" 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 To: BUGTRAQ@netspace.org 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: info@earthonline.com - 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 : hostmaster@earthonline.net customerquality@earthonline.com sales@earthonline.com info@earthonline.com rick@earthonline.com lyle@earthonline.com audrey@earthonline.com 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 (gvs@rinet.ru) [http://gvs.rinet.ru/] ---------------------------------------------------------------------- Date: Tue, 9 Mar 1999 13:51:28 -0700 From: Brett Glass To: BUGTRAQ@netspace.org 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: Valdis.Kletnieks@VT.EDU To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org Subject: Re: SMTP server account probing >>>>> "Brett" == Brett Glass 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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: rrpermeh@rconnect.com   rrpermeh@resinc.net     IS Engineer       WEB   : http://www.rconnect.com http://www.response.net Rural Connections /   HELP  : help@rconnect.com       Response Inc.        FAQ   : http://www.rconnect.com/help                          SALES : sales@rconnect.com sales@resinc.net ------------------------------------------------------------ 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 Reply-To: Tobias J. Kreidl To: BUGTRAQ@netspace.org 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: Tobias.Kreidl@nau.edu #!/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, info@anotherhost.org" # # 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 < To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 achurch@dragonfire.net http://achurch.dragonfire.net/ ---------------------------------------------------------------------- Date: Sat, 13 Mar 1999 13:36:47 +0100 From: typo@INFERNO.TUSCULUM.EDU To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 savior@savings.com, info@savings.com, and recently, tandy@whynot.com. 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: 553 ... We don't accept mail from you, asshole. RCPT TO: 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! kerb@cana.net