Unauthenticated Filesystem Access

[Clever Name]

FYI, if you connect to the management, even over the open wifi management, you can get filesystem access to /pineapple/ui without being logged in.  For example, you can open http://172.16.42.1:1471/modules and see all modules installed, including traverse the directories and view all file contents regardless of permissions.  You can also read the files in /pineapple/ui, though there's nothing that interesting, you could do http://172.16.42.1:1471/ngsw.json to read the file.  Also, permissions are ignored.  A file with no read permissions at all can be displayed.

[Clever Name]

This was fixed in v1.0.1-beta.2020091914551.

[Clever Name]

FYI, CVE-2020-25726.

[Darren Kitchen]

Thanks for reporting this, and I understand you're trying to help. I wouldn't go as far as calling this a vulnerability. That's sort of akin to pointing out that the login page is accessible unauthenticated. There's nothing sensitive in the UI directory that's accessible - for example, the json file you mention is an element of progressive web apps. All of the configuration and loot data are stored elsewhere. As you've determined, after you reported this we removed it from 1.0.1. Again, I'm sure you have the best of intentions but, there's no data leak or pivot. Had there been I would absolutely understand a CVE, but as is I'm a bit perplexed. 

[Clever Name]

I think the problem would be in that you can browse through their installed modules.  Let's say someone makes a simple module that will opkg install htop and basically display htop output in the web browser.  There are so few modules available right now that a lot of people would probably install it just to install it, and it seems somewhat useful.  But unbeknownst to the user that the person that made the module made a symlink called 'escape' to the default loot directory in their module directory.  Or, better yet, just a symlink to /.  So let's say you're sitting in a bar somewhere and see open wifi and you connect to it with your laptop and get 172.16.42.42 and you're like hmmm I wonder if this person installed that htop module?  So, over open wireless, unauthenticated, you go to http://172.16.42.1:1471/modules/htop/escape and you land in /.  You browse your way to /etc and view the shadow file (which I have verified you can do) and you copy root's hashed password.  Now you throw that in john the ripper and let it crack the root password.  Then you ssh to the pineapple and, for fun, rm -rf / and watch for the most confused face in the place and now you know whose device it was.  Completely possible.  Aside from that, though, it's more of information disclosure, as you can browse through /pineapple/ui/modules and explore which modules are installed and access all of the files.  I don't know if modules will use their own directories for temporary files or something.  WiFite winds up as a module, will cracked.txt be in modules/wifite?

As it stands right now, you are correct- as I mentioned when I used that json file as just an example, it's nothing useful... right now.  But as described in my example, it's feasible that it could be a big problem depending on the nature of future modules.

[Darren Kitchen]

Yes, it *could* be a problem *if* someone submits a vulnerable module *and* we accept that module to the repository. Considering this isn't the case, and that this is removed from 1.0.1 and onward, and that we are not accepting modules with vulnerabilities - I don't see your hypothetical scenario playing out. Any information that was obtainable before a restriction was added would provide no benefit to an adversary. Again, thank you for the report, and I don't want to split hairs with you because I believe your intention is sound - however I do not believe a CVE is warranted.