View Issue Details

IDProjectCategoryView StatusLast Update
0003041Kali Linux[All Projects] Kali Package Bugpublic2016-05-11 07:54
ReporterzeroSteiner Assigned Tosbrun  
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version2016.1 
Target VersionFixed in Version2016.2 
Summary0003041: King-Phisher Dependencies Missing
DescriptionKing-Phisher package deployment for Kali Linux Rolling 2016.1 is missing required dependencies causing the King Phisher Server to fail when responding to RPC requests.
Steps To Reproducesystemctl start ssh
systemctl start king-phisher
/user/share/king-phisher/KingPhisher
(at this point the client and server both appear to be running correctly; but users are unable login to the king-phisher server instance)
attempt to login through the client by providing your local username and password
IE
server: localhost
name: root
password: toor
press connect
you should get RPC failed please verify server is running.

If you run wire-shark you will see the client connect to port 80, but the server never responds.

to see the missing dependencies and issues caused:
cd /usr/share/king-phisher
python -m unittest -v tests
Additional InformationThe fix is as follows
pip install "py2-ipaddress==3.4.1"
pip install --force-reinstall -I pytz

pytz needs to be reinstalled as it does not have the zoneinfo
'/usr/lib/python2/2.7/dist-packages/pytz/zoneinfo'

to verify all King Phisher components are working correctly run unit tests again
cd /usr/share/king-phisher
python -m unittest -v tests

start ssh, and the king-phisher services
start the client and attempt to login, it should be successful.

I would like to work further with the team to have the king-phisher package deployment moved to a PostgreSQL database instance as King-Phishers support for SQLite is very limited. When a new database schema is released a new SQLite database would have to be created and the old database would be incompatible as it does not support database schema upgrade capabilities. More information can be found at https://github.com/securestate/king-phisher/wiki/Database.

Looking forward to working with you.
zeroSteiner

Activities

rhertzog

2016-02-08 09:41

administrator   ~0004676

Hello,

thanks for notifying us. We will need your help to fix properly those issues. Let me explain both problems...

For py2-ipaddress, there are two different backports of the Python 3.3+ ipaddress module. There's the one you picked and the one which is packaged in Debian/Kali: https://pypi.python.org/pypi/ipaddress/1.0.16

Both provide the same ipaddress module and they can't be co-installed. Thus it would be nice if you could use the version packaged in Debian (which is also the most popular on pypi and in general). I was hoping they would be compatible as they are supposed to be a backport of the same API but apparently they are not. Can you switch to "ipaddress" ?

Now there's the question of pytz. The version in Debian does not contain the zoneinfo file but it has been patched to use the zoneinfo files provided by the tzdata package (aka /usr/share/zoneinfo). If you use the pytz API properly, things should work... but you are relying on the fact there's a zoneinfo directory near the pytz/tzfile.py and this is a bad assumption to make

Can you fix your code to not make this assumption ?

I tried hardcoding zoneinfo_path in king_phisher/ics.py to /usr/share/zoneinfo to see if it helps but I still get failures related to timezone handling.

I think you should find a way to not need to parse the zoneinfo file yourself.

Let me know your thoughts.

For the postgresql support, let's discuss this once we have fixed the above issues.

MqFuhA9Cze

2016-02-09 22:54

reporter   ~0004689

So to follow up with this we've implemented changes to support your preferred ipaddress module and they have been submitted in a pull request (PR#67) which is currently waiting to be reviewed and tested.

As for the pytz issues, the files have to be accessed because the necessary information is not exposed via the pytz API. King Phisher needs to be able to extract the duration information for Day Light Savings time for different regions and in order to do that the files have to be processed manually. While implementing the feature which required this we were unable to identify a suitable Python module that provided this information. Commit e0ee0aa6ab however adds support for identifying zonefiles stored in /usr/share as a compromise.

rhertzog

2016-02-18 14:17

administrator   ~0004726

I see the required fixes have landed in the "dev" branch. Can we safely do a new snapshot release based on dev? Or shall we rather wait the next official release?

Or do you want to provide us the minimal patches to use (or list of commits to cherry-pick) on top of the current 1.1.0 release?

zeroSteiner

2016-02-18 14:30

reporter   ~0004728

We're finalizing our testing today and will be merging dev into master by the end of the day tomorrow. If possible I'd prefer to do a snapshot release based on master after that has occurred. I think that would be the easiest solution for everyone.

zeroSteiner

2016-02-19 14:16

reporter   ~0004736

We finished our testing yesterday and these changes have been merged into the master branch. When ever you have the opportunity you should be good to proceed to make a snapshot release.

The only other problem we noticed and wanted to mention was that the python-gi-cairo package was missing. A separate ticket was opened for it, ID 0003054.

rhertzog

2016-02-23 17:10

administrator   ~0004756

king-phisher 1.1.0+git20160222-0kali2 solves the problems with pytz and ipaddress (and adds the missing dependency on python-gi-cairo). The test suite is running (and passing) during the build...

Now there's the postgresql setup which is left. By default postgresql does not run on Kali and so it's difficult to do the required setup at package installation time.

We can however possibly modify king-phisher.service to add "Requires=postgresql.service" (or "Wants=postgresql.service" to make it non-fatal) and to run a script via "ExecStartPre" that would read the database configuration from the king-phisher configuration file and that would create the required user and database if they are missing.

This is something that could be integrated on your side (i.e. upstream). What do you think of this idea?

zeroSteiner

2016-03-21 18:34

reporter   ~0004999

I've been looking into the postgresql support issues. What you're describing sounds like it would work. I could handle creating the database and adding the database user automatically.

The only question I have before I add this in is would it be possible for the installer to generate the connection string and place it into the server configuration file? This would also need to generate a random password. The problem I'm trying to avoid is determining when postgresql should be setup with a new user and database versus just using sqlite as it's currently configured to.

The included installation script handles the creation of the connection string in these 5 lines: https://github.com/securestate/king-phisher/blob/master/tools/install.sh#L353-L357

rhertzog

2016-03-21 19:23

administrator   ~0005000

It's fine if you want to modify setup.sh to setup the postgresql connection string by default. We don't use it but we can replicate something similar in the postinst script (with debconf).

But the CREATE USER / CREATE DATABASE should really happen at runtime in the PreExec script like I said so that we have a way to ensure that PostgreSQL is running. You could protect all this with a check on the existence of the database...

if ! su - postgres -c "psql -l" | grep -q '^king_phisher$'; then
   su postgres -c "psql -c \"CREATE USER king_phisher WITH PASSWORD '$PG_KP_PASSWORD';\"" &> /dev/null
   su postgres -c "psql -c \"CREATE DATABASE king_phisher OWNER king_phisher;\"" &> /dev/null
fi

rhertzog

2016-03-21 19:24

administrator   ~0005001

BTW I did not test my check, I think I miss some options to control the output of "psql -l" but you get the idea.

zeroSteiner

2016-03-21 19:40

reporter   ~0005002

I was planning on having the server check the status of postgresql using systemctl (or upstart depending on whats available) and starting the service if it's not already running. That way the logic can be kept within Python, eliminating the need to parse the configuration file to obtain the user database name and password. It can do that while it's still running as root before it drops its privileges.

Additionally this way if the user explicitly switches back to sqlite in their configuration file the postgresql service won't be started unnecessarily .

Would that be acceptable?

rhertzog

2016-03-21 21:34

administrator   ~0005003

Sure, but then you must do the CREATE USER and CREATE DATABASE from python too.

zeroSteiner

2016-04-26 12:28

reporter   ~0005164

These changes are in the master branch now. Given only the connection string, the server will now try harder to start the PostgreSQL service via systemd and create the user and database if necessary as well.

Thanks for your patience on this.

sbrun

2016-05-11 07:54

manager   ~0005230

A new version 1.2.0+git20160510-0kali1 will be in kali-rolling in few hours, (using postgresql)

Issue History

Date Modified Username Field Change
2016-02-05 22:37 zeroSteiner New Issue
2016-02-06 09:08 rhertzog Assigned To => sbrun
2016-02-06 09:08 rhertzog Status new => assigned
2016-02-08 09:41 rhertzog Note Added: 0004676
2016-02-09 22:54 MqFuhA9Cze Note Added: 0004689
2016-02-18 14:17 rhertzog Note Added: 0004726
2016-02-18 14:30 zeroSteiner Note Added: 0004728
2016-02-19 14:16 zeroSteiner Note Added: 0004736
2016-02-23 17:10 rhertzog Note Added: 0004756
2016-03-21 18:34 zeroSteiner Note Added: 0004999
2016-03-21 19:23 rhertzog Note Added: 0005000
2016-03-21 19:24 rhertzog Note Added: 0005001
2016-03-21 19:40 zeroSteiner Note Added: 0005002
2016-03-21 21:34 rhertzog Note Added: 0005003
2016-04-26 12:28 zeroSteiner Note Added: 0005164
2016-05-11 07:54 sbrun Note Added: 0005230
2016-05-11 07:54 sbrun Status assigned => resolved
2016-05-11 07:54 sbrun Resolution open => fixed
2016-05-11 07:54 sbrun Fixed in Version => 2016.2