itsm0ld Posted December 8, 2011 Share Posted December 8, 2011 (edited) This is another improvement I wanted to make after I got my MK3 when testing, securing the /pineapple web interface with a password so here is how to do it! SSH to your MK3 (default IP is 172.16.42.1) Lets create the first file: touch /etc/httpd.conf Now lets add the /pineapple prefix to secure using nano: nano /etc/http.conf (file should be empty) Add the following: /pineapple:admin:$p$root This defines the page to secure in this case /pineapple, then the username in this case admin, then it looks to the root users password (whatever you set, default is pinepplesareyummy) Close and save the changes. Now we need to edit the /etc/config/uhttpd to use the httpd.conf nano /etc/config/uhttp Scroll down to the section called: # Configuration file in busybox httpd format un-comment the following line to look like: option config /etc/httpd.conf Close and save changes. Lastly we need to restart uhttpd to make the changes active: /etc/init.d/uhttpd stop /etc/init.d/uhttpd start Now if you browse to http://172.16.42.1/pineapple it will prompt you for a username and password. Hope this helps! Edited December 10, 2011 by itsm0ld Quote Link to comment Share on other sites More sharing options...
itsm0ld Posted December 10, 2011 Author Share Posted December 10, 2011 Confirmed working on 1.0.2 Anyone else get this working or did I just ramble on Quote Link to comment Share on other sites More sharing options...
Marlboro Filter Posted December 10, 2011 Share Posted December 10, 2011 (edited) i still can browse to http://172.16.42.1/pineapple wihtout password :( :( :( tested using chrome and firefox still no password, i also tried to reboot the device i follow exactly as mention :( :( Edited December 10, 2011 by Marlboro Filter Quote Link to comment Share on other sites More sharing options...
itsm0ld Posted December 10, 2011 Author Share Posted December 10, 2011 (edited) i still can browse to http://172.16.42.1/pineapple wihtout password :( :( :( tested using chrome and firefox still no password, i also tried to reboot the device i follow exactly as mention :( :( Ack just realized I have a typo in the code section.. I have updated the post but the problem line was nano /etc/config/uhhtp Should have been: nano /etc/config/uhttp That should do it let me know! Edited December 10, 2011 by itsm0ld Quote Link to comment Share on other sites More sharing options...
Marlboro Filter Posted December 10, 2011 Share Posted December 10, 2011 well done bro... work perfectly. here's the changes touch /etc/httpd.conf nano /etc/httpd.conf /pineapple:admin:$p$root nano /etc/config/uhttpd Scroll down to the section called: # Configuration file in busybox httpd format un-comment the following line to look like: option config /etc/httpd.conf restart service /etc/init.d/uhttpd stop /etc/init.d/uhttpd start Thank you very much itsm0ld. now my pineapple are secure...horayyy:) :) Quote Link to comment Share on other sites More sharing options...
Mr-Protocol Posted December 10, 2011 Share Posted December 10, 2011 Please update to the newest firmware. Mine prompted me for password on version 1.9 firmware from the Wiki. Quote Link to comment Share on other sites More sharing options...
itsm0ld Posted December 10, 2011 Author Share Posted December 10, 2011 well done bro... work perfectly. here's the changes touch /etc/httpd.conf nano /etc/httpd.conf /pineapple:admin:$p$root nano /etc/config/uhttpd Scroll down to the section called: # Configuration file in busybox httpd format un-comment the following line to look like: option config /etc/httpd.conf restart service /etc/init.d/uhttpd stop /etc/init.d/uhttpd start Thank you very much itsm0ld. now my pineapple are secure...horayyy:) :) Glad you got it working! Quote Link to comment Share on other sites More sharing options...
Sebkinne Posted December 10, 2011 Share Posted December 10, 2011 Please update to the newest firmware. Mine prompted me for password on version 1.9 firmware from the Wiki. Indeed. I built that in a few versions back. Best, Sebkinne Quote Link to comment Share on other sites More sharing options...
itsm0ld Posted December 10, 2011 Author Share Posted December 10, 2011 (edited) Indeed. I built that in a few versions back. Best, Sebkinne Just giving an alternative to a total re-flash and the questions that have come up over how to do it. If you can get to your pineapple and just want to add the feature or secure more than just the /pineapple page this is how it can be done. Edited December 10, 2011 by itsm0ld Quote Link to comment Share on other sites More sharing options...
Mr-Protocol Posted December 11, 2011 Share Posted December 11, 2011 Reflashing will have newest bug fixes and features. 10 minutes (mine only took like 5 minutes) for the latest and greatest updates, that is not so much to ask. By the time you ssh and do all the messing around you could have it done lol. Quote Link to comment Share on other sites More sharing options...
itsm0ld Posted December 11, 2011 Author Share Posted December 11, 2011 Not much to ask at all, just an alternative. Quote Link to comment Share on other sites More sharing options...
httpCRASH Posted December 11, 2011 Share Posted December 11, 2011 (edited) Reflashing will have newest bug fixes and features. 10 minutes (mine only took like 5 minutes) for the latest and greatest updates, that is not so much to ask. By the time you ssh and do all the messing around you could have it done lol. I agree, and why only fix the login, and not get the rest of the new fixes.. that makes no sence B) Edited December 11, 2011 by httpCRASH Quote Link to comment Share on other sites More sharing options...
itsm0ld Posted December 11, 2011 Author Share Posted December 11, 2011 Well alright lol.... Quote Link to comment Share on other sites More sharing options...
foxof Posted December 11, 2011 Share Posted December 11, 2011 Nice, but I wouldn't actually use the root password as web auth credentials; unless you want your root password to be sniffed while performing auth over plain text http....and have someone taking over your pineapple... Quote Link to comment Share on other sites More sharing options...
Sebkinne Posted December 12, 2011 Share Posted December 12, 2011 Nice, but I wouldn't actually use the root password as web auth credentials; unless you want your root password to be sniffed while performing auth over plain text http....and have someone taking over your pineapple... Well, normally the victims do not know about the pineapple ui. But you are right of course. I could restrict access to ceartain IPs / mac addresses. I will give it some though. Sebkinne Quote Link to comment Share on other sites More sharing options...
httpCRASH Posted December 12, 2011 Share Posted December 12, 2011 Well, normally the victims do not know about the pineapple ui. But you are right of course. I could restrict access to ceartain IPs / mac addresses. I will give it some though. Sebkinne but then it should be mac a filter, or total optional.. because if you run the pinapple without any ICS, and only with phising sites, then you should still be able to connect to it from a mobile device... so i dont think that binding it to 172.16.42.42 would be the right way to go... Quote Link to comment Share on other sites More sharing options...
Mr-Protocol Posted December 12, 2011 Share Posted December 12, 2011 The pineapple phishing that Darren showed in Mark II videos had no internet connected to it. You just target most common sites. I personally don't see a need to restrict the /pineapple page due to the need for the root/password. I don't understand what you are trying to say "binding" to the 42.42 IP when that is just the default gateway for the pineapple. Quote Link to comment Share on other sites More sharing options...
foxof Posted December 12, 2011 Share Posted December 12, 2011 The pineapple phishing that Darren showed in Mark II videos had no internet connected to it. You just target most common sites. I personally don't see a need to restrict the /pineapple page due to the need for the root/password. I don't understand what you are trying to say "binding" to the 42.42 IP when that is just the default gateway for the pineapple. 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 Quote Link to comment Share on other sites More sharing options...
Mr-Protocol Posted December 12, 2011 Share Posted December 12, 2011 I wonder if possibly making it HTTPS would be a quick fix for such things. For me I see the chances would be low of someone getting into it. Most people are not all that great at understanding the packets captured and such, but maybe something should be done to secure it a little better possibly. In regards to the white/black list, it should be there, at least it is on the 1.9 Seb firmware on my AP51. Quote Link to comment Share on other sites More sharing options...
Sebkinne Posted December 12, 2011 Share Posted December 12, 2011 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 Again, I am looking into a better option. Give it until next week, I just have a lot to do at the moment.. Best, Seb Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.