Mr-Protocol,
If you consider the case where the victims can sometimes be people who are capable of using a network sniffer... then it somewhat becomes relevant imho.
They would see plenty of requests to /pineapple (assuming you are logged-in to the UI of course) and might want to have a look at it.
- Decoding the base64 of the http auth is trivial, and would expose your root credentials...
- Using another password than the root in the httpd.conf prevents exposing your root account (ssh); but does not prevent http ui access.
A solution would then indeed be in the IP filtering of the /pineapple uri.
Although, "hardcoding" an IP restriction for traffic coming from 172.16.42.42 would not be the way to go (again, imho) : it must be configurable (network config can be changed by the owner of the pineapple so 42.42 becomes irrelevant).
As a dirty workaround, one could make a check in the /pineapple/index.php to ensure that $_SERVER['REMOTE_ADDR'] is let's say 127.0.0.1 (the IP to check could come from a conf file as well).
(I would personnaly use 127.0.0.1, and tunnel the http administrative access through a SSH connection to the pineapple (so http to /pineapple is at least encrypted); while still allowing other ressources to be publicly browseable for phishing).
Another way could be to use the pattern-match feature of iptables for traffic traffic destined to <pineapple_ip>:80 and containing "/pineapple" .. but this would probably cause a noticeable overhead.
Just throwing out ideas.. if you only consider regular victims it indeed does not make any sense to take such precautions.
On a different subject (but will avoid to open another thread for it) , where did the feature allowing to blacklist/whitelist SSIDs go? Was quite useful to restrict the scope of the attack.
fox