ref #35574 (comment)_
However, what seems to be out of scope of this PR, and is a security issue @joomla/security is the changing of a security credential (account validation) by GET request, which should be addressed, as nothing should change when making GET requests, which are designed for page retrieval and not updating a user object.
For the record this was reported to the Joomla security strike team, via their email address, however I did not receive any reply to my report to date
its now March 2 2022 . Im here today because someone else is having outgoing spam checkers on their server following the activation link by a GET request, and thus performing a change of state of a user from blocked to not blocked and activated.
X-ClientProxiedBy: SRI-Exchange01.REDACTED.local (192.168.70.211) To
SRI-EXCHANGE01.SRIHQDOM.local (192.168.70.211)
X-BESS-ID: 1646230662-111362-22863-6630-1
X-BESS-VER: 2019.1_20220301.2317
X-BESS-Apparent-Source-IP: REDACTED
X-BESS-Outbound-Spam-Score: 0.00
X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.238322 [from
cloudscan15-214.us-east-2a.ess.aws.cudaops.com
Rule breakdown below
pts rule name description
---- ---------------------- --------------------------------
0.00 BSF_BESS_OUTBOUND META: BESS Outbound
X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS55810 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND
X-BESS-BRTS-Status:1
172.70.134.252 - - [02/Mar/2022:14:17:43 +0000] "GET /login?task=registration.activate&token=11256c8f88122fb2ff8e7773012d6596 HTTP/1.0" 303 - "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
172.70.134.252 - - [02/Mar/2022:14:17:43 +0000] "GET /login HTTP/1.0" 200 30044 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
the official reply from the JSST on 20 Oct 2021 was:
we discussed your report and don't agree with the classification as a security issue.
The security-relevant aspect of that feature is, that we want to make sure, that the given mail address of a user indeed exists and that only the user is able to prove that fact. The current, GET-based implementation does that.
and my reply:
But you are NOT doing that.
Some services that scan urls interact with mails BEFORE the mail server has accepted them! These stateful firewall and malware scanning services terminate the SSL and scan the email BEFORE rejecting the email at the mail server layer.
What you are ASSUMING is that all scanning of email content is done AFTER a mail server has interacted with the mail, and rejected any invalid mail addresses. This is not always the case.
Furthermore some mail services do not reject the email at SMTP conversation time. They will accept ALL MAIL, and then using features of the mail server, will make their decision AFTER the SMTP conversation - they could scan the urls here too - and then they can reply with BoxTrapper replies or custom failure messages rather than the SMTP failure messages we see most of.
Therefore I can verify an email address, on a domain with that kind of service, even if the email address DOESNT exist! Thus this is a "security-relevant aspect of that feature" because you have not taken these scenarios into account. You assume that "only the user is able to prove that fact" and that is NOT THE CASE.
I dont think you get that. I dont think your team understand this is possible.
I did not get a reply from that email.
Regardless of what you state, this IS A SECURITY ISSUE that needs fixing. This is an automated spam check making security changes to a user that are unauthorised - you are not proving that the email address of a user exists, in fact in my tests today I was using made up email addresses and I was able to activate the user because the spam check outbound on the email was visiting the link with a GET request. That is a security issue.
Using this exploit I can create unlimited activated users on a site, that is correctly configured to force a user activation by email, even if the email address doesnt exist, as long as it passes internal Joomla email address validation so fsn8fdsa89fsd@asiut6adf78o6sd.com would be valid for example (yes I bashed the keyboard)
ref #35574 (comment)_
Labels |
Added:
No Code Attached Yet
|
Title |
|
So, let me summarize the current state:
Yes, depening on a the specific mail server setups (specificially: usage of scanning tools that follow links on either inbound or outbound traffic), there are scenarios where a user account might be activated even if the the mail address does either not exist or isn't controlled by the user.
I agree that this is not expected behavior .
The question discussed within the JSST was, if that unexpected behavior is a security issue on it's own. At the time of the original report, we didn't consider that being the case.
During the recent JSST sprint we discussed the issue again, coming to the conclusion that their might be one specific scenario, where we theoretically see a very minor security issue. However, weighting the "severeness" of the issue against potential side effects by a patch (potential issues in 3rd party extensions relying on the current behavior etc) we decided to not patch this in a private security PR but in a public PR, which is currently being worked on.
So, another 6 months and NOTHING, right?
Waste my time AND my money and then wonder why so many Joomla users and
builders are just pissed off.
This is a fucking security hole you could drive a goddamn truck through.
You guys call yourselves security experts? Please...
On Wed, Mar 2, 2022 at 11:13 AM David Jardin @.***>
wrote:
So, let me summarize the current state:
Yes, depening on a the specific mail server setups (specificially: usage
of scanning tools that follow links on either inbound or outbound traffic),
there are scenarios where a user account might be activated even if the the
mail address does either not exist or isn't controlled by the user.
I agree that this is not expected behavior .The question discussed within the JSST was, if that unexpected behavior is
a security issue on it's own. At the time of the original report, we didn't
consider that being the case.During the recent JSST sprint we discussed the issue again, coming to the
conclusion that their might be one specific scenario, where we
theoretically see a very minor security issue. However, weighting the
"severeness" of the issue against potential side effects by a patch
(potential issues in 3rd party extensions relying on the current behavior
etc) we decided to not patch this in a private security PR but in a public
PR, which is currently being worked on.—
Reply to this email directly, view it on GitHub
#37172 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALO7JJSH7UYS7W6XJQT472TU56VS3ANCNFSM5PXTKEBA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.You are receiving this because you commented.Message ID:
@.***>
--
"On the off chance that you’re not going to live forever, why not take a
chance at being happy now?" ~ Charlie Skinner (The Newsroom)
if that unexpected behavior is a security issue on it's own
The ability to change a user from being blocked to being not blocked - by a single unauthenticated GET request IS A SECURITY ISSUE - it goes against EVERYTHING !
AT THE VERY LEAST it should be a POST request required.
At the time of the original report, we didn't consider that being the case.
So "at the time" you and the whole security team of Joomla were happy that a GET request was making security decisions on a user object, and changing the access control of a user object. Based on that statement alone every one of you should resign your position on the JSST. This is basics!
a GET request should NEVER be making security sensitive changes to a the Access Control Limits of an object - this is basic security programming 101
where we theoretically see a very minor security issue
I have repeatedly shown you that this is not minor. I can flood a site with millions of fake ACTIVATED USERS within seconds - even if the site has a configuration that means users need to authenticate by "clicking a link".
Stop trying to save face, and just fix it. Its been too long and too many releases have already been made where this could have been fixed. All that is needed is for you to stop sending a URL in the email, and just send the token, and the URL to the form where someone can enter that token - IIRC this is exactly what Joomla used to do!
During the recent JSST sprint we discussed the issue again
So you are now randomly reopening and rediscussing items you have previously closed and disregarded that you stated were not security issues before... sounds like a lie.
However, weighting the "severeness" of the issue against potential side effects by a patch (potential issues in 3rd party extensions relying on the current behavior etc)
Absolute rubbish. Name me one 3rd party extension that "relies" on Joomla being insecure and relying on a GET request to "authenticate" new user account activations?... I'll wait...
we decided to not patch this in a private security PR but in a public PR, which is currently being worked on.
Link?
There is no way this is not a security issue.
FIX THIS
Time is not free.
I didn't realize "impertinent" was such an issue.
If you guys would rather dodge issues and refuse to fix things you KNOW are issues, and HAVE KNOWN about for MONTHS, then that's up to you, but when you start whining because you're hemorrhaging market share, you can look at 5 years of alphas and betas that change so much between versions that developers can't keep up, and develop your default templates in a freaking VACUUM - you can look there in a few years when the Joomla we all loved is nothing more than an unsupported shell.
KEEP THOSE HEADS BURIED FOLKS
@brianteeman Your point is?
repeated trolling by an anonymous account
@brianteeman I know
I beg your pardon. I was signed in. It has my email address.
What are you whining about now?
But it does appear you guys would much rather careen off topic in any way you can rather than fix the issues that have been reported to you.
You will have to synchronize your wallet and make sure you debug it with bech13.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-03-07 18:36:03 |
Closed_By | ⇒ | PhilETaylor |
@breebee Delete this whole thread for security issues :)
The Joomla Project and the Joomla Security Strike Team do not believe this is a "security issue"
The official reply from the JSST on 20 Oct 2021 was
we discussed your report and don't agree with the classification as a security issue.
They are wrong of course. Changing the security of a user object by a GET request by an anonymous mail scanning software goes against all security best practice.
:( i deleted my posts to not litter on the internet or bring attention to a security issue, you apparently took so long to post your comment you didnt notice.
PLEASE FIX THIS SEVERE SECURITY FLAW.
This is absolutely the worst thing that any website owner who actually needs users to create accounts and login.