we need to integrate new password algorhythm ASAP

i just provided an online demonstration of an exploit in xtorrent module to it's author.

in the demonstration i obtained his admin uname, password hash & email address.

scarey? well not as scarey as the fact it took 2 seconds, yes 2 seconds to decrypt the md5 hash back to plaintext.

i then logged in using the decrypted plaintext pass.

i created a custom block from admin, with info of the demo.

http://www.unseen.org.au/

i have not done anything serious to the site, and the owner does now accept that sql injection is a major cause for concern. & he is aware of my access.

really if it took 2 seconds to decrypt the hash to plaintext and login, then we really need to push the new password encryption branch into 1.1 ASAP. in fact it's a security necessity..

Attach file:

---

  snapshot3.png (0.00 KB)

Good idea. Suggest also adding a password salt to make hash cracking more difficult when users choose a weak password, as no hash algorithm can protect against dictionary attacks.

I looked into this for xoops a while back. I could be (badly) wrong, but it looked like a new algorithm could be substituted in directly without any large code changes. The main issue was what alternative hashes are widely shipped with php.

The salt could be set in the installer, and also shouldn't require much changes beyond that.

the new password branch in svn uses 2 salts to hash the password with and then the final password +2salts is hashed using sha256.

it's basicly (broken down)




that's a very basic description.

each of the salts is 64 characters long they are added to the pass_plain which is md5 before adding the salts.

then sha256 the result.

basicly sha256 is now hashing a 160 character password.

i don't think that can easily be bruteforced or decrypted. lol

This all seems so nostalgic... I could swear this has been discussed and ignored before.

@vaughn, hilarious.

not ignored here tho will :)

the branch is active and complete except for 1 minor issue, once that issue is resolved, the new password system is good to go. and will not be a problem either for existing users, as i've already taken those into consideration.. ;)

Cool :)

If I understand this correctly it really highlights the need to have a set of modules, on sourceforge, that have been tested and validated for amongst other things security vulnerabilities such as this.

How is the average user supposed to track all of this? This is important work that Vaughan has put forth and highlights the complexities of a project like this. How do we make it a little bit simpler for people using Impress?

Seth

Good point Seth.

I think there is an opening for an internal security alert system in Impress Admin....

Hi Vaughan, I also informed him about the problem, but in other modules.

Quote:

Look this date 2008/2/12.

I was now being restored on suggestion of improvement he had sent to him. After this message I looked at the module and found other problems that could lead to the involvement of the site.

But unfortunately, after this message, he not returned me more. No word changed after this. When you talk with him, please ask about and he can confirm what I am speaking.

ps: I am tired of suffering attacks. But I always respect when someone discovers a vulnerability and tells me where you are and how to fix. If all people were so, the hackers would not have a good life.

The problem is that today is creating a University of hackers and they are earning money from this.

About integrate new password algorhythm, is necessary, but...

http://www.php.net/manual/en/ref.mcrypt.php


This function now in version 5 is native and can be used on a large scale. Provê a method of using very strong and robust. In the past she had great depêndencias on the operating system, but I feel that in today it is already in better versions of php5.

In many security sites have heard very well for their use as a key that does not allow feedback and works with 128bits.

Now I have a real problem in complex and both suggested this function, as the use of this new approach proposed Vaughan I will not advance in anything.

Case Real

- The hacker invades the site and amending configs of xoops.
- This change is minimal, is only one escape "> within this.
- From now he knows where the door is and will use it combined with other things and will pass unnoticed.

Although the server may have a reasonable safety, "there is no 100% secure server," will be very difficult to find it. Even if today there is no flaw in the code of impresscms, the site will be invaded.

The reason is the lack of filtering the output. Most of the things is to not allow the entry of malicious code, but there are several things to be done during a search or query. It is not enough just to verify the data entry, we need to evaluate the output of data with urgency.

XoopsToal is offline and will be transferred to another server. Everything that is stored in the database must be verified. This data base has more than 220mb of information and is not an easy task.

Quote:

I still think there is a need to have a review process where new modules/versions are examined against a list of the most common vulnerabilities. Modules/versions that 'pass' the evaluation could be marked with a 'security audited' logo or something like that (also, we could publish a page on exactly what this means - ie. what the audit covers). Apart from reducing the number of incidents it will help module authors learn and avoid future problems.

I'd be happy to help out with this later on. Just sitting down to audit security of my first module now Would it be worth trying to put together a list of stuff to check or did someone do that already somewhere?

Yet another reason for moving towards php5...

Zaphod - I'm sure any help of this nature would be appreciated!

Again - this is something else we can use the idea of the icsm_header for - both for QA test status, and also together with a version-like function for updating the users in case of discovered security issues.

sorry, off-topic:

my reply here:

http://www.xoops.org/modules/newbb/viewtopic.php?post_id=285183#forumpost285183

copy content here, if deleted.

Hi wishcraft, Vaughan, JAVesey and all xoopers.

The issue here is advise the developer on the problem and this is completely ignored.

It is a pity that in my paiz not have a person who honestly tell me about a security point where is the problem and proposing a solution.

This is independent of cms being used. But there is a real difference in this aboradagem, verification of entry and verification of removal.

In this case, the module allows the failure to inject the malicious code, that is a fact and is proven.

The developer corrects this problem very quickly. But this does not guarantee that will be safe. The reason is the output of data. The hacker has prevented at the time the module has failed to deploy another code to extract data and using a javascript common?

The answer to this is the way to check the output of data. At this point there is a differential in favour of xoopscube and xoops and impresscms are still vulnerable.

What I am talking here is based on our experience in suffering with this type of problem, because we already know of some practices used by crakers and idiots who insist on trying misrepresenting the house outside.

Total agreement with you!

i agree Giba, although myself and wishcraft got off to a bad start, we are both now amicable towards each other, we both over reacted, me so because when trying to help someone I was deemed a bad person simply because of who I am and my relationship to ICMS.

However I hope that this history can be cleared up.

As i have just proved, security issue aside. When people collaborate & help each other, everything moves more fluently aswell as calmly.

Security has to be a high priority. Up until yesterday I had never attempted or even knew how to properly inject SQL into a url. But since starting with ImpressCMS, I have done some reading, and it seems that my reading is paying off slowly.

You can't properly secure something unless you understand how SQL injection works and XSS, this is what I am currently learning in my own time. and yes I also agree it is far better when someone who hacks your site, tells you exactly how they did it, a demonstration shouldn't be needed, but it is more helpful to know why that exploit works, once you know the why's, it is far easier to protect from it. But saying that, it can be difficult to spot a vulnerability by looking at code, so essentially, we need tools to help aswell. a cracker/hacker is a great tool because it's a real person who you can talk with (providing they are willing to offer assistance).

and assistance I will also give to Wishcraft should he require any. afterall, it's the users who suffer most when these kinds of exploits get attention from the wrong people & ICMS, XOOPS, XC, Joomla etc are nothing without their users.

@giba: the new password algorhythm uses the PHP 5 native hash('sha256', $password); function.

but there's a fallback standalone script if php5 hash function is not detected, as will be the case for PHP 4 users. so both PHP4 & 5 users will not have any problems.

Very, very thanks Vaughan.

Even using the translator I could fully understand their words. I think you did a great job of writing this message.

I fully agree with you on all terms, especially when you tried to warn the origin of the problem of security.

On the question of 'sha256' native in php5, really, you are right too.

I am sure that your value to the team, if it continues impresscms is specializing in security will be of great value and their recognition will be immense for the whole community. We know that a person of this responsibility in charge of a sector very critical and we all know this.

Now remain very concerned about the issue when we already have something recorded in the database and exit via consultation could prove comprometedores data and also allows the server to expose new codes malíciosos with no currently fails.

The issue of protecting the output is quite preocupando me because we could not solve the problem and also because this code is constantly destroying our database.

Anyway, thank you for service to community and I know give value to an information of this nature. I am also studying a lot to not schedule wrong, but I agree that a tool of verification is important and vital.

Thanks Giba, I'm glad the translation was ok :)

as for your concerns about cleaning output & input, If my concept works with the html purifier branch, then i'm pretty sure that will be a huge benefit to the security of icms.

At the moment i have ideas and thoughts in my head and i can see an end result of what I want to achieve, but i am having a hard time getting those thoughts out of my head and into written word so that I can give everyone a picture.

I will try to write a blog this weekend and get my thoughts on screen in a clear & understandable manner in order for translations to be more accurate so that you can understand better..

Another place to look at for username/password security is banners.php - it has separate functions for clients and client logins that get stored in another table.