I won't tell you specifically how it is done, but you can inject the POST_PAYLOAD subject with the correct BCC string to make it work. I watched a site get injected with over 500 aol email accounts. It worked like a champ, right before we purged their queue. The worst part, once the script-kiddies find out your site is open, they do it without ever hitting your site. They just send the right HTTP string with a post payload configured and your site is SPAMming the world.

That's why this contact module was invented for XOOPS. It will take care of those issues along with the proper security codes. You, the admin, control how secure your contact form is!

First, thanks for your input Seventhseal and Dave_L.

Quote:

A quick glance shows no but I don't think it needs to be because:



So the user cannot influence what goes into the subject.

Quote:

I've tried but there is obviously a way. To the core team: are there any plans to incorporate/use the xoops.idbleeming.com contact us module?

I'll have a look at the above module and try to incorporate the changes into the existing contact us module to strip out the injection at least. Seventhseal, are you willing to provide me more info (via PM) on this injection technique for the patch? I do think it is important that the current contact us module be as tight as possible in this regard. Failing that, it should be dropped and replaced with the xoops.idbleeming.com module instead.

Thanks all and Cheers.

McNaz

Just to add some more info ...

I just took a look at the attempts to hack my contact form. In each case, the attacker is inserting a "Bcc:" into the subject or body fields. Those are the only fields (in my case) that accept user input.

I don't have my script handy, but if I recall correctly, I either delete all non-text characters in the subject, or replace them with spaces, which prevents injection of headers.

The body content should be less important, since it's preceded by a blank line that indicates the end of the headers. That's assuming the content-type is text. If the content-type is HTML, then you'd have to watch out for web bugs, abusive script, etc.

Thanks for the additional info David_L. I'll wait till I hear from Seventhseal until I proceed on this.

Cheers.

McNaz.

Sent you an example - don't run it, because even if you think it doesn't work, you will want to look at your queues...

I would imagine that when the new version of XOOPS comes out, I will incorporate, and maybe XOOPS will incorporate officially

Two usefull links :
http://securephp.damonkohler.com/index.php/Email_Injection
http://www.jellyandcustard.com/2006/02/24/email-header-injection-in-php/

Dasdan carried out a hack to be protected from these attacks by the form of contact.

Download hack , replace juste the index.php file.

Thanks for the example seventhseal. Very interesting.

I've had a look at it and still cannot see how it can work for two reasons, at least on the version of the contact form I have (my understanding could also be limited ).

1. The injection sample you sent me is over 100 characters in length, which will not get accepted by the contact form as the fromEmail field is limited to 100 characters.

2. A way around this would be to construct your own $_POST array and submit that. That, however, will be stopped by Xoop's token security system:



Sorry to keep posting back but I am just trying to establish the degree of vulnerability of the contact module (version index.php,v 1.12.12.1 2005/10/28 00:48:31 skalpa Exp)

Thanks for everyone's input and time.

Cheers.

McNaz.

Quote:

If I was thinking straight I would have tried a shorter example... I will test further.

I don't want to teach hacking - but here's a clue.

Most "script-kiddies" do not use your form. They know what the payload looks like, and send the HTTP transaction through some other type of script (php maybe) or programatically to get the data sent.

What it really comes down to is two fold. Any developer developing a form should do as much checking as possible. For the most part, this would require something like javascript to do real-time. Then, when validating post data, you must be able to validate each field for "real" values and be able to stop processing when errors are found.

Another key to hacking any form is understanding that the php processor can be overloaded. So, if you see someone hit your site many many times within the same minute, that is what they are trying to do. Cause an overflow.

As you examine the POST payload I sent you, pay attention to the hex codes included and inserted between command functions. Anything that slips through testing will trigger your phpmailer to do exactly as told.

Another example is taking the payload I gave you, and converting all characters to chr() type hex codes.

Ultimately, these types of form injections are harmless unless your code is really bad at validation. Most of these scripts that are run are posted on the onzyou type sites. Sometimes theya re way out of date. Be aware, once they find a hole, they will start picking to ultimately rootkit your box and own you! Good luck, it's a great learning experience, but nothing more.