None of this is really new. The greatest danger comes from the client. Virtually everything can be read on the client from malware/key logger. What may surprise some is that 2FA does not always help with a malware attack, because after logging in with 2FA, the session also depends only on tokens and no longer on 2FA. As with internet banking, you would have to hedge each transaction individually with 2FA. That is not the case in Nextcloud.
What can be done now? You can correctly logoff from sessions. For my case, I have all cookies deleted in the browser when I close the browser. Also, you have to understand that 2FA does not help against all attack scenarios. Use a good virus scanner or an operating system with less malware. E.g. the biggest malware ever Emotet was only implemented for Windows. Linux or macOS was the best virus protection here.
I don’t think much of adjusting the configuration. It doesn’t solve the problem. Maybe it mitigates it a little.
This is the part where it has to be open for individual enhancement based on different user needs.
Many use Nextcloud exclusively on LAN, other uses it with federation excusively, and yet others have more rigid security requirements. Fortunately Nextcloud STANDARD configs and OPTIONS makes is versatile enough to fullfill most needs. However for the very security rigid organisations, I would assume per default, that Nextcloud is placed behind a WAF. If not, then I would say that adding full WAF feature set into Nextcloud, is a huge effort, with very little value.
I do get what you are writing, but I do not think there is a need for more Nextcloud enhancements, as mitigations to most risks, is achieveable in the middleware with standard modules and tweaks.
Some believe that a Nextcloud that is purely local such as http://192.168.0.x or https://onlylocalaccess.mycomplany.tld would eliminate the problem. This is exactly not the case. When attacked via malware, the client is remotely controlled, the local Nextcloud is read, and the data is exfiltrated via the Internet. Or do the users not have Internet access?
And a Web Application Firewall also does not help or at least not in all cases. You can test if E2EE or the app Secrets still works. Than e.g. the data can be stolen, too. Also the malware can crypt the data that WAF can not analyse it and WAF must allow or deny. Mostly allow i think.
Solution: You must separate intranet and internet on the desktop. I don’t know anyone who does that.
Unfortunately, I have not yet understood what you think could be achieved like WAF. Do you think that e.g. SSL Inspection solves the problem pointed out by the thread starter? Do you think that then no more tokens can be transferred to the Internet to use them? You can ask vendors if WAF software can do that at all. I think they only use blacklists and maybe they can find known malware in the normally encrypted ssl data. In the case of targeted attacks, all this is pointless.
No. However moving the authentication and federation to a waf with security gateway capabilities, you moves mitigation to that level, as that one acts as and replaces your reverse proxy, but build for purpose to protect scenarios also like that.
i dont care if it is really new or not
as a matter of fact the only way to prevent not the attac but the damage
is a simple and fast way to kill the sessions (on klick for all users, and force them to ra auth, cuz in the middle of the night u don know jack)
you are wrong about just “Maybe it mitigates it a little.”
this gonna help you a lot if shit hits the fan !
you save time, but still you are not able to kick them (the bad guys) out and force them to reauth
sadly as you see in my other posts this is not gonna work,
at least here on my config / box … gonna look a little more into it
see the LTT hack, the client was not controlled,thy got a copy of the session tokens from th browser,
so the 2FAand passwords were never breached
the main problem and thats the case here with nextcloud too
there is no way to force a user or all to reauth with their credentials
by killing revoking their tokens as admin. thats the issue
the config options are only a way do reduce stress or attack surface
no one is cacking something into NC
there are options here and seems that they are not working as expected
some say user experience over security (which is not realy true here cuz the attac is kind of special)
dont get me worng
but a WAF des not get you anywhere near the protection you need against these kind of attack
but thats another topic …
what you are talking about is a fully IDS IPS system with
inspecting ssl traffic and scanning everything in / out including every attachment that comes in an goes out
yeah its doable
and oh boy some of the back office users who gets a ton of mails and attachements every day still got hit by stuff
the only way is to put these workstations in a DMZ (old school)
have fun supporting your users and keep the collaboration effort and user expe high …
spoiler not gonna work
so bottom line, you have to set some usere experience limiting settings on NC to minimize the surface for an attack like this
if shit hits the fan
as an admin you will be missing the feature to force all users to reauth with their credentials and kill or revoke their tokens
(and yeah this will be fun when 2FA enabled for all the plugins and devices auth via token)
Well I have loads of experiences with Broadcom SiteMinder. This tool is utilizing apache tomcat reverse proxies with a plugin and that one then handles all this for you through the SiteMinder policy servers.
Apache Traffic has plugins to be able to do most of the same. However is it “easy” to configure? No. But is the effort worth spended to try and build a solution guide for using that instead? Probably.
Actually I think you might be able to solve this with Gluu as well. Move the authentication and authorization from Nextcloud to Gluu. This one has these additional security settings buildin, and because Gluu as acting as a reverse proxy (yes you will have to terminate your TLS on Gluu and not in NC webserver) it is all about how you sete up your infrastructure. Just ensure that no clients reaches Nextcloud directly, but is forced to go through the Reverse Proxy (like Gluu or Apache Traffic) to reach the Nextcloud instance.
Yes. I agree the 2FA was never breached. But the password can be stolen on client side if needed.
Yes. Maybe it is possible to add it to Nextcloud. Very good idea.
Yes. It treats the symptom and not the cause.
I think that SSL interspection does not work at the latest when the data within TLS is encrypted again. As an attacker, i would always do this (communication to the Command-and-Control-Server). This can be tested with test viruses within e.g. https://privatebin.net/. Can WAF find the virus transported from your client through WAF to the internet and back to your client?
Forget the WAF statement as a stand alone. I apologize. I have never used a WAF which is just and only a WAF. The tools I have worked with had WAF AND Secure Reverse Proxies. My bad.
Any terminating link in your infrastructure, can be mitigating an attack like this. As I said: Move session management and authentication and authorization (including) from Nextcloud to an entity in front build for purpose, like Gluu.
No. I got a ton of experience building secure authentication, authorization and governance of web trafic. This includes WAF, session management, reacting to suspecious patterns and likely session and token attacks.
Yes that is a good idea. Finally it would be useful if the session id is only valid for the special client so you can’t just use the session key on another device. Maybe that is the question for Nextcloud. But of course this does not solve the malware and therefore remote control problem direct on the client. Nothing helps. Also not 2FA after authentication.
Correct. Malware can and will always be able to initiate “legit” connections, as it is coming from a trusted client. However tools like Gluu has excactly the features the OP is asking for, as it can terminate and kickout - even block specific sessions by the admin interface. However why should Nextcloud start implementing mitigations from attacks, which comes from a trusted source? Malware needs to be caugth by your end point protection on your devices, or your coorporate ATP or SIEM. Only other solution is to never trust any source at all. That can work, but how many of the community users would then stop using Nextcloud because it becomes very hard and complex to ensure family and friends can login without annoying checks and constant nagging?
But killing a session in Nextcloud will never be an option. If ever using Federation to login to nextcloud, it will never work. You would have to add CASB features, so Nextcloud has an API which can also tell the IDP, that this user needs re-authentication.
This is why I started with the “is it worth the effort compared to other possible solutions”