No Code Attached Yet
avatar PhilETaylor
PhilETaylor
2 Mar 2022

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)_

avatar PhilETaylor PhilETaylor - open - 2 Mar 2022
avatar joomla-cms-bot joomla-cms-bot - change - 2 Mar 2022
Labels Added: No Code Attached Yet
avatar joomla-cms-bot joomla-cms-bot - labeled - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar sjb1963
sjb1963 - comment - 2 Mar 2022

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.

avatar PhilETaylor PhilETaylor - change - 2 Mar 2022
The description was changed
avatar PhilETaylor PhilETaylor - edited - 2 Mar 2022
avatar SniperSister SniperSister - change - 2 Mar 2022
Title
Security Issue Ignored by JSST - Outbound Spam checks auto activate users by GET request.
Outbound Spam checks auto activate users by GET request.
avatar SniperSister SniperSister - edited - 2 Mar 2022
avatar SniperSister
SniperSister - comment - 2 Mar 2022

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.

avatar sjb1963
sjb1963 - comment - 2 Mar 2022

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)

avatar PhilETaylor
PhilETaylor - comment - 2 Mar 2022

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?

avatar sjb1963
sjb1963 - comment - 2 Mar 2022

There is no way this is not a security issue.
FIX THIS

avatar chmst
chmst - comment - 2 Mar 2022

@sjb1963 for what did you waste money, as joomla is free?

avatar PhilETaylor
PhilETaylor - comment - 2 Mar 2022

Time is not free.

avatar sjb1963
sjb1963 - comment - 2 Mar 2022

@chmst Hiring an expert to figure out where you dropped the ball. THAT's where?

Any more impertinent questions?

avatar rdeutz
rdeutz - comment - 2 Mar 2022

@sjb1963 watch your language, please.

avatar sjb1963
sjb1963 - comment - 2 Mar 2022

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

avatar brianteeman
brianteeman - comment - 2 Mar 2022
avatar sjb1963
sjb1963 - comment - 2 Mar 2022

@brianteeman Your point is?

avatar brianteeman
brianteeman - comment - 2 Mar 2022

repeated trolling by an anonymous account

avatar rdeutz
rdeutz - comment - 2 Mar 2022

@brianteeman I know

avatar sjb1963
sjb1963 - comment - 2 Mar 2022

I beg your pardon. I was signed in. It has my email address.
What are you whining about now?

avatar sjb1963
sjb1963 - comment - 2 Mar 2022

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.

avatar Yuxanju
Yuxanju - comment - 3 Mar 2022

You will have to synchronize your wallet and make sure you debug it with bech13.

avatar PhilETaylor PhilETaylor - change - 7 Mar 2022
Status New Closed
Closed_Date 0000-00-00 00:00:00 2022-03-07 18:36:03
Closed_By PhilETaylor
avatar PhilETaylor PhilETaylor - close - 7 Mar 2022
avatar PhilETaylor
PhilETaylor - comment - 30 Mar 2022

@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.

avatar PhilETaylor
PhilETaylor - comment - 30 Mar 2022

I suggest you check your facts. I have repeatedly provided solutions to this and other security issues. Only to be ignored.

Being trolled by someone with zero contributions... ever ...

Screen Shot 2022-03-30 at 17 58 01

avatar PhilETaylor
PhilETaylor - comment - 30 Mar 2022

oh and now @breebee has decided to delete their trolling posts too... hahahaha

avatar breebee
breebee - comment - 30 Mar 2022

:( 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.

avatar brianteeman
brianteeman - comment - 30 Mar 2022

@breebee several hundred people receive a copy via email of every message

Add a Comment

Login with GitHub to post a comment