'Invitation' to hack joomla site 1.5 - 3.1.1

[Viktor Iwan]

Hi Guys,
probably some of you might have notice this...
http://seclists.org/fulldisclosure/2013/Jun/149

it just launch to the public and now, even newbie hacker get invited to test this security hole....

what quite bugs me is when i looked at the history:

# History
2013.05.11 Vulnerability reported to the vendor
2013.05.12 Vendor asked for details
2013.05.12 Details and exploit provided to the vendor
2013.05.30 Asked vendor about the status of investigation (no response)
2013.06.11 Sent another mail to the vendor (no response)
2013.06.15 Full disclosure

a month of no responses ??
should we get worried ? no ?

[Donald Gilbert]

This is the first I've seen of this. I wonder if Nick Savov of the JBS has seen this? He'll have to respond to say whether or not.

First off though, the assertion that "the attacker must only know the beginning of the username of the victim" is wrong. Due to the way serialization works, the part in the report that says ';s:12:"the_us' is incorrect. You must know the full length of the username and then replace 12 with the length of the username and adjust for 32 characters. It's not as "simple" as the reporter would have you to believe. Ever since Joomla 3.0, it is the recommended practice and even a step in the installation process to use a different username than simply "admin" so I would say that just from that, the majority of the sites running on 3.0 or later are more protected than a site running say, 2.5. As long as they don't go around spouting their username. :)

Secondly, you have to steal the remember me cookie for the logged in user. This is not an easy task, as there are not (to my knowledge) any known XSS vulnerabilities in core. Definitely not in the Platform or Framework (but applications built on top of them could unknowingly introduce an XSS vulnerability).

Finally, this does not apply to 1.5 as described in the report. While the methods in 1.5 are similar, they are not the same, and as such following the directions on a 1.5 site will get you nowhere. Now, it may be that a similar 1.5 exploit is just as straightforward with some modifications, but it's definitely not something a "script kiddie" could execute.

I really don't know why JBS hasn't responded to this. Even if they had replied once with "we're working on it" it may not have become publicly known so soon. But 1 month is very fast from discovery to full disclosure, so I'm not sure who to blame.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[brian teeman]

Just to be clear this is NOT a JBS task but a JSST task.

[Donald Gilbert]

Well in that case then I'm not sure why the JSST failed to respond with a simple "we're working on it" multiple times.

Is there anyone even on the JSST? I've never heard or seen anyone say they are. Who's the head of it that can explain the negligence?

On Wed, Jun 19, 2013 at 8:58 AM, brian teeman <joom...@googlemail.com> wrote:

Just to be clear this is NOT a JBS task but a JSST task.

[Michael Babker]

On Wed, Jun 19, 2013 at 9:03 AM, Donald Gilbert <dilber...@gmail.com> wrote:

Is there anyone even on the JSST? I've never heard or seen anyone say they are. Who's the head of it that can explain the negligence?

The bottom of every release notice on joomla.org talks about active JBS and JSST personnel.

[Donald Gilbert]

http://developer.joomla.org/security.html

That doesn't give any names. It just says "contact the JSST"

--

[Michael Babker]

Right, because the JSST as a whole is the POC for all security vulnerabilities in Joomla code.  There is no single individual who is the POC for all security issues.  As I said, the list of personnel active in JSST at the time of a release is listed on each release notice on joomla.org.

[Donald Gilbert]

I'm just wondering why it was never addressed. Since there was never a response to the inquiries, we now have a publicly disclosed vulnerability on a list that I'm sure hackers monitor. Now every Joomla site out there is vulnerable to an extent, although as I explained earlier it's not as bad as it seems.

So, if someone from the JSST would care to respond and explain what the thinking was behind it, it would be appreciated. I don't know, maybe they never received the emails and it's time to update the way security notifications are handled. Maybe the discloser is lying and he just posted it because he felt like it, without ever notifying. Maybe he notified and got a response, but lied saying that he didn't to make his actions appear justified. Who knows? Someone on the JSST does.

[Mark Dexter]

Because people on JSST are busy and sometimes make mistakes, I guess.
On the other hand, is it fair to blame the JSST because someone
decides to go public with a security issue? Would you go public
because you were frustrated waiting for a response, or would you try
to find out what was going on? I wouldn't go public and I don't think
most members of the community would go public in this circumstance.
Imo it is irresponsible and childish. ("You're not paying enough
attention to me, so I'm going to do something to force you to,
regardless of the consequences.")

So, while the JSST should have responded sooner, I think we should be
clear about who is responsible for their actions. If the JSST had
acted more promptly, it is possible that this disclosure would not
have happened. However, the JSST is NOT responsible for this
disclosure, the person who disclosed is.

Mark

[brian teeman]

On Wednesday, 19 June 2013 15:42:21 UTC+1, Donald Gilbert wrote:

http://developer.joomla.org/security.html

That doesn't give any names. It just says "contact the JSST"

I dont even see that or how to actually contact the JSST any more.

There used to be a prominent form 

In addition iirc joomla signed up to an agreement to respond to security reports within a certain time period etc  - cant find that link now either

 

On Wed, Jun 19, 2013 at 9:25 AM, Michael Babker <michael...@gmail.com> wrote:

On Wed, Jun 19, 2013 at 9:03 AM, Donald Gilbert <dilber...@gmail.com> wrote:

Is there anyone even on the JSST? I've never heard or seen anyone say they are. Who's the head of it that can explain the negligence?

The bottom of every release notice on joomla.org talks about active JBS and JSST personnel.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Nikolaos K. Dionysopoulos]

Hello all,

We're developers. Let's leave the politics (who's to blame) aside and let's consider the technical aspect (how to fix it). I think this is what matters now that the disclosure is out there.

Despite the difficulty of the attack, it is still feasible and not entirely difficult to launch IF the attacker has the cookie. The username of an administrator is easy to discover on sites with front-facing components which display the username, from forums and ticket systems to social components and even galleries. The username is not treated as a secret and, if you ask me, shouldn't be treated as such. But even if it's not known the small unknown portion of the first block and the very fast algorithm (XOR) used allow for easy brute force attacks, even with plain PHP code.

So, how do we fix it? We need a stronger encryption algorithm. Sadly mcrypt is not universally available and even when it is available not all encryption algorithms are. We need something that can be implemented in PHP, it's relatively fast and fairly secure. We already have an implementation of AES-128 running in CTR (Counter) mode in pure PHP, included in the restore.php (the AKEncryptionAES class) used by the Joomla! Update component. FWIW the same class also provides AES-128 en-/decryption in the much better CBC (Cipher Block Chaining) mode, but this requires mcrypt. Do note that CBC and CTR are the two block cipher modes recommended by cryptography experts (something that I am not).

I could make AKEncryptionAES into a Platform class and submit a patch for Joomla! 2.5 and 3.1 to use it for the remember me cookie, but someone with more crypto experience than yours truly would have to verify that I'm not doing something stupid. If the JSST or JBS members are interested, you know how to get in touch with me. I could provide a patch for 3.0 in a matter of 24-36 days, maybe less. The only drawback would be that existing "Remember me" cookies are invalidated, but in the grand scheme of things I think that's acceptable.

Cheers,

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Donald Gilbert]

Obviously the discloser is responsible for disclosing. I'm not continuing the conversation just to make people feel bad. That's not the purpose. If it's true that the JSST is busy (which I'm sure it is) and if it's true mistakes can be made (lord knows I make them all the time) then maybe it's time to consider a review of the process. Maybe a new Joomla application project (like the new Tracker) that can take security reports and has autoresponders and all the bells and whistles, instead of an email based system.

Security is definitely something we are going to have to manage on the Framework once it gets it's first public release. A unified system for that would be nice.

[Donald Gilbert]

I would prefer bcrypt. It might be worth getting in touch with Anthony Ferrara. He wrote the new password_hash() methods for PHP 5.5 and there's a compatibility layer available for previous PHP versions. Additionaly, he has a very strong reputation in the security arena, and would be able to offer great insight and possibly a simple yet effective solution.

So all in all I think there are a couple things to review. The security reporting process as well as how do we deal with the issue at hand.

[Viktor Iwan]

Hi guys, i consider my self as an integrator... So at the moment, eventhough we still have to life with this issue... In scale 1-10 (1: no worries - 10: danger issue)... What would you choose ?

Is there any feature beside 'remember me' that using JCryptCipherSimple ?

If you take a look at the history, there was a quick respond from the vendor (joomla).. Any idea who give the respond ? Probably he/she has strong reason to not put this issue on tracker...

[brian teeman]

Security issues are never put on the public tracker

[Herman Peeren]

Just some small technical remarks:

• bcrypt is a hash, but we are here talking about a two-way algorythm (something that is encrypted but is intended to be deciphered too).
• the two-way algorithm in the remember-me cookie is astonishing simple. I had wondered about that for some time. Anybody that has seen Joomla's code for this knows, that it is not something new.
• Nic proposes to use a better two-way algorithm that is available in Joomla now, so we can fix this issue asap. Of course we can look at even better long term solutions, but in the mean time a fix might fulfill a need.
• the vulnerability only needs the beginning of the username and the length of it (but the latter can be "brute forced" by looping through different possible lengths)
• the user doesn't have to be logged in to get the remember-me cookie, for that is also stored on the user's computer after the session is finished. You can also run a program on that computer which has total access to the cookie store; some free app or something that can do that job... Even when you are offline.
• although this security leak by itself might not be so very big, a very tiny hole can be enough to get powertools like WSO or C99 shell or something comparable on board of a site to be hacked, after which you can intercept all traffic,  can change any file and, what I see as a trend in malicious hacking atm: remove your traces as much as possible.
• maybe in the long run we should rethink the necessity of a two-way storage of that username and password in that cookie. Wouldn't a hash that is replicable on the server be better?

- Herman

[Denis Ryabov]

I'd replace current md5-based hash

О©╫

$privateKey = JApplication::getHash(@$_SERVER['HTTP_USER_AGENT']);

О©╫

to something like a concatenation of md5 and sha1 hashes:

О©╫

$seed = @$_SERVER['HTTP_USER_AGENT'];

$secret =О©╫JFactory::getConfig()->get('secret');

$privateKey = sha1($secretО©╫. $seed) .О©╫md5($secretО©╫. $seed);

О©╫

As a result, key length is 72 characters that should be sufficient to encrypt remember-me data.

О©╫

О©╫

-------

Best regards,

Denis Ryabov

[Herman Peeren]

Here is an older posting related to this issue. Not something new, that the remember-me cookie is so weakly encrypted:
http://jeffchannell.com/Joomla/joomla-remember-me-cookie-encryption-issues.html

[Donald Gilbert]

Our current implementation requires a two-way algorithm, but I question the necessity of that.

For a short term solution, the easiest thing to create an announcement instructing users to disable the Remember Me plugin.

--

[Denis Ryabov]

BTW, in J!2.5 and 3.x the remember-me cookie is sent with HttpOnly flag, so it's impossible to get it using XSS in most of browsers.

 

19.06.2013, 23:07, "Herman Peeren" <herman...@gmail.com>:

Here is an older posting related to this issue. Not something new, that the remember-me cookie is so weakly encrypted:
http://jeffchannell.com/Joomla/joomla-remember-me-cookie-encryption-issues.html

 

--

[Herman Peeren]

Sorry, i reacted to your posting, but thought that you were talking about the way passwords are stored. That is not the case, I jumped to conclusions to quickly. So I deleted my posting. Sorry.

Your proposal is about the key that is used to encrypt the the username-password-string in the cookie. You propose that a block of 72 chars is used, so everything fits into it.... that doen't sound unreasonable (unless the 32-bytes block would be a result of the encryption algorythm used). 

[Nikolaos K. Dionysopoulos]

Dear Don,

Even though disabling the plugin is a valid short term solution from a developer's point of view, from the site owner's it's not. Not when users expect to log in to the site's front-end and not just browse the site as guests. That and the fact that nobody really reads the announcements make this, in my opinion, a non-solution.

Nicholas K. Dionysopoulos

[Herman Peeren]

On Wednesday, 19 June 2013 21:23:14 UTC+2, Donald Gilbert wrote:

Our current implementation requires a two-way algorithm, but I question the necessity of that.

+100!

On Wednesday, 19 June 2013 21:23:14 UTC+2, Donald Gilbert wrote:

For a short term solution, the easiest thing to create an announcement instructing users to disable the Remember Me plugin.

+1

So we now have:

• the very short term action: warn users that it might be safer to be a bit careful with that remember-me plugin. 
• the relatively short term fix: to encrypt the cookie a bit safer; be it Nic's proposal or Denis'or one still to come.
• the longer term issue of how to solve this securely, questioning the need of a two-way encryption
• the current procedures for security issues in Joomla and how they could possibly be improved.
  

[Donald Gilbert]

Nic, you can log in as a user and browse as a logged in user without the remember me plugin.

[Donald Gilbert]

I've been speaking with Anthony about this, and at first he facepalmed and wondered why. Then he helped me come up with a valid solution to the problem. I'm putting together a POC and it doesn't require using external libraries.

The approach would basically just store a random 32 bit token as the login cookie, and then grant access to the site based on that token. This is just as secure as using regular PHP session cookies.

--

[Nikolaos K. Dionysopoulos]

I know :) On busy sites the session is deliberately short-lived. Not having the remember me plugin means that repeat visitors will have to retype their username and do they complain! It's even worse on some support sites where people are quick to assume that you banned them instead of checking if they are logged in...

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Donald Gilbert]

Thankfully I don't have to deal with those types of.. ehem.. users. :) Good point though Nic. I hadn't thought about that.

Also, correction on my previous post. The approach would store a 32 _byte_ (256 bit) token as the login cookie, and then grant access based on that.

We would generate the token using the already present JCrypt::genRandomBytes() and call it good. Hopefully Anthony comes by to back me up.

[Anthony Ferrara]

Donald and all,

On Wednesday, June 19, 2013 3:49:55 PM UTC-4, Donald Gilbert wrote:

I've been speaking with Anthony about this, and at first he facepalmed and wondered why. Then he helped me come up with a valid solution to the problem. I'm putting together a POC and it doesn't require using external libraries.

The approach would basically just store a random 32 bit token as the login cookie, and then grant access to the site based on that token. This is just as secure as using regular PHP session cookies.

A bit more info here.

The token should be a 256 bit (32 byte) random token. I looked at JCrypt::genRandomBytes() and it should be good enough for this purpose. 

Basically, every time there's an account change (password change, etc), you should regenerate that token. Then, you can send said token to the browser straight away in a cookie prefixed by the userid.

When "logging" in a user via the cookie, you just check to see if a userid is in the database with the token. Then, if it is, get the token from the database.

This step is important. Using a Timing safe comparison algorithm, compare the submitted token with the one in the database. This is necessary to prevent leaking timing information from the database (and hence information about the real token):

http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-timing-attacks-on-php-applications-time-to-take-them-seriously/

There's code there, and on my blog here (mine is licensed WTFPL): http://blog.ircmaxell.com/2012/12/seven-ways-to-screw-up-bcrypt.html

There really isn't any other "quicker" change that I would be comfortable recommending. Passwords should never leave the system (even encrypted), so killing the current method with fire is likely going to be your best approach...

Anthony

[Troy Hall]

This is like closing the barn door AFTER the horses are out but....

if JSST needs a email donkey then I'll volunteer.  I'm almost constantly @ the pc/phone and could easily setup "alarms" specifically for JSST.  Then if there is an urgent issue I could do w/e the rules tell me to do.

Bear

[Fernando Cassia]

On Wed, Jun 19, 2013 at 12:11 PM, Mark Dexter <dexter...@gmail.com> wrote:

On the other hand, is it fair to blame the JSST because someone
decides to go public with a security issue? Would you go public
because you were frustrated waiting for a response, or would you try
to find out what was going on? I wouldn't go public and I don't think
most members of the community would go public in this circumstance.
Imo it is irresponsible and childish. ("You're not paying enough
attention to me, so I'm going to do something to force you to,
regardless of the consequences.")

Sorry Mark, but that is the way the "security industry" works. Kiddies build their "reputation" on security circles by "finding holes". The bigger the target, the bigger the "badge" (virtual badge, at least) they get from their peers.

So "I found a huge hole in (say,Oracle's Java)" gives them more peer recognition than "I found a hole in this other blogging host written in COBOL that nobody uses".

And "I let them know and they did nothing" is just what they need to claim that the developer doesn't know what it is doing, and how much brighter the "exploit finder" is (in their mind, anyway).

The whole system is flawed, and don't expect them to act of the interest of the common good, they're just interested in themselves, and buidling their "reputation" as hackers...

This is just my opinion based on previous exploits of known software for the last few years...

FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario
- George Orwell

[Viktor Iwan]

@fcaasia, i half agree with you... but this loophole finder/hacker/younameit... has done proper code of conduct... he explain his theory (although it might be wrong). he contact the vendor first (joomla) before a full disclosure...  i think he is 'a friend' and we just had miscommunication with him...
a simply reply "we are working on this.. please don't disclose it' will stop him to publish it

No need to point finger now, we're joomla (= as a whole)

i hope there will be new security release of J3, J2.5 (and hopefully J1.5)...

[Goyat LLC-吉田憲人]

+1

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! General Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-gene...@googlegroups.com.
> To post to this group, send an email to joomla-de...@googlegroups.com.
> Visit this group at http://groups.google.com/group/joomla-dev-general.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--

---
Goyat LLC, Yokohama, Japan
Norito H.Yoshida 吉田憲人

"Happiness is a perfume you can not pour on others
without getting a few drops on yourself."

幸福は香水のごときものである
人に振りかけると
自分に必ずかかる

[Nick Savov]

Looks like the form and agreement got lost in the new developer site move.
I'll try to track down what's needed for the JSST page and get that setup
on developer.joomla.org. Thanks for the notification, Brian!

Kind regards,
Nick

[elin]

It was addressed, he just got impatient, which was fair, but it's not like there wasn't back and forth.

Elin

[Donald Gilbert]

All,

I've been working today on a solution to this, and have come up with one that does away with our practice of storing the credentials as a hashed cookie and then decrypting them to login the user. It was a lot more involved than I originally had expected, but it does work quite well. The downside of this approach is that it does invalidate all current remember me cookies, but that is a small price to pay for the increased security.

The patch I have has been tested and works against the current CMS master. Here's the git compare so you can see what changed: https://github.com/dongilbert/joomla-cms/compare/rememberMe

The approach I took is very similar to what Anthony was explaining earlier. I'm using our JCrypt class to generate a strong 256 bit key and then combine that with the logged in username, and then encrypt that and use it for the value of the login cookie. The cookie is stored using a hash for the name. (specifically, JApplication::getHash('JLOGIN_REMEMBER'), this way it's unique per site)

Once a user's session expires from them being away from their computer for longer than the allotted session time, the next time they come back and refresh the page, the Cookie Authentication Plugin automatically logs them in. Within the onAfterInitialize method of the Remember Me plugin, the system checks that the person viewing the site is a guest, and then checks for the presence of a remember me cookie. If one is found, it decrypts the cookie value in much the same way the credentials are currently decrypted, explodes that result on the first ':'. The first item in that resulting array is the username, and the second item is the originally generated 256 bit token. It then passes the username and the fully encrypted token (the stored cookie value) as the credentials to $app->login($credentials). This is where the Cookie auth plugin takes over. It checks the database for a loginToken associated with the provided username, and if one is found, it completes a timing safe comparison between that known value and the value presented by the cookie. If they match it's a valid login and all is well.

You can test this by cloning my fork of the joomla-cms repo (github.com/dongilbert/joomla-cms) and then checkout the rememberMe branch. Perform an installation and then login using the sidebar module. Be sure to check the "Remember Me" box. :) After that, you can wait around until your session expires and then just refresh the page to see that you are still logged in. However, I found that to be too slow. There's a faster way to check and that is to temporarily comment out line 760 of legacy/application/application.php (the line that invalidates the JLOGIN_REMEMBER cookie). Once that's commented out, you'll see that no matter how many times you click log out, it simply doesn't work. Well, it does work, but the Cookie authentication plugin is immediately logging you back in during the onAfterInitialize plugin event.

There's still some work to be done to it, like adding it to the other sql install files and maybe moving some things around (the timingSafeCompare() method might need to move somewhere), but I just want to make sure that you all agree that this is a valid method and that it does address our concerns.

Finally, I must say I was a little doubtful of authenticating a user based on the value within a cookie, but then I realized that PHP does so an every single request. This approach is just as secure as (maybe more?) PHPSESSID.

Thanks again for the help on this today Anthony.

[Websiteconcepts]

Great work Don coming up with this on such short notice, thumbs up

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

[Herman Peeren]

My only objection to the current implementation (and Anthony's story) is that the cookie is now stored in the db. That makes it very insecure: for with a SQL-injection (or other way to maliciously retrieve info from the db) you can now login as any user whose cookie is stored in the db. I don't agree that that is "just as secure as using regular PHP session cookies", for they are only stored during the session, whereas those remember-me cookies are by default valid for a year and are not only available for logged in users. A safer solution would be to regenerate the token based on a combination of things in the db and some other source (for instance the "secret" from the config-file).

BTW an attack using the cookie as it was would be done via the (hacked) client computer. Storing the token in the db adds another attack-possibility (to retrieve the info via the db) while not securing the hole the client's computer very much. So the insecurity possibilities are increased, not decreased. Very good thing is to not store the password client-side, but the crappy "encryption" that is used for that is even worse. Not so much because of what is now presented as the hack (that you only need the first part of the username), but more because the key is just an MD5 of the HTTP-User-agent... which is a very limited set of strings. If the password is not stored in the cookie, that cannot be retrieved. But still the attacker can just login using that cookie.

- Herman

[Herman Peeren]

Please don't mind the second paragraph of my last posting too much, for that is mainly saying that if a client's computer is hacked a remember-me-login can never be safe.

The main point is in the first paragraph: never store info in the db with which it is possible to login (or create a cookie to login). Only use info from the db to generate a similar hash as was sent by the client. And that hash can for instance be generated using the config-secret (or get another extra key in a similar, non db way).

- Herman

[piotr_cz]

It has been set with HttpOnly flag since 3.10:
https://github.com/joomla/joomla-cms/commit/4de5b0c4f23a3ab3ba9731deb5a28b80e06119fb

On Jun 19, 9:23 pm, Denis Ryabov <drya...@yandex.ru> wrote:
> BTW, in J!2.5 and 3.x the remember-me cookie is sent withšHttpOnly flag, so it's impossible to get it using XSS in most of browsers.
>
> š

>
> 19.06.2013, 23:07, "Herman Peeren" <herman...@gmail.com>:
>
> Here is an older posting related to this issue. Not something new, that the remember-me cookie is so weakly encrypted:http://jeffchannell.com/Joomla/joomla-remember-me-cookie-encryption-issues.html
>

> š--

> You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

> To unsubscribe from this group and stop receiving emails from it, send an email tojoomla-dev-gen...@googlegroups.com.
> To post to this group, send an email tojoomla-d...@googlegroups.com.
> Visit this group athttp://groups.google.com/group/joomla-dev-general.
> For more options, visithttps://groups.google.com/groups/opt_out.
> š
> šš
>
> š

[Denis Ryabov]

It was backported to 2.5 as well (I don't know exact version, but HttpOnly is set in 2.5.11).

20.06.2013, 11:13, "piotr_cz" <pkoni...@hotmail.com>:

> To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

> To post to this group, send an email to joomla-de...@googlegroups.com.
> Visit this group at http://groups.google.com/group/joomla-dev-general.
> For more options, visit https://groups.google.com/groups/opt_out.

--
С уважением,
Денис Рябов

[piotr_cz]

The 'secret' key is/was used as a salt in JApplication::getHash:
https://github.com/joomla/joomla-cms/blob/master/libraries/legacy/application/application.php#L902

I don't see a problem that the login token is stored in DB.
So are (hashed) user passwords. I mean - when attacker gets access to
DB, it's over, finito.

> > an MD5 of the HTTP-User-agent... which is a *very *limited set of

> > strings. If the password is not stored in the cookie, that cannot be
> > retrieved. But still the attacker can just login using that cookie.
>

> > *- Herman*

[Herman Peeren]

On Thursday, 20 June 2013 09:56:03 UTC+2, piotr_cz wrote:

I don't see a problem that the login token is stored in DB.
So are (hashed) user passwords.

There is a big difference: if you maliciously get info from the db, you cannot log in with that at the moment. The hashed passwords cannot be used to log in. But the stored token, as is proposed now can.

SQL-injection is one of the most used and easiest forms of attacks and with all those extensions available for Joomla, there is quite a chance this will occur from time to time. If the gain is that you can easily log in as superadministrator, there will be an increase in SQL-injection attacks, for sure.

[piotr_cz]

Maybe the solution could be to make the loginToken useless without
knowing the secret key (that's stored in configuration file)?

[Herman Peeren]

On Thursday, 20 June 2013 09:56:03 UTC+2, piotr_cz wrote:

The 'secret' key is/was used as a salt in JApplication::getHash:
https://github.com/joomla/joomla-cms/blob/master/libraries/legacy/application/application.php#L902

I didn't just mean that the 'secret' key should be used, but that information not in the database (like that 'secret' key) should be used to further proces the information stored in the db.

In the case of Don's proposal: if the token is stored in the db the way it is now, then the cookie should store that token hashed with for instance the 'secret' key. When the cookie is used for authentication,  the token for that user is first hashed with the 'secret' key and then compared with what comes from the cookie.

[Herman Peeren]

On Thursday, 20 June 2013 10:27:52 UTC+2, piotr_cz wrote:

Maybe the solution could be to make the loginToken useless without
knowing the secret key (that's stored in configuration file)?

YES, that is exactly what I mean (and had typed in my reply before seeing this).

[Nikolaos K. Dionysopoulos]

In this case you're going back to the lack of passable reversible (symmetric) cryptography. The cookie would have to store the token encrypted with the secret key. The site would then unencrypt it and looks for the (unencrypted) token in the database.

EDIT: I see that Herman is also saying the same thing.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Denis Ryabov]

What about this way:

 

1. Generate random token.

2. Generate random salt.

3. Store "salt:token" in cookies. 

4. Store token and md5(salt.token) in the database.

5. The plugin checks that token exists and salted token is correct too.

 

-------

Best regards,

Denis Ryabov

 

 

20.06.2013, 12:38, "Nikolaos K. Dionysopoulos" <niko...@gmail.com>:

[Thomas PAPIN]

Maybe a "stupid idea " but

The current issue is possible due to : 

The used key is 32 characters long. The first block to encrypt is thus:
a:2:{s:8:"username";s:12:"the_us

Should not be possible to replace 

$rcookie = $crypt->encrypt(json_encode($credentials));

with something like
$myrandomvalue = uniqid();
$rcookie = $crypt->encrypt($myrandomvalue."|||||".json_encode($credentials));

and in remember plugin:

$str = $crypt->decrypt($str);

$str2 = substr($str,strpos('||||||'));

$cookieData = json_decode($str);

That is a short term solution ?

2013/6/20 Denis Ryabov <dry...@yandex.ru>

[Herman Peeren]

Yes, that is a good way too! In fact, what I said about storing some extra information with which to generate the server-side hash, is then stored in the cookie. Brilliant.

[Herman Peeren]

No, sorry, that is not a solution (nor short nor long term):
1. it is not a matter of the string to be encrypted being too short, but the key.
2. in fact that was allready a non-item for the key is so weak (limited possibilities) that it is easily decrypted anyway.
3. the real problem is, that the password is stored in the cookie in a decryptable (symmetric) way; that is solved by Don's proposal.

I think the problem is solved if we adjust Don's proposal to add a hash produced from the db-stored token, as is suggested in some postings here (and of which I like Dennis' suggestion to store the salt and the token in the cookie most).

- Herman

[Nikolaos K. Dionysopoulos]

No, this is bad.

• MD5 is a weak hash. See hashcat, whitepixel or john the ripper
• Storing the salt in the cookie defies the purpose of using a salt in the first place

Storing the salted MD5 and salt in the database is equivalent to storing a second password for the same user account which is equally susceptible to brute forcing as the user's own password. This can be mitigated by using a very long password which contains characters from a large character set (256 bits would be great), making it impractical to attack it with a brute force attack. But this also violates the initial attempt to not store a password (encrypted or not) in a cookie.

However, what is not addressed in any of these solutions (including what I proposed yesterday) is:

• Preventing log ins with this cookie from an untrusted browser, e.g. if the cookie is stolen. Anyone who has the cookie has access to the account. Since most sites run over plain HTTP and site owners do tend to use unsecured WiFi networks in public locations the possibility of cookie theft is not too low to consider.
• Allowing a user to use the Remember Me cookie from multiple devices, e.g. a laptop and a mobile phone. Setting the remember me cookie on one device would nullify it on the other device.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Allon Moritz]

Perhaps it is worth to check out how the other guys did id (WP, Drupal). Perhaps this topic at SO can help to find a solution http://stackoverflow.com/questions/244882/what-is-the-best-way-to-implement-remember-me-for-a-website. Sorry I can't add more to this topic as my knowledge is too basic :-(

[Herman Peeren]

Good points, Nicholas. I agree with most, but not that "Storing the salt in the cookie defies the purpose of using a salt in the first place". It is common practice to send a salt and a hash together; for instance when sending a nonce with the password in Digest Authentication. Of course MD5 can be replaced by a slower algorithm. The points about stealing the cookie are of course also applicable to the current situation (and to a symmetric encryption you suggested earlier).

- Herman

[Nikolaos K. Dionysopoulos]

Yes, of course. I meant that in the context of using MD5 hashes it defeats the purpose, as an attacker could easily create a suitable salt and token to match the MD5 hash. He'd essentially use the MD5 as the known hash, the salt as the known salt and treat the token as the unknown password, then use a password cracking application against it.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Anthony Ferrara]

Herman, et al,

On Thursday, June 20, 2013 2:39:46 AM UTC-4, Herman Peeren wrote:

My only objection to the current implementation (and Anthony's story) is that the cookie is now stored in the db. That makes it very insecure: for with a SQL-injection (or other way to maliciously retrieve info from the db) you can now login as any user whose cookie is stored in the db. I don't agree that that is "just as secure as using regular PHP session cookies", for they are only stored during the session, whereas those remember-me cookies are by default valid for a year and are not only available for logged in users. A safer solution would be to regenerate the token based on a combination of things in the db and some other source (for instance the "secret" from the config-file).

If I am not mistaken, session tokens are stored in the database as well. So if an "attacker" can get into the DB, they can access all active sessions as well...

If you're really concerned about this (honestly, I would be more concerned about the SQLi vectors you describe), you could MAC the token in the cookie with your site-secret:

    $cookie = $user . ':' . $token . ':' . hash_hmac('sha256', $token, $siteSecret);

That would mean that getting the token wouldn't be enough, they would also need to get the secret key from the server side.

But I must warn you, this ONLY will make things more secure if you're using a cryptographic secret for the siteSecret. This is something very non-trivial for the average developer to do, yet alone the average user. You're now requiring the server to hold cryptographic material. This is not trivial...

 

BTW an attack using the cookie as it was would be done via the (hacked) client computer. Storing the token in the db adds another attack-possibility (to retrieve the info via the db) while not securing the hole the client's computer very much. So the insecurity possibilities are increased, not decreased. Very good thing is to not store the password client-side, but the crappy "encryption" that is used for that is even worse. Not so much because of what is now presented as the hack (that you only need the first part of the username), but more because the key is just an MD5 of the HTTP-User-agent... which is a very limited set of strings. If the password is not stored in the cookie, that cannot be retrieved. But still the attacker can just login using that cookie.

Let's make one thing clear. If an attacker gets onto a users computer, it's already game over. There is literally no way for you to prevent *any* form of attack that comes from or involves the users computer. That's why protecting against XSS is such a critical task, because if the attacker can get JS onto the page, you can't stop what they are going to do from there. Likewise, if an attacker can get at the browser of the user, they can do anything as well... 

Additionally if a user can get access to the network between the user and the server (say by hijacking a router), they can do anything the user can do as well (since they can spoof IP addresses, and execute a MITM attack). That's why SSL and SSLONLY cookies are vital for any semblance of security.

And to be fair, I am suggesting to remove the cipher from the current patch (and have done so here: https://github.com/dongilbert/joomla-cms/commit/3580aec9b9aeebcaef45177967ae8245ba51a555#commitcomment-3467046 )...

Anthony

[Herman Peeren]

Hi Anthony,

I totally agree with you, BUT... there's always a BUT ;-)

Of course it is much more important to avoid SQLi vulnerabilities than to mitigate the effects of it. But Joomla is a base system in which anybody can just plug in any extension. Thousands of those extensions are freely available and there is NO or hardly any control on their security. Only when a vulnerability is known (when maybe allready installed on thousands or even millions of websites) they are reported on the Vulnerable Extensions List (VEL). It is hard to do it differently, although it maybe an idea to start setting up testing for safety that must be passed before an extension is officially published on the Joomla Extensions Directory (JED). But then extensions will still be published. It's the ecosystem of extensions that makes Joomla big, vivid, popular. And those extensions are not very much under control of being safe. Number one attack vector is SQLi. One thing is sure of a succesful attack: public opinion sees it as a vulnarability of Joomla itself when a Joomla website is hacked, even if the vulnerability was in a 3rd party developer's extension.

That is why I think that Joomla's core should do some extra effort to mitigate the effects of attacks as much as possible. Or at least: when some extra security can be easily added, why not do that. And in that respect I was saying: don't store all info with which you can login with any user account in the database. We could even extend that principle to the session cookie, but for the remember-me cookie it is even more important as that cookie is by default valid for a whole year and even more important: not just valid when the user is just logged in at that very moment.

- Herman

[Donald Gilbert]

Thanks for all the great feedback guys. 

I've read every post and made what I think are some meaningful changes that address your points. The login token stored in the cookie now consists of the username, the token, and then an additional string consisting of the encrypted website secret. These three items are then separated by a : into a string and base64_encoded for safe storage in the cookie. Additionally, the full login token is no longer stored in the database. The token stored in the db consists of the username : token that is then base64_encoded for safe storage in the db If an attacker gets db access, the loginToken's stored there are useless for granting access.

The authentication process remains more or less the same, with adjustments made to account for the changes in the stored tokens.

See the changes here: https://github.com/dongilbert/joomla-cms/compare/rememberMe#L3L668

--

[Herman Peeren]

Grrreat! Thank you Don.

Just one remark: Base64 is only to make it not human readable, but from a security point of view it is the same as not encrypted. So it is not right to say "base64_encoded for safe storage". In the cookie you don't need any encryption (as Anthony also said in his last posting), so base64 is allright. Just don't call it " safe storage". In the db it is the same as not encrypting the token and username together, but just store the plain token (which is allright too). If you want to put the token a little bit more secure in the db, then you should hash it with that username (and do the same hash with the token you get from the cookie).

So: it is allright, but I just want to make a point about what you communicate about Base64.

Thanks again.

- Herman

[Donald Gilbert]

By "safe storage" I meant that since we are using JCrypt::genRandomBytes(32) to create the token, there's the possibility of it containing a : - so exploding on : would be an issue.

[Herman Peeren]

On Thursday, 20 June 2013 17:04:15 UTC+2, Donald Gilbert wrote:

By "safe storage" I meant that since we are using JCrypt::genRandomBytes(32) to create the token, there's the possibility of it containing a : - so exploding on : would be an issue.

That sounds good, but I only don't understand $db_token = base64_encode($response->username . ':' . $token); in https://github.com/dongilbert/joomla-cms/commit/1d914f46b31b3c6a97c1bf4525a4ca22b41e4faa#L0R670 then. For after decoding it still is the token with the possible ':', isn't it? Or do I misunderstand you?

[Donald Gilbert]

When I decode, I limit the explode to 2 parts. So it just breaks it at the first : instad of at each.

But I'm working on a simpler fix as well. New code pushed up shortly.

[Donald Gilbert]

And new code has been pushed.

The notable changes in this round is that the cookie auth plugin is now limited to only working when trying to login via cookie. Additionally, I now check the validity of the MAC in the cookie auth plugin, instead of in the remember me plugin.

Finally, this still protects the user so that even if an attacker were to gain access to the db and get the tokens, they would not be able to use those tokens in order to log in. They still need the MAC, which is the hash_hmac('sha256', $token, $siteSecret). And that's the real issue, since our greatest attack vector is SQL based attacks from vulnerable extensions.

So, test it up! Make sure it works, please. And then we can get this in for 3.1. I'm sure we'll need to port this to 2.5 as well.

[elin]

Overall I think there is an  important decision to be made about encryption in general, and it is  one I would like to hear from people on this list specifically about, which is whether to mid release cycle raise the minimum to 5.3.7 so that we can use bcrypt (with a fallback for sites with lower versions). This wouldn't break anything short term for existing sites because I think it should be approached as only being done for security reasons and keep b/c on everything else but in the end some time in the next two years it's just inevitable that something will slip in.  

So I see actually four options
Stay on 5.3.1 and add a strong recommendation for 5.3.7 to the technical requirements

Stay on 5.3.1 and in addition add a warning on install.

Move to 5.3.7 officially but don't stop installation for 5.3.1-5.3.6

Move to 5.3.7 and stop installation for anything lower.

Thoughts?

Elin

[Donald Gilbert]

Considering that 5.3.27 is set to be released in a few weeks as the last "scheduled" 5.3 release, I think it would be entirely reasonable to raise the minimum version to 5.3.7, if not higher. We have 5.3.10 as the minimum for the Framework due to the many security fixes in that version.

[brian teeman]

Changing the minimum level mid release is a poor decision

Allowing installation on a version that means the install is insecure is a terrible decision

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[elin]

What the framework does doesn't have any particular relevance, it's a totally separate project as indicated by the fact that it upped the minimum,  There will always be new releases, the question is about likely impact on extension developers, site implementers and end users.

As many people know I was for a 5.4  minimum for the 3 series on the basis that by the time we got to Joomla 3.5 php 5.3 would be EOL and given the original release schedule I was pretty close to the mark. We're going to be supporting 3.x for a long time, long after most new users will be on 5.5 .  That said, in my opinion, the minimum requirements are a contract just like the apis are.  That means it's possible to break them but only for very good reasons. And if you are going to break them do it earlier rather than later.

I will say also that my feeling is that used judiciously the CMS does have a lot of market power meaning that Joomla users will push hosts to upgrade if they get a strong security message in particular. And that's good for everyone. 

Elin

Changing the minimum level mid release is a poor decision

Allowing installation on a version that means the install is insecure is a terrible decisionha

[brian teeman]

On Thursday, 20 June 2013 23:27:16 UTC+1, elin wrote:

I will say also that my feeling is that used judiciously the CMS does have a lot of market power meaning that Joomla users will push hosts to upgrade if they get a strong security message in particular. And that's good for everyone. 

Elin

Sadly the number of hosts that still havent followed and disabled magic quotes shows that much as we think they should follow they dont 

[elin]

An large number did get pushed up to 5.3 though. If we stopped installation when magic quotes is enabled it would make people take notice.  That's the crucial difference I think.  But you have to choose your battles.

Elin

[Amy Stephen]

Don Gilbert - Many will benefit from your work. Here's hoping they will never learn just how much you helped them. Well done.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Mark Dexter]

As far as options, I would say still allow PHP 5.3.1 and (a) use
bcrypt if it is available (in other words, if using 5.3.7 or later)
and otherwise code remember me the most secure way we can; (b) advise
people to use 5.3.7 and, if they can't, not to use remember me. If
someone ignores our advice and gets hacked via this vulnerability, at
least we tried to warn them.

Does that seem like a reasonable approach?

Mark

[Donald Gilbert]

The version of "Remember Me" that I wrote and have linked to on this thread is entirely safe and secure on any version of PHP >= 5.3.0.

I don't think it's reasonable to say that those on PHP < 5.3.7 just should use Remember Me, especially when we have a secure version available for them to use right here.

[Mark Dexter]

My bad. I misunderstood and thought there was an issue with the
remember me fix and 5.3.1. So, if we're good to go on that, I don't
see the necessity to up the PHP minimum. As for the general issue of
password hashing, my understanding is that simply by going to sha1 and
doing a few other tricks, we can be miles ahead of where we currently
are.

Mark

[Donald Gilbert]

In my opinion, the project should move to 5.3.7 "officially" but not stop installation on 5.3.1-5.3.6. If a user is trying to install on a version lower than 5.3.7, then they should receive a _strong_ warning about the risks involved and link them to the bugfix list in 5.3.7 (http://php.net/ChangeLog-5.php#5.3.7) and maybe point them to some blog posts about vulnerabilities known in earlier versions.

However, that's somewhat aside the point from this thread. Maybe start another thread with the 4 options you listed out, and ask for feedback from the community. Community interaction, teaching and listening can go a long way towards the goal of educating the community about the issues. Maybe Joomla could contact all the major component and template providers and ask them to do a news post about why their users should move to hosts that provide at least PHP version 5.3.7.

Lots of options to consider.

And thanks Amy - I do appreciate your kind words. Hugs and unicorns. :)

On Thu, Jun 20, 2013 at 5:47 PM, elin <elin....@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Donald Gilbert]

Mark, 

There's definitely a lot we can be doing for storing passwords better. Our current approach has been around for a while and there have been a lot of advancements in that arena. It's something that I think we need to for sure work on and have settled by the first 3.5 beta. I don't see it as a pressing issue for 3.2 though.

On another note, it should be said that there isn't necessarily a problem with our implementation of JCryptCipherSimple, sometimes there are perfectly valid uses for a two-way algorithm. So I don't think we should necessarily deprecate that class, we just need to be conscious of where and why we have chosen to use it. The only reason it was useful for exploiting the Remember Me cookie was because it was rather trivial to guess the first 32 characters of the serialized login cookie.

[Pirateking Captjay]

Holy crap!!! My site has been down since March... I have been trying to fix it. My hosting co, can't or won't help, here i was blaming them for lack of php and mysql updates...that were badly out of date. I was in the process of upgrading from 1.5 to j2.5 when it got hacked as well as the server it self on 2 joomla sites that i know of. I finally gave up todays ago and moved what i had left of it from jxml on my pc to the my new hosting co... nearly 2 years down the drain!

[elin]

Really the question i asked is totally separate from the remember me issue.  It's important for encryption across the board, and this just pushed me to ask a question that I have had.

ELin

>> >> email to joomla-dev-general+unsub...@googlegroups.com.

>> >> To post to this group, send an email to
>> >> joomla-de...@googlegroups.com.
>> >> Visit this group at http://groups.google.com/group/joomla-dev-general.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >>
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Joomla! General Development" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an

>> > email to joomla-dev-general+unsub...@googlegroups.com.

>> > To post to this group, send an email to
>> > joomla-de...@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/joomla-dev-general.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Joomla! General Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to joomla-dev-general+unsub...@googlegroups.com.

>> To post to this group, send an email to
>> joomla-de...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/joomla-dev-general.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! General Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to joomla-dev-general+unsub...@googlegroups.com.

> To post to this group, send an email to joomla-de...@googlegroups.com.
> Visit this group at http://groups.google.com/group/joomla-dev-general.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Donald Gilbert]

Good and entirely valid point, but discussing that might push this thread more off topic, and the previous things to discuss might get lost. So as I suggested previously it would be better (IMO) to open a new thread to take a look at encryption across the board. One common "thread" per actual thread is a good way to segregate, keep posts on topic, and get stuff done.

What I would like to see from this thread going forward is a consensus on the new Remember Me code. An agreement of whether it's sufficient, how soon we can get it tested by more than just me, and how can we get this into 2.5 asap as well. Since the old remember me cookie is the target of a published vulnerability, it would be wise to get that taken care of asap.

Additionally, I'm aware that simple steps were taken in 3.x to try and mitigate the issue, but changing the code to json_encode instead of serialize isn't sufficient. (And please don't get mad at me for pointing that out here on list; it is publicly available information.) It makes things slightly more difficult since you have to know more of the plaintext for the exploit to work, but it's not enough. We do need to move to a system where we are not letting passwords leave the system, even if they are encrypted, as soon as possible.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Donald Gilbert]

Elin posted the following on GitHub, and my reply was getting a bit long and involved, so I decided to move the discussion here.

"You need to store in a separate table or people will not be able to use their tablets ;)."

People would still be able to use their tablets, but the current implementation does prevent them from activating the remember me functionality on multiple devices. They may or may not be a problem. The previous implementation allowed it, simply because it wasn't saving and verifying a token, it was sending the username and password in an encrypted cookie. So, whether the side effect of allowing remember me in multiple locations was purposeful, that's another question. I see it as a useful side effect, so the code here should be modified to allow for it.

However, I don't think we need to store in a separate table in order to accomplish this. Another approach would be to issue a single authentication token to every device a user logs in from. As long as that token is not expired, it will continue to allow users to log in from multiple locations. Logging out from one device would log you out from all, which may or may not be wanted.

The more I think about it, and read other's approach to this, the more I think storing in a secondary table would be a good idea. Here's one of the posts I read on the topic: http://jaspan.com/improved_persistent_login_cookie_best_practice

That posts presents a way to allow for remember me tokens for multiple devices and also deals with cookie theft in a pretty reasonable way. It would be worth considering an approach along those lines.

[brian teeman]

I think it would be an unfortunate loss of functionality if people were only able to use remember me on a single device.

[Herman Peeren]

On Saturday, 22 June 2013 10:23:13 UTC+2, brian teeman wrote:

I think it would be an unfortunate loss of functionality if people were only able to use remember me on a single device.

I don't think it is a loss of functionallity, for that is how it is implemented now and always has been. There now is a proposal to store those cookies in another table, so multiple cookies are possible per person (one per device). That is new and wanted functionallity.

[kisswebdesign]

@don - nice article (old, but good). Do you know if drupal still use this system?

If they do, what (if any) security issues have they encountered that we could learn from?

If they have changed, why and what do they do now?

I haven't delved into drupal, and don't know anyone on their Dev team, or I would have reached out myself.

Site security is such a big issue, so anything that we can do to improve the core is valuable.

Chris.

[Herman Peeren]

Sorry, not true what I just said: now the remember-me-cookie is only stored client-side, so working on multiple devices (but in an unsafe way, for storing the user's password in an easy decryptable way).

One per browser-instance, I mean, for on one device you can also have multiple browsers. They also have their own cookies, not just multiple devices.

[SpiralScripts]

I have been following this discussion with interest, clearly there are people in this group with bigger brains than me.

But there seem to be some general points of consensus. The main one is that the token approach seems to be the way go. I do strongly agree that the password should never be stored in a cookie.

Also it seems to me that a lot of the problems could be mitigated if the 'remember me' function could be made to work only for selected user groups eg registered users and authors, and not administrators. It is administrator passwords that will be the main focus of attack.

[piotr_cz]

Good idea. I'd also add option to choose expiry period (one year seems to be pretty long).

But first the basic mechanism, features later.

Good job everyone.

[piotr_cz]

@SpriralScripts

meybe easier to implement would be to mark a user as authenticated using autologin, like

$user->set('autologin', true);

Components could then limit functionality to such users. (ie. Manual login required to change password).

Point 5 in 'Improved Persistent Login Cookie Best Practice'

[Donald Gilbert]

@SpiralScripts - It is currently limited to only the frontend of the website; you cannot use the login cookie to access /administrator. I think it would be a good idea to limit it only to accounts that aren't Super Administrators, but I can see that some might see that as too limiting. So, it might be better to add in some options to the Remember Me plugin so that site administrators can select which user groups they want to be able to log in via cookie. That would probably be the most flexible approach.

@Chris - I'm not sure if Drupal is still using it, but I'll find out. Some insight from their experience would be valuable.

@Piotr_cz - I agree that we should make it flexible and allow site administrators to set the length of the login cookie. Also, I think we should move the code that sets the cookie out of the administrator and into the cookie plugin, but I'm wondering the best approach for that. It's possible that we could just add an onUserLogin method to the cookie auth plugin, I'll have to check and see.

Finally, I'm not really a fan of these methods being split across multiple plugins. It should be simpler to implement, IMO. I'm going to work on re-writing so we can drop the actual "Remember Me" plugin altogether, and accomplish all the functionality we need within the "Cookie Auth" plugin. Should make it more straightforwards as well as easier to maintain.

[Donald Gilbert]

I put together some POC code that allows me to consolidate all the methods dealing with cookies and checking etc into the Cookie Auth plugin. The upside is that maintenance for this becomes 100x easier because you don't need to remember all the different places to enable / disable or change settings, it's all in one place in the code, so that's good.

The only apparent downside (which I don't think is a negative) is that all Authentication plugins need to be loaded sooner in the system boot process than they currently are, so that we can trigger the onAfterInitialize() event from within the Cookie Auth plugin. This has zero break in backwards compatibility, because Authentication plugins are currently not able to trigger the onAfterInitialize().

What do you think? Would that be a good or bad approach to allow access to the onAfterInitialize event within auth plugins. I could come up with arguments both for and against, but I'm leaning towards for.

[Anthony Ferrara]

Just a general piece of advice.

When it comes to security, simple is better. The simpler you can make the mechanism, the far better that will be for everyone. Rather than trying to solve every possible use-case in an API, try to solve the basic one *really* well. Then let people swap it out if they need more functionality (or different behavior).

But don't try to build one flexible system that can work for everyone. It's been tried. It doesn't work.

Remember, KISS. Especially when it comes to security, simple is FAR better than "all use-cases covered"...

Anthony

[Mark Dexter]

With that advice in mind, perhaps it would make sense, for version
3.1.2, to make the absolute minimum changes to the existing remember
me code that are needed to address the security issue. Then we can
consider further improvements for version 3.2. That way we minimize
the chance of introducing a new bug or b/c issue in a security
release.

Does that make sense to everyone?

Mark

[Marco]

Hello together,

As the author of the disclosure I would like to clarify some things.

First, I would have never disclosed this issue, if I only received one reply... A short message that somebody is working on the issue would have been enough. The full disclosure was also announced some days before to the JSST. So there was plenty of time to stop it!

Second, because this issue is very easy to detect for everybody with elementary (!) cryptographic knowledge, you don't know if this flaw is already known in the "underground"...

My consideration was that it is really easy for the end users to protect themselves by simply deactivating the remember me function and protecting yourself is better than getting your passwords decrypted by someone else... If somebody reused his password, the damage would be higher in the latter case...

Also the remember me function is just one affected function. If the cipher is used in 3th party extensions for the encryption of sensible data, this data is nearly unprotected and that is not something you would like to have...

Best regards,
Marco


On Wednesday, June 19, 2013 1:24:45 PM UTC+2, Viktor Iwan wrote:

Hi Guys,
probably some of you might have notice this...
http://seclists.org/fulldisclosure/2013/Jun/149

it just launch to the public and now, even newbie hacker get invited to test this security hole....

what quite bugs me is when i looked at the history:

# History
2013.05.11 Vulnerability reported to the vendor
2013.05.12 Vendor asked for details
2013.05.12 Details and exploit provided to the vendor
2013.05.30 Asked vendor about the status of investigation (no response)
2013.06.11 Sent another mail to the vendor (no response)
2013.06.15 Full disclosure

a month of no responses ??
should we get worried ? no ?

[Donald Gilbert]

Two-way cryptographic algorithms are *sometimes* needed. And JCryptCipherSimple is a fine implementation for that purpose. However, those using our class need to know that it is a weak encryption, and shouldn't be used for sensitive data.

Marco, your exploit only works if you know the first 32 characters of the encoded string, which is a pretty big accomplishment. With Remember Me, you had most  of that given to you since you know the plain text structure from looking at the code, but I would assume in other situations you wouldn't be able to crack it so easily. Rainbow tables are inneffective against this form of encryption, because it is unique per site / per user agent string. So IMO this exploit isn't as bad as you're making it out to be.

[Viktor Iwan]

Does JSST have stats on how many joomla site hacks ? is it decreasing or increasing ?
I'm not joining 'the underground' but i know that some of them are good enough at "breaking" things..

Maybe @marco could clarify if the remember me 'loophole' is less secure than @donald thought of...

[Donald Gilbert]

It's not about what I think, read the exploit for yourself. You NEED to know the first 32 characters of the decoded string on order for it to work - if you don't have that - you don't have anything. 

—
Sent from Mailbox for iPhone

[Marco]

I think if encryption is needed, it is mostly used for encrypting sensitive data and thus the JCryptCipherSimple should never be used. My exploit only shows one attack on the cipher, but there are still others, which are applicable if no plaintext is known... If you are interested in this kind of attacks, you could have a look at key reuse in the one-time-pad. This attacks are similar.

Maybe the picture of Tux in the Wikipedia article below shows the weakness of the JCryptCipherSimple better:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_.28ECB.29

And it is not true, that you have nothing if you don't have the first 32 characters. If you don't have one or two characters, you only loose one or two characters in the second block. In the example it is true, that if you don't have the full username, you loose some information about the password. But the remainder is still brute force able. And if you for example use a longer username, so that the password in encrypted in the third block, the username is not necessary at all to encrypt the password. If you use a very short username, the situation is also different.

[Seth Warburton]

Thank you for posting here Marco,

It's really unfortunate that you didn't receive any response from the JSST and I hope that this will prompt changes to how these things are handled in future.

Thank you also for highlighting this issue. If the smart people here find a way to make Joomla stronger (and I am certain they will) because of your efforts, then you have done all of us a great service.

Best regards,

Seth

[Donald Gilbert]

If that's the case, then your original report was incomplete, and the exploit wasn't viewed with the level of concern that it should have been. Had you _actually_ fully disclosed the severity of the exploit in your original notification to the project, it may have been treated differently.

[Marco]

In the report I used the remember me function as an example. Maybe that was not detailed enough, but I thought everybody with a security background should know the weaknesses and consequences of using the ECB mode in cryptography. However, in general it would be nice to give a status update or a short reply if requested by the reporter. It's also always possible to ask if something is unclear...

@Seth
Thank you for the nice words, it's nice to get some positive feedback :-)

[Donald Gilbert]

@Marco - I didn't even _know_ about your message to the JSST prior to your full disclosure. I guess the JSST would be proud of that fact, since they don't publicly discuss security issues pre-patch. However, I'm convinced there is some improvement in the process that we could put in place for reporting on and checking the status of reported security issues.

Also, since the JSST is somewhat of a "secret society" (I've been around Joomla for years, and on the core team for 6 months, and I still only know of 2 people who are active on the team), it's hard to tell if there is anyone on the team that has a "security background". The solutions I came up with were at the guidance of someone I know has a strong security background, which is why I asked him for help as soon as I had a concept of how we could approach this better.

So, thanks for stopping by and updating the report, it's now more clear to me than ever how big our problem is.

[Mark Dexter]

As for who is on JSST, it's on every release notes announcement:
http://www.joomla.org/announcements/release-news/5499-joomla-3-1-1-stable-released.html
(near the end). Mark