Disclosure of the FTP Password inside Filemanager.ai link

[anon11210450]

When browsing the filemanager.ai website, the password is disclosed inside a Base64 encoded string.
This is also disclosed inside the browser’s history.

Example (not using real password):
Monsta FTP**

Any Base64 Encoded JSON data starts with “ey”
So we can do:

echo eyJ0IjoiZnRwIiwiYyI6eyJ2IjowLCJwIjoiWU9VUl9QQVNTV09SRF9IRVJFIn19IA0K | base64 -d
Outputs: {“t”:“ftp”,“c”:{“v”:0,“p”:“YOUR_PASSWORD_HERE”}}

Then we can connect to this account using explorer.exe like so:

explorer ftp://epiz_25969029:[email protected]

and we get full access to the FTP account.

This sort of attack could work if a user got a virus on their computer which sends their browser history to a malicious host, and thus anyone on that side could easily run a RegExp to search for patterns starting with “ey”.

---

In my opinion I’d use some sort of temporary hash that would expire in 5 minutes.

[HaydenANG]

There are a few factors to guess though, first you have to get the 8 digit long account id, along with the first part, which could be anything, then if you get a virus, it can do anything. Temporary hashes are good ideas, I know thats what cPanel use.

---

It would be a good idea, but the MonstaFTP program I don't think, comes with that. Maybe suggest it to them? But then all FTP password would have to be hashes, then it gets complicated. Because MonstaFTP connects straight to the ftp server.

[adisp007]

It was made on purpose by MonstaFTP:
https://www.monstaftp.com/guides/how-to-auto-generate-log-in-links

[Admin]

This is how the login links work with MonstaFTP. It would be safer of course to generate a one time login token, and send the password to MonstaFTP internally while generating that one time login token. But then MonstaFTP would need to store the login password in some kind of persistent data store, and right now MonstaFTP doesn’t have any persistent storage.

This is how the login links work, and we can’t change that.

@anon11210450

This sort of attack could work if a user got a virus on their computer which sends their browser history to a malicious host, and thus anyone on that side could easily run a RegExp to search for patterns starting with “ey”.

If there is a virus on the computer, then all bets are off. The virus could run a MITM proxy and capture the POST data for any login forms, even if the connection uses HTTPS by injecting their own root CA into the browser or OS certificate chain. Or they could be viewing website pages, recording keystrokes and capture sensitive data in many other ways.

No amount of website security can save you if a device on either end is infected.