I’ll check into this, but I’ll have to boot the server back up, pretty sure I patched this when I heard about it, but it’s worth a check - thanks 
Apologies, but this is not caused from a Windows PC. I have not had one connected to it (only at the beginning a while back, at least 5-6 months, to seed the files). From reading into the other thread it seems to be based on a Python script, meaning that it couldn’t have gone through my Windows PC back then also.
You could be thinking of Wannacry? Which was well known to spread through Windows systems.
And you know this is a nextcloud issue how? Do you have logs that show it was through nextcloud?
So. First of all. This kind of stuff is exactly why you have a backup. Good for you.
We have not heard of this before. However, we are unaware of any exploits in Nextcloud to have remote code execution.
So if you could go trough your access logs to find out what was going on please do.
Someting that comes to mind. Are you by any chance running NGINX with our outdated config and an outdate php-fpm?
2 Likes
Would be very interesting to know how it got in…
To add to this.
Can you send me (in private) your
- access logs
- nextcloud version
- php version
- webserver and version
Then we can dive into it more.
I’ll grab this for you this weekend, as I’m away from home currently until tomorrow.
Just for info, this has now been posted below with more info also;
It’s possible that @kesselb is correct - will confirm versions once I’m back.
That article on Bleeping Computer sounds as though the ransomware targets client computers running the sync client, rather than the server itself. However having the server “locked via SSH” (meaning server OS user passwords changed?) would suggest otherwise.
Is the nginx vulnerability being involved just speculative at this point, or does that seem like a likely culprit?
In the interest of attack surface reduction, I’ll share a couple other things I’ve done to harden my system. I run a dummy site that’s returned if the wrong/no SNI is used so random scans are less likely to ever reveal the Nextcloud instance. I also block all connections to it from non-ARIN addresses. That in particular drastically reduced the amount of random access I get. Also, it probably goes without saying, but there is no outside SSH access Or any other sort of remote control to the system. If you must have remote console access, strictly use a VPN.
If the infiltration point really is on the server, those measures will go a long way to help reduce potential exposure.
Does this affect people with NextCloudPi?
Digging through logs, I found these few requests from a few days ago:
2019-11-12T20:12:40Z 185.165.168.229 - - [12/Nov/2019:20:12:38 +0000] "GET / HTTP/1.1" 302 5 "-" "python-requests/2.20.0" "185.165.168.229"
2019-11-12T20:14:10Z 185.16.206.2 - - [12/Nov/2019:20:14:00 +0000] "GET / HTTP/1.1" 302 5 "-" "python-requests/2.20.0" "185.16.206.2"
2019-11-12T20:14:10Z 185.16.206.2 - - [12/Nov/2019:20:14:01 +0000] "GET /login HTTP/1.1" 200 1973 "-" "python-requests/2.20.0" "185.16.206.2"
2019-11-12T20:13:25Z 185.165.168.229 - - [12/Nov/2019:20:13:11 +0000] "GET /login HTTP/1.1" 200 1975 "-" "python-requests/2.20.0" "185.165.168.229"
Anyone else have similar requests in their logs?
These both seem to be anonymous proxies. I’ve blocked both of them at the firewall.
Agreed, I also geoblock. Best decision in my life. 
tl;dr nobody knows how the attack happened. This may or may not be a nextcloud issue. This may or may not be related to the nginx php-fpm exploit.
The article linked earlier in the thread does not explain things properly and thus the attack source isn’t known.
The URL with extension is also obfuscated in the article, so we have no idea if the nextcloud install itself was compromised.
I don’t see popular nextcloud providers (such as hetzner) having issues and the nextcloud reps in this forum appear clueless. This implies it’s not a nextcloud issue.
Most probable cause is probably that nginx and php-fpm was not updated with the latest security fixes.
I have checked my servers and that is the only entry point I could come up with so far. I doubt that it is some new hole that someone has discovered. As it looks like a works or something that is scripted to scan for hosts.
Maybe not the best time I updated to NC 17:
Following apps have been disabled:
deck (incompatible),
event_update_notification (incompatible),
files_texteditor (incompatible),
quota_warning (incompatible),
ransomware_detection (incompatible), <---
ransomware_protection (incompatible), <--
spreed (incompatible)
This implies we don’t know nothing. And we have to collect more facts and investigate further.
Or?
All those have updates. So just upgrade, go to apps and update the apps.
They probably updated the article and added new information. The ransomware is looking for config/config.php and reads the datadirectory from there. Sounds like server to me.