fozavci/viproy-voipkit

How I got viproy running

infosecconsultant opened this issue · 4 comments

infosecconsultant commented

I just wanted to leave some notes here about how I managed to get viproy up and running recently after having a lot of issues.

  1. I spun up a new ubuntu install 20.04.1
  2. I installed Kali Linux as per these instructions https://github.com/rapid7/metasploit-framework/wiki/Setting-Up-a-Metasploit-Development-Environment
  3. Instead of following the instruction in the above link to install ruby, I installed ruby v3.0.2 using method 1 here: https://linoxide.com/how-to-install-ruby-on-ubuntu-20-04/ (where the guide says 3.0.0, use 3.0.2)
  4. After confirming ruby was installed successfully and getting the correct output of ruby -v I then followed the rest of the metasploit instructions to install the ruby gems.
  5. I then confirmed that ./msfconsole loaded successfully.
  6. I then cloned and copied the files from https://github.com/fozavci/viproy-voipkit into the relevant folders. This included wordlists/external/core/modules and the modifications to mixins.rb
  7. Despite following instructions, I was getting the following error message:
user@user-virtual-machine:~/metasploit-framework$ ./msfconsole 
/home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader/callbacks.rb:25:in `on_file_autoloaded': expected file /home/user/metasploit-framework/lib/msf/core/auxiliary/msrp.rb to define constant Msf::Auxiliary::Msrp, but didn't (Zeitwerk::NameError)
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/kernel.rb:28:in `require'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader/helpers.rb:95:in `const_get'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader/helpers.rb:95:in `cget'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader.rb:231:in `block (2 levels) in eager_load'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader/helpers.rb:26:in `block in ls'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader/helpers.rb:18:in `each_child'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader/helpers.rb:18:in `ls'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader.rb:226:in `block in eager_load'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader.rb:211:in `synchronize'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader.rb:211:in `eager_load'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader.rb:311:in `each'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/zeitwerk-2.5.3/lib/zeitwerk/loader.rb:311:in `eager_load_all'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/railties-6.1.4.4/lib/rails/application/finisher.rb:133:in `block in <module:Finisher>'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/railties-6.1.4.4/lib/rails/initializable.rb:32:in `instance_exec'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/railties-6.1.4.4/lib/rails/initializable.rb:32:in `run'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/railties-6.1.4.4/lib/rails/initializable.rb:61:in `block in run_initializers'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/3.0.0/tsort.rb:228:in `block in tsort_each'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/3.0.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/3.0.0/tsort.rb:431:in `each_strongly_connected_component_from'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/3.0.0/tsort.rb:349:in `block in each_strongly_connected_component'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/3.0.0/tsort.rb:347:in `each'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/3.0.0/tsort.rb:347:in `call'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/3.0.0/tsort.rb:347:in `each_strongly_connected_component'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/3.0.0/tsort.rb:226:in `tsort_each'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/3.0.0/tsort.rb:205:in `tsort_each'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/railties-6.1.4.4/lib/rails/initializable.rb:60:in `run_initializers'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/railties-6.1.4.4/lib/rails/application.rb:391:in `initialize!'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/railties-6.1.4.4/lib/rails/railtie.rb:207:in `public_send'
	from /home/user/.rbenv/versions/3.0.2/lib/ruby/gems/3.0.0/gems/railties-6.1.4.4/lib/rails/railtie.rb:207:in `method_missing'
	from /home/user/metasploit-framework/config/environment.rb:4:in `<top (required)>'
	from /home/user/metasploit-framework/lib/msfenv.rb:17:in `require'
	from /home/user/metasploit-framework/lib/msfenv.rb:17:in `<top (required)>'
	from ./msfconsole:18:in `require'
	from ./msfconsole:18:in `<main>'
user@user-virtual-machine:~/metasploit-framework$
  1. I found that to fix it you need to modify two lines in your metasploit-framework/config/application.rb file to this:
require File.expand_path('../boot', __FILE__)

all_environments = [
    :development,
    :production,
    :test
]

Bundler.require(
    *Rails.groups(
        coverage: [:test],
        db: all_environments,
        pcap: all_environments
    )
)

#
# Railties
#

# For compatibility with jquery-rails (and other engines that need action_view) in pro
require 'action_controller/railtie'
require 'action_view/railtie'

#
# Project
#

require 'metasploit/framework/common_engine'
require 'metasploit/framework/database'
module Metasploit
  module Framework
    class Application < Rails::Application
      include Metasploit::Framework::CommonEngine

      config.paths['log']             = "#{Msf::Config.log_directory}/#{Rails.env}.log"
      config.paths['config/database'] = [Metasploit::Framework::Database.configurations_pathname.try(:to_path)]
      config.autoloader = :classic
#     config.autoloader = :zeitwerk -------- SET TO CLASSIC TO LAUNCH VIPROY

      case Rails.env
      when "development"
        config.eager_load = false
      when "test"
        config.eager_load = false
      when "production"
        config.eager_load = false
#        config.eager_load = true ---------- SET TO FALSE TO LAUNCH VIPROY

      end
    end
  end
end

# Silence warnings about this defaulting to true
I18n.enforce_available_locales = true
require 'msfenv'

And voilla. It seems to work fine. I'll update here if anything breaks but that it launches and seems to run the modules I've tried is encouraging.

I hope that @fozavci might take a look at some point and update the software and instructions for installing as it's definitely not a super straightforward process to get it running.

Good luck all!

fozavci commented

@infosecconsultant Thank you for the entry. Viproy was discontinued for a long time, hence I didn't update the docs or code at all. However, after your effort here, I updated the Readme to show your fix. I appreciate your effort there, feel free to fork Viproy and create newer repository if you believe it works for you. Keep this in mind, it requires (especially Skinny modules) a lot of Ruby and MSF components called legacy these days. Other readme files may show how they work if you're interested in. Good luck.

infosecconsultant commented

Hi @fozavci no worries.
It has been quite some time since I needed to play with VoIP/SIP and I remembered this tool fondly from several years ago when I saw you demo it at a conference.

Are there other tools you might recommend instead of Viproy these days for VoIP/SIP hacking? Viproy certainly filled a niche that no other tools did and I'm sad to hear that it has been discontinued. Is there any chance that you would get the Metasploit team to merge the modules into the main repo and maintain them going forward?

I will look at building a fork and potentially even dockerizing it to make it more accessible. Depending on the issues though, it might be a bit tricky as I'm not particularly adept at Ruby.

Cheers mate!

fozavci commented

Thanks, I developed it as there was no similar tool for SIP, Skinny, IMS and exploitation. I still don't know any alternative either. I used it to discover and exploit 0days on various UC and VoIP vendors, and presented in events. After I left VoIP/UC space, I left the tools as it was only a PoC. In those days, I have submitted all the modules to Metasploit Framework, but their pull request standards were too high for me renormalise the code, it was a huge effort. Also there is no warranty that the modules would work properly as MSF had core library changes as well. I wish my best to you if you work on it, I would be more than happy to promote it as well.

infosecconsultant commented

Noted. Thanks for the explanations. I noticed that Metasploit does have a few SIP/VoIP modules but they don't really cover the same use cases as Viproy's ones.
I might start looking into Ruby a bit more then and I'll see how it goes... :)
All the best!