Only if the users home directories are explicitly shared to all users manually. Any recent OS linux or windows based protects all personal directories by default.
Wrong. The directories that the FTP server service itself has access to depend on what account the FTP server service is running as. It has nothing to do with the account you log in to the FTP server itself with, which very likely has nothing to do with Windows accounts anyway and is likely accounts created within the FTP server application. In this case, it sounds like anonymous access was allowed, which is an FTP server setting or account and not a Windows account.
If the FTP server is running as a service on Windows and is running as NT Authority/System, then that server would have access to all directories on all disks regardless of what file permissions are set, as that account has higher access than a user account that is assigned administrative rights. It can access all directories, even user home directories. This would be the same if the service was running as the root user on a Linux/Unix/macOS box.
Of course that’s why you’re supposed to use least privilege for services, but quite often people who don’t know what they’re doing don’t, and that makes my job easier. Even if least privilege was being used it’s very likely that unless the guy is a complete moron he probably didn’t have the root of the drive configured as the root of the FTP anyway, and likely had all of the stuff in some subdirectory somewhere for the purpose of remote access, backups, etc.
And I should clarify that when I said “wrong” I didn’t mean your comment was technically wrong, only that in the context here you have another application with its own set of file permissions in the mix so that complicated things, as I described above.
You're wrong. Just cause the daemon is running as root (which is required for anything running under port 1024) does not mean the users have access to everything unless they chmod everything to 777
Again, you're conflating FTP users with local OS user accounts. If the FTP server service daemon is running and root and is allowed to execute commands, it could chown or chmod any directory on the box. It depends on the level of access the default FTP user that was exposed has in regard to the FTP software. There was a HackTheBox box a while back where exactly that happened - credentials were exposed for an FTP user that had access to an administrative console for an FTP service that was running as root. Through the console, the low-privileged user account was able to to execute commands as root via PHP, which lead to root on the box.
The Windows angle still stands as directly as I pointed out. NT Authority\SYSTEM doesn't care about NTFS file system rights. In fact, on a domain-joined box, it doesn't care about domain permissions either (if located on local disks for the compromised box). I've dumped entire user share directories from the root (example, users$ with a bunch of users under that) using this method before, and those had domain permissions set so that only the individual user had read/write (not full control) on the directories. Even DA and EA groups didn't have access. SYSTEM didn't care.
We don't know what OS this box was running, but depending on how it was misconfigured, getting access to contents of the whole box is entirely possible.
Literally this. Download EML, PST, or OST files from an FTP? Yup! Done it before. Pen tester pede here.
Only if the users home directories are explicitly shared to all users manually. Any recent OS linux or windows based protects all personal directories by default.
Wrong. The directories that the FTP server service itself has access to depend on what account the FTP server service is running as. It has nothing to do with the account you log in to the FTP server itself with, which very likely has nothing to do with Windows accounts anyway and is likely accounts created within the FTP server application. In this case, it sounds like anonymous access was allowed, which is an FTP server setting or account and not a Windows account.
If the FTP server is running as a service on Windows and is running as NT Authority/System, then that server would have access to all directories on all disks regardless of what file permissions are set, as that account has higher access than a user account that is assigned administrative rights. It can access all directories, even user home directories. This would be the same if the service was running as the root user on a Linux/Unix/macOS box.
Of course that’s why you’re supposed to use least privilege for services, but quite often people who don’t know what they’re doing don’t, and that makes my job easier. Even if least privilege was being used it’s very likely that unless the guy is a complete moron he probably didn’t have the root of the drive configured as the root of the FTP anyway, and likely had all of the stuff in some subdirectory somewhere for the purpose of remote access, backups, etc.
And I should clarify that when I said “wrong” I didn’t mean your comment was technically wrong, only that in the context here you have another application with its own set of file permissions in the mix so that complicated things, as I described above.
You're wrong. Just cause the daemon is running as root (which is required for anything running under port 1024) does not mean the users have access to everything unless they chmod everything to 777
Again, you're conflating FTP users with local OS user accounts. If the FTP server service daemon is running and root and is allowed to execute commands, it could chown or chmod any directory on the box. It depends on the level of access the default FTP user that was exposed has in regard to the FTP software. There was a HackTheBox box a while back where exactly that happened - credentials were exposed for an FTP user that had access to an administrative console for an FTP service that was running as root. Through the console, the low-privileged user account was able to to execute commands as root via PHP, which lead to root on the box.
The Windows angle still stands as directly as I pointed out. NT Authority\SYSTEM doesn't care about NTFS file system rights. In fact, on a domain-joined box, it doesn't care about domain permissions either (if located on local disks for the compromised box). I've dumped entire user share directories from the root (example, users$ with a bunch of users under that) using this method before, and those had domain permissions set so that only the individual user had read/write (not full control) on the directories. Even DA and EA groups didn't have access. SYSTEM didn't care.
We don't know what OS this box was running, but depending on how it was misconfigured, getting access to contents of the whole box is entirely possible.
I sure wouldn't mind learning how to break into computers.
In minecraft.