View Issue Details

IDProjectCategoryView StatusLast Update
0000694Kali LinuxKali Package Bugpublic2013-11-14 10:37
ReporterErwan.lr Assigned Torhertzog  
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.0.5 
Fixed in Version1.0.6 
Summary0000694: wpscan_2.1+git20131024-1kali0 Still not working
Description

Hi,

I am a dev of the WPScan tool and noticed it's still not properly working in the latest version of Kali (especially after an apt-get dist-upgrade)

Please use the latest git version as I've just committed some stuff for Kali

First of all, two Gems are missing:

  • ruby-progressbar (>= v1.2.0)
  • terminal-table (> v0)

Then, there are two options:

  • create a .bundle/config file into /usr/share/wpscan and put these lines:

    BUNDLE_WITHOUT: test

  • run "bundle install --without test" in the wpscan directory, however this will require the ruby1.9.1-dev package (otherwise there will be an error during the installation of the ffi gem)

Finally, you can also delete the spec directory as it's not useful in a prod environment (this will also delete the wordlist which is linked to a testing file from /usr/share/wpscan/spec/fixtures/wpscan/modules/bruteforce/wordlist.txt)

Steps To Reproduce

Fresh install of Kali Linux 1.0.5

apt-get update && apt-get upgrade
apt-get dist-upgrade

$ wpscan --version
Could not find gem 'ruby-progressbar (>= 1.2.0) ruby' in the gems available on this machine.
Run bundle install to install missing gems.

Additional Information

Any issue please let me know :)

Activities

rhertzog

rhertzog

2013-11-08 11:36

administrator   ~0001062

I wanted to fix this "quickly" but it turns out that it's a can of worms. You can follow the progress in the kali-proposed-updates repository ("deb http://http.kali.org/kali kali-proposed-updates main" in /etc/apt/sources.list).

I started by following your advice:

  • I updated ruby-ruby-progressbar and fixed it to have proper rubygems integration
  • I fixed ruby-terminal-table to have proper rubygems integration
  • I updated wpscan (2.1+git20131108-0kali1) and disabled the test dependencies in bundle

But wpscan still doesn't work properly. wpscan used to have a hack that disabled bundler and thus allowed packaging mistakes to go unnoticed. But now it complains of other missing gems... for example ruby-ethon depends on ffi (>= 1.3.0) but Kali/Debian only has 1.0.11.

Erwan.lr

Erwan.lr

2013-11-08 11:45

reporter   ~0001063

In Kali 1.0.5, the hack to exclude bundler doesn't work anymore (it was relying on the output of the uname -a) and therfore has been removed in the git version.

For ffi, you will need the ruby1.9.1-dev package then (to be able to install it from the "gem install") :/

rhertzog

rhertzog

2013-11-08 11:53

administrator   ~0001064

I backported ruby-ffi 1.9.0 from Debian unstable to Kali and now wpscan seems to start correctly.

Please have a go with the packages of kali-proposed-updates and let me know your results. You can also wait until tomorrow and try the daily ISO image:
http://archive.kali.org/kali-daily-images/kali-linux-daily-amd64.iso

If everything is OK, I'll move the package to the main kali repository.

BTW thank you for caring about wpscan in Kali!

rhertzog

rhertzog

2013-11-08 11:57

administrator   ~0001065

BTW in Debian/Kali we package ruby libraries system wide and we have a rubygems integration shim (package rubygems-integration) so that bundle and other gem users find the correct ruby library. So users don't need ruby-dev at runtime, it's only needed by the build of the respective ruby extensions packages (in this case ruby-ffi).

rhertzog

rhertzog

2013-11-08 14:55

administrator   ~0001066

Sorry, I have been too quick... during my tries I dropped the test gems from the Gemfile and under this condition, it works. However when I keep those in the Gemfile, it fails despite the .bundle/config which says to ignore them.

It looks like that as long that Gemfile.lock doesn't exist, it wants to have access to all gems, whatever their group. So I should really create that file at build time... however the resulting binary package will not be able to ensure that we have the exact same version of all gems mentionned in Gemfile.lock. I wish there was a way to run bundler without requiring this Gemfile.lock.

rhertzog

rhertzog

2013-11-08 20:33

administrator   ~0001068

After a few hours of battle, I think I have cleaned up the situation. I had to update quite a few ruby-* packages and package some more that were missing. This is now all done in kali-proposed-updates.

rhertzog

rhertzog

2013-11-08 20:35

administrator   ~0001069

As for wpscan, I opted to patch it to drop the bundler support. This is now implemented in wpscan 2.1+git20131108-0kali2.

Please test and let me know if it works for you!

Erwan.lr

Erwan.lr

2013-11-09 10:42

reporter   ~0001070

Ok, it works :)

However, I've committed a fix so you will not have to comment this "require bundle/setup" nor the test gems in the Gemfile each time (even if you might have done a script for that :p)

It's basically the same fix as previously (require the bundle unless we are in kali but with a better detection: the previous detection was a grep for "Linux kali" but it fails when the user choose another machine name, like I did :D)

So now the bundle is not required if the "kali" is in the "uname -a"

Tell me if it's Ok for you, and I will tag the release at 2.2

Erwan.lr

Erwan.lr

2013-11-09 11:01

reporter   ~0001071

Facing another issue, as the cache directory is not created in Kali, there is an error with the cache system (and the mkdir method in ruby does not seem to have an option to recursively create directories :o)

Erwan.lr

Erwan.lr

2013-11-09 11:22

reporter   ~0001072

Solved, please use the latest git version :)

rhertzog

rhertzog

2013-11-09 16:10

administrator   ~0001073

Will do but really for things like cache directory, it should not be hardcoded to live within the source tree. The free desktop mandates the usage of $XDG_CACHE_HOME/wpscan/ for example with $XDG_CACHE_HOME defaulting to ~/.cache.

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

For Kali it works because the default user is root, but for any other distro, you won't have the right to create/use that directory if the software is installed system-wide (and not as a git checkout in $HOME).

rhertzog

rhertzog

2013-11-12 10:12

administrator   ~0001074

Hello Erwan, I just checked what you have put in git. The better fix for Kali detection is not much better than the first one. If you want something reliable, you should check /etc/os-release or /etc/debian_version (I have kali chroots for tests where the uname -a check won't work).

I suggest this:

def kali_linux?
File.readlines("/etc/debian_version").grep(/^kali/i).any?
end

rhertzog

rhertzog

2013-11-12 10:33

administrator   ~0001075

I just uploaded wpscan 2.1+git20131112-0kali1 (the latest snapshot from git) to kali-proposed-updates.

Issue History

Date Modified Username Field Change
2013-11-07 15:50 Erwan.lr New Issue
2013-11-08 11:31 rhertzog Assigned To => rhertzog
2013-11-08 11:31 rhertzog Status new => assigned
2013-11-08 11:36 rhertzog Note Added: 0001062
2013-11-08 11:45 Erwan.lr Note Added: 0001063
2013-11-08 11:53 rhertzog Note Added: 0001064
2013-11-08 11:57 rhertzog Note Added: 0001065
2013-11-08 14:55 rhertzog Note Added: 0001066
2013-11-08 20:33 rhertzog Note Added: 0001068
2013-11-08 20:35 rhertzog Note Added: 0001069
2013-11-09 10:42 Erwan.lr Note Added: 0001070
2013-11-09 11:01 Erwan.lr Note Added: 0001071
2013-11-09 11:22 Erwan.lr Note Added: 0001072
2013-11-09 16:10 rhertzog Note Added: 0001073
2013-11-12 10:12 rhertzog Note Added: 0001074
2013-11-12 10:33 rhertzog Note Added: 0001075
2013-11-12 10:33 rhertzog Status assigned => closed
2013-11-12 10:33 rhertzog Resolution open => fixed
2013-11-12 10:33 rhertzog Fixed in Version => 1.0.6