|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200101122051.f0CKpuN16056@sam.julianhaight.com> Date: Fri, 12 Jan 2001 15:51:00 -0500 Reply-To: btpost@MAIL.JULIANHAIGHT.COM From: btpost@MAIL.JULIANHAIGHT.COM To: BUGTRAQ@SECURITYFOCUS.COM Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David F. Skoll wrote: > > SpamCop (http://spamcop.net/) has a service which operates as follows: [snip] > Unfortunately, the URL generated in step (2) contains a fixed prefix > followed by an incrementing sequence number. A spammer therefore needs to > send one innocuous e-mail (to a friend at spamcop.net?) from a real e-mail > address to get the initial sequence number. He then spams everyone at > spamcop.net while his shell script calls "lynx" with > repeatedly-incrementing sequence numbers. > > Fix: Spamcop should add (for example) a random 16-byte cookie to each URL to > make it harder to guess. Spamcop now uses an MD5 hash of a secret combined with the sequence number (emailid) to create a unique, cryptographically challenging CRC which must be supplied in conjunction with the original ID number. Old "release URL": http://spamcop.net/release?i=4545096 New "release URL": http://spamcop.net/release?i=zf14f97b165461b0128332e50556a24bez4545096 This system is still not as secure as it would seem at first, since the secret used in the hash is always the same. This provides a wider base for a brute-force attack. > Status: Weakness reported to SpamCop a week ago; no response yet. I had not planned a fix for this "bug". I had been aware of it for many moons (hell, I knew it was a weakness when I originally coded it). However, it didn't seem important for a few reasons, the biggest is simply spammer psychology. No spammer in their right mind would do what David suggests. People with spamcop accounts are *not* good targets for spamming, since most of them rabidly report spam to the originating ISP by using spamcop's one click (tm - blech) reporting system. Furthermore, spammers are exploiters of bandwidth. They try to maximize throughput by expending as little bandwidth per message as possible. They use open relays and multiple rcpt-tos per message. In the proposed attack, the spammer generates a bunch of new emailids. However, their messages will still be sparsely spread throughout a much larger forest of other spammer's email and legitimate mail. So for instance, if the spammer sent a group of messages, s/he might have to release 100 times as many messages in order for s/h/it's messages to get through. From a spammer perspective, this is a collosal waste of time. However, the denizens of bugtraq are not so concerned with bandwidth or throughput. As soon as I heard this 'bug' had been posted to bugtraq, I knew I needed to fix it soon, or some 31133+ h4x0r would be releasing all my member's mail to "prove" the bug exists. For the record: anyone who tries to release email in bulk will be reported as an abuser to their ISP. Emailids which predate this fix are releasable without the increased security, since the 'challenge' emails have already been sent for those messages. Any new messages received will require the enhanced release code. All messages are purged within one week, so the vulnerability will work out of the system gradually. - -=Julian=- btpost@mail.julianhaight.com (SpamCop admin) -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBOl9uLpWmJaclF7J1EQKbGACg+0EQ5/wzPYF6RzQM5QZOxOv5kgsAn0kt pDdtL7LoyKi4/rM82x+mg5Pt =2hCR -----END PGP SIGNATURE-----
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |