Jump to content

Secure Pineapple Config Interface On Mk3


Recommended Posts

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 by itsm0ld
Link to comment
Share on other sites

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 by itsm0ld
Link to comment
Share on other sites

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

snapshot19.png

Thank you very much itsm0ld. now my pineapple are secure...horayyy:) :)

Link to comment
Share on other sites

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

snapshot19.png

Thank you very much itsm0ld. now my pineapple are secure...horayyy:) :)

Glad you got it working!

Link to comment
Share on other sites

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 by itsm0ld
Link to comment
Share on other sites

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 by httpCRASH
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...