search

pentestgeek / phishing-frenzy

Ruby on Rails Phishing Framework
www.phishingfrenzy.com
GNU General Public License v3.0
794 stars 297 forks source link

SSL Certificate - Mix of HTTP and HTTPS #372

Closed zjmc10 closed 6 years ago

zjmc10 commented 6 years ago

Hello,

Apologies, me again. One more issue I encountered after purchasing a certificate to use. We didn't have budget for a wildcard certificate which I feel would make it easier to configure. So from having it working perfectly, I've followed the steps in the Ubuntu instructions to update pf.conf with my cert and key locations. I generated the CSR and obtained the cert for the current subdomain I was using - intel.mydomain.info. I've played around with a few different setting combinations, but not sure the best way to proceed.

Currently I have my Application Site URL set as http://mydomain.info (as applied cert to subdomain).

In Campaign settings I used the https://sub.mydomain.info and FQDN sub.mydomain.info

Configured the SSL files in Phishing Options.

Launching the campaign and clicking the link it delivers successfully - but now back to not having the click or password recorded (built in intel template). The troubleshooting guide helped me earlier when it was just HTTP and I had a silly mistake in the Site URL.

After the changes and the mix between HTTP (for Site URL) and HTTPS for campaign I'm a little stuck. Now output of apachectl -S is:

VirtualHost configuration: :443 is a NameVirtualHost default server intel.mydomain.info (/etc/apache2/sites-enabled/16.conf:13) port 443 namevhost intel.mydomain.info (/etc/apache2/sites-enabled/16.conf:13) alias intel.mydomain.info port 443 namevhost intel.mydomain.info (/etc/apache2/sites-enabled/pf.conf:1) :80 is a NameVirtualHost default server intel.mydomain.info (/etc/apache2/sites-enabled/16.conf:1) port 80 namevhost intel.mydomain.info (/etc/apache2/sites-enabled/16.conf:1) alias intel.mylifehouse.info port 80 namevhost phishing-frenzy.com (/etc/apache2/pf.conf:1) ServerRoot: "/etc/apache2" Main DocumentRoot: "/var/www/html" Main ErrorLog: "/var/log/apache2/error.log" Mutex ssl-stapling: using_defaults Mutex proxy: using_defaults Mutex ssl-cache: using_defaults Mutex default: dir="/var/lock/apache2" mechanism=fcntl Mutex mpm-accept: using_defaults Mutex watchdog-callback: using_defaults Mutex ssl-stapling-refresh: using_defaults PidFile: "/var/run/apache2/apache2.pid" Define: DUMP_VHOSTS Define: DUMP_RUN_CFG User: name="www-data" id=33 not_used Group: name="www-data" id=33 not_used

Any help or pointers would be greatly greatly appreciated!! Thank you.

zeknox commented 6 years ago

When looking at the Apache configuration above it appears that intel.mydomain.info is configured for both 16.conf and pf.conf. Not sure if this is causing a conflict with the overlap but again you want to ensure you have separate FQDN for PF interface, and separate FQDN for phishing sites.

If the stats were working before SSL the first thing I would look at is adjusting the Global Settings > Application Site URL to include the https:// version of the website (assuming PF interface is now running over https).

Now that the configuration change is made your active phishing sites will not pickup the change right away. You need to either make the campaign inactive, and active again so the phishing site is redeployed with new PHP tracking tags which include the https:// version of the PF interface (also you could hit the reload button in the campaign settings since this reloads the apache config and re-deploys the phishing site).

You seem to be super close! Good Luck.

zjmc10 commented 6 years ago

Ok thanks for the tips, I'll play around with the settings a bit more and see if I can get it. Currently I don't have the PF interface running over https:// just the subdomain I was using in the campaign (intel.mydomain.info). The PF interface I just have http://mydomain.info.

I've generally been creating a new compaign after each change I make and restarting Apache in between. I'll recheck the config files and make some changes and see what happens.

zjmc10 commented 6 years ago

Ok got it working and tracking clicks and passwords. I changed back to the original pf.conf since the PF interface wasn't using HTTPS and set the original mydomain.info in the pf.conf instead of the intel.mydomain.info I want to use for my phishing links. I created a new campaign pointing to the certificate files and launched successfully.

The only issue now is I receive the green secure padlock if I go directly to https://intel.mydomain.info but on the phishing link due to images etc it throws up a security warning. I'll have a play around with the templates and see how I go. Thanks again for all your help, looks like I'm ready to move into production mode and do some more testing.

zeknox commented 6 years ago

Regarding the issues over HTTPS, take a look at your browser console and reload the page. Check to see what errors are being thrown in the console.

It sounds like the images want to load over an HTTP source which is an issue when loading the site over HTTPS.

zjmc10 commented 6 years ago

Ok sure thanks, that sounds like what it's doing. One hopefully final thing - I've moved to production mode now but emails don't send. When starting sidekiq I get the same deprecation warnings I did previously, but the little red guy doing the side kick doesn't appear afterwards. I can open the sidekiq console though and it shows 2 failed. I'll have a bit of a read through previous issues as I think I saw a couple of things related to sidekiq previously. Any tips or things to check would be greatly appreciated too. Thanks!

zeknox commented 6 years ago

It's likely because you need to restart the sidekiq service and prepend the RAILS_ENV=production before the command. If you dont pre-pend that then it will try operating out of the development database.

zjmc10 commented 6 years ago

I was running the following:

rvmsudo RAILS_ENV=production bundle exec sidekiq -C config/sidekiq.yml

Looks like PF might not be in production mode for some reason after following the steps. I'll have a poke around and try and work out what's happening.

zjmc10 commented 6 years ago

Well it all seems to be working now! I changed a few things and then restarted Apache and sidekiq so not sure exactly what I had done wrong. But all working in production mode now - sending emails, open, click and password are successful. I should be able to stop bothering you now :)

Really appreciate all your assistance and quick responses. Thank you.