Subscription form attack

What to do when someone abuses your "confirm mail" facility?

[perkoch]

We are using a *nix/Perl program called Post Office Pro 4.0 for administrating subscriptions and mailings for our newsletters. It has its quirks, but mostly does what it is supposed to do. The program has never been misused by hackers trying to use our mail gateway to send out spam.

In order to stop people form signing up other subscribers than themselves, we have implemented an autoresponder that sends subscribers an confirmation request mail. Subscribers have to click on a special link in this mail to be added to the database.

During the last couple of weeks someone has started using this feature to send a large number of confirmation mails to various existing and non-existing AOL addresses, i.e. they fill in the form repeatedly with the same AOL address, and our program faithfully sends a confirmation request mail to these addresses. Needless to say, our mailbox is filled with AOL error messages, and we have got complaints from AOL members getting dozens of such confirmation request mails from us.

We are having difficulties seeing why someone would abuse our system in this way. It could be that we have enemies we do not know of, people who are trying to get our IP addess banned from AOL, but that's a wild guess.

We have checked our logs and do find the relevant mailings. Here's one example (we have altered the name of the newsletter):

209.110.70.11 - - [23/Oct/2002:12:39:53 -0600] "GET /cgi-local/post/manager.pl?email=[e-mail]&group1=Name_of_newsletter HTTP/1.0" 200 11714 "-" "-"

The IP address changes every now and then: 216.78.250.82, 209.110.70.11 etc.

First of all: Are there anyone of you who have experienced anything similar?

Also: Is there a way to stop such abuse?

We are grateful for any comments.

[Dreamquick]

<humour>
And not getting AOL visitors is a *bad* thing?
</humour>

Most of my suggestions assume you can control the behaviour of the program in some way or other...

1) If the IP is pretty consistent for a number of requests and then changes why not consider putting in a rule which says a single IP can only ask for a signup once per N hours?

2) Have you tried reverse dns lookups or whois on the names to figure out if they are all from the same organisation or potentially coming through proxies, or if you put each ip into your browser do you get a website appearing? (In other words can we see a pattern? If so you might be able to stop them)

3) If all else fails add an extra stage before you send that mail - create random text in an image and ask the user to enter the text then submit the form. As only humans can see the text and write it down this will stop the bots.

4) If you make any forms use the POST method rather than the GET method it makes programming stuff to mess with them a fair bit harder. (Trust me on this one - a monkey can program a bot to do GETs but it takes a lot more effort to program a bot to do POSTs)

5) Make the script which sends data to the mail-out script generate a one-way hash (md5?) of the input data. Next make the mail-out script check this hash against the input data, if the do not match then do nothing. As long as you use a combination of input elements and fixed text when you generate the hash then it will make it really hard for them to fake that hash!

- Tony

[edited by: Dreamquick at 3:43 pm (utc) on Oct. 27, 2002]

[Key_Master]

You can stop it but it will require some modification to the script. One way you could stop the abuse is to encode each E-mail address.

Example:

Subscriber submits E-mail address. Script encodes E-mail address and passes the encoded variable to the autoresponder. Subscriber confirms subscription by clicking on the link in the confirmation E-mail. Script decodes E-mail address and verifies it's authenticity.

So:

/cgi-local/post/manager.pl?email=[e-mail]&group1=Name_of_newsletter

would look like:

/cgi-local/post/manager.pl?email=3435336572676440616f6c2e636f6d-15&group1=Name_of_newsletter

Everything else gets tossed.

[andreasfriedrich]

4) If you make any forms use the POST method rather than the GET method it makes programming stuff to mess with them a fair bit harder. (Trust me on this one - a monkey can program a bot to do GETs but it takes a lot more effort to program a bot to do POSTs)

A perl monkey´s GET request:

$ua->request(GET 'http://www.ac.com/?age=14&cool=yes');

A perl monkey´s POST request:

$ua->request(POST 'http://www.ac.com/', [age=>14, cool=>'yes']);

Not that much more of an effort ;)

Andreas

[Dreamquick]

...and there I was adding my #5 when you beat me to the punch key master!

Personally I prefer adding a one-way hash rather than a simple encoding scheme as there are only so many common encoding techniques around and theoretically you could just scan them all until you broke the scheme you were using (since encoding is a two-way process rather than just one-way so you can get the data out of it if you know what you are doing).

Also I kind of like the idea of messing with their heads by making it very clear what the new protection scheme is because I know full well that unless they got access to the source they will not be able to crack it without a great deal of effort. :)

- Tony

[Dreamquick]

andreasfriedrich,

I turn my back to make a counter post and someone finds a fault in my logic - it shows that I'm not a perl user don't it? :)

You're absolutely right that POST requests are *really* easy if you know how (or have good toys), but due to the seemingly aimless nature of what they are doing I wouldn't class them as professionals and so I thought it was more likely to be a simple bot / script which would be limited to GET requests without some changes to the code.

- Tony

[edited by: Dreamquick at 4:08 pm (utc) on Oct. 27, 2002]

[Key_Master]

You can scramble or add varibles to an encoded E-mail address to make it virtually impossible to crack. I added a check variable to the example in my previous post. Can anyone tell me what it was (it's pretty simple).

But, I think I misread perkoch's original question. We need to eliminate multiple submissions to the same page. I think a simple cookie would do the trick. Simply put- no cookie, no treat and only one treat per cookie.

[Dreamquick]

{dreamquick raises his hand}

Ohhh! Me Sir! Me Sir!

Did you turn the characters into their hex values and also add a counter onto the end containing the number of characters?

Other answers to the orignal question include logging the email addresses being used and denying repeat emails for X hours - personally I wouldn't trust cookies to provide me with a sense of security, especially if the attackers know their stuff.

<added>
There are moments like this when I think an official IRC channel for certain forums would be a really good idea. Real-time conversation rather than post, read, reply delays.
</added>

- Tony

[perkoch]

Thank you all! While we were sleaping on the other side of the Globe, you have been coming up with all these great suggestions! We will bring the suggestions to the attention of the people who make the program we use and I am sure we will be out of the woods in no time.

[Mark_A]

perkoch you say it is to maintain and sign up subscribers to a newsletter and that:

"they fill in the form repeatedly with the same AOL address"

Surely some improvement in the back end would solve this, for example only one request for inclusion to any email address * ever * repeated requests are denied.

Plus perhaps log IP and program id for each request into a db to gain evidence on perps ... look for duplicates and select .. then contact their ISP with evidence and get their dial ups removed.