7ala / armitage

Automatically exported from code.google.com/p/armitage
0 stars 0 forks source link

Something went wrong: session.compatible_modules #136

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Open a meterpreter shell
2. Right click -> Access -> Escalate Privileges 
or
2. Right click -> Explore -> Post Modules

What is the expected output? What do you see instead?
Modules should be filtered to applicable ones. Instead a java error occurs.

Exact error is Error:java.lang.RuntimeException: Invalid Module

What version of Metasploit are you using (type: svn info)? On which
operating system?
metasploit v4.6.0-2013041701 on Kali Linux

Which database are you using?

Please provide any additional information below.

Original issue reported on code.google.com by y2k...@gmail.com on 26 Apr 2013 at 6:06

GoogleCodeExporter commented 9 years ago
I pulled the latest from R7's repository and was unable to reproduce this 
behavior. It works for me. Do you have any other details that may help me? Does 
this happen every single time or did it happen once?

Original comment by rsmu...@gmail.com on 26 Apr 2013 at 12:00

GoogleCodeExporter commented 9 years ago
It happens every time, and persists across reboots. msfupdate doesn't show any 
new versions either. The following error appears in the console in which 
armitage is running:

[lib/msf/core/rpc/v10/rpc_base.rb:16:in `error', 
lib/msf/core/rpc/v10/rpc_session.rb:215:in `_find_module', 
lib/msf/core/rpc/v10/rpc_session.rb:203:in `block in rpc_compatible_modules', 
lib/msf/core/rpc/v10/rpc_session.rb:202:in `each', 
lib/msf/core/rpc/v10/rpc_session.rb:202:in `rpc_compatible_modules', 
lib/msf/core/rpc/v10/service.rb:149:in `block in process', 
lib/ruby/1.9.1/timeout.rb:68:in `timeout',
lib/msf/core/rpc/v10/service.rb:149:in `process', 
lib/msf/core/rpc/v10/service.rb:89:in `on_request_uri', 
lib/msf/core/rpc/v10/service.rb:71:in `block in start', 
lib/rex/proto/http/handler/proc.rb:38:in `call', 
lib/rex/proto/http/handler/proc.rb:38:in `on_request', 
lib/rex/proto/http/server.rb:355:in `dispatch_request', 
lib/rex/proto/http/server.rb:289:in `on_client_data', 
lib/rex/proto/http/server.rb:149:in `block in start', 
lib/rex/io/stream_server.rb:48:in `call', lib/rex/io/stream_server.rb:48:in 
`on_client_data', 
lib/rex/io/stream_server.rb:192:in `block in monitor_clients', 
lib/rex/io/stream_server.rb:190:in `each', lib/rex/io/stream_server.rb:190:in 
`monitor_clients', lib/rex/io/stream_server.rb:73:in `block in start', 
lib/rex/thread_factory.rb:22:in `call', lib/rex/thread_factory.rb:22:in `block 
in spawn', lib/msf/core/thread_manager.rb:100:in `call', 
lib/msf/core/thread_manager.rb:100:in `block in spawn']
Warning: invalid use of index operator: $null['modules'] at modules.sl:258
Warning: variable '$__frame__' not declared at gui.sl:98

Original comment by y2k...@gmail.com on 26 Apr 2013 at 7:07

GoogleCodeExporter commented 9 years ago
Try:

db_rebuild_cache

Wait a few minutes. If this doesn't work, reinstall the Metasploit Framework or 
at least drop the msf database so it gets recreated. This error isn't an 
Armitage error. It's coming from the framework. I still can't reproduce it.

Original comment by rsmu...@gmail.com on 27 Apr 2013 at 12:29

GoogleCodeExporter commented 9 years ago
Setting up bundler (1.1.4-6) ...
Setting up rubygems-integration (1.1) ...
Setting up metasploit-framework (4.6.0-2013041701-1kali0) ...
Setting up metasploit (4.6.0-2013041701-1kali0) ...

Ok, I have Kali Linux and I ran msfupdate. I can't reproduce this error--but, I 
did do service metasploit stop to make sure all the non-framework stuff is not 
running. Try that too.

Original comment by rsmu...@gmail.com on 27 Apr 2013 at 1:14

GoogleCodeExporter commented 9 years ago
After a database drop, restarting and stopped the services, and then restarting 
the box, it's finally working again. Not entirely sure what the issue was, but 
it looks to have been resolved. Sorry to take up your time

Original comment by y2k...@gmail.com on 27 Apr 2013 at 3:30

GoogleCodeExporter commented 9 years ago
Cool, it sounds like the module cache was corrupted in some way. 

Original comment by rsmu...@gmail.com on 27 Apr 2013 at 1:14

GoogleCodeExporter commented 9 years ago
Can you detail how exactly to drop the database? The problem seems to have 
returned, and none of my previous steps have fixed the issue.

I've done a db_rebuild_cache, stopped and started all services, and restarted 
multiple times. Not sure what is causing the issue exactly.

Original comment by y2k...@gmail.com on 29 Apr 2013 at 12:49

GoogleCodeExporter commented 9 years ago
y2kspy: Have you run any of the commercial products (Community Edition, 
Express, or Pro) in your current install?

Original comment by rsmu...@gmail.com on 29 Apr 2013 at 12:52

GoogleCodeExporter commented 9 years ago
As far as I know, no. I installed this with a simple apt-get install armitage. 
The only things that have been changed configuration wise should be some custom 
modules I wrote myself.

Original comment by y2k...@gmail.com on 29 Apr 2013 at 12:56

GoogleCodeExporter commented 9 years ago
Try:

source /opt/metasploit/script/setenv.sh
dropdb 'msf3'

Original comment by rsmu...@gmail.com on 29 Apr 2013 at 12:57

GoogleCodeExporter commented 9 years ago
Done. Are there any special procedures necessary for recreating the database? 
Or just create a new database called msf3?

Original comment by y2k...@gmail.com on 29 Apr 2013 at 1:00

GoogleCodeExporter commented 9 years ago
It'll recreate itself.

Original comment by rsmu...@gmail.com on 29 Apr 2013 at 1:04

GoogleCodeExporter commented 9 years ago
After a full database drop, the problem persists. Perhaps I'll just reinstall 
metasploit from scratch. Not sure if a purge will remove the custom scripts 
that I wrote, so should I back those up?

Original comment by y2k...@gmail.com on 29 Apr 2013 at 1:06

GoogleCodeExporter commented 9 years ago
before you reinstall... can you email me the ~/.msf4/logs/framework.log file. I 
suspect that this is an environment issue and out of my control, but, I'd like 
to know what's happening too so I can better support folks with the same 
question in the future.

Original comment by rsmu...@gmail.com on 29 Apr 2013 at 1:13

GoogleCodeExporter commented 9 years ago
Absolutely. I'll email it to you right now.

Original comment by y2k...@gmail.com on 29 Apr 2013 at 1:15

GoogleCodeExporter commented 9 years ago
apt-get purge metasploit && apt-get install metasploit enough to do what's 
necessary?

Original comment by y2k...@gmail.com on 29 Apr 2013 at 1:20

GoogleCodeExporter commented 9 years ago
There are several metasploit related packages including metasploit-framework. 
TBH though, I don't really know what it will take under Kali only because I'm 
not that familiar with that environment yet.

Original comment by rsmu...@gmail.com on 29 Apr 2013 at 1:24

GoogleCodeExporter commented 9 years ago
Real quick--you'll want to recreate the db. Try that before a reinstall and 
make sure you restart everything. Try

source /opt/metasploit/script/setenv.sh
createdb 'msf3'

Original comment by rsmu...@gmail.com on 29 Apr 2013 at 1:27

GoogleCodeExporter commented 9 years ago
Also, going through your framework.log file, I'm seeing errors trying to load a 
module. This could explain part of the issue you're experiencing. I don't know 
where this module came from, but I don't have it in my git pull of the source.

[04/28/2013 20:27:11] [e(0)] core: 
/opt/metasploit/apps/pro/msf3/modules/post/linux/gather/sucrack.rb failed to 
load due to the following error:
NameError
uninitialized constant Msf::Core
Call stack:

Original comment by rsmu...@gmail.com on 29 Apr 2013 at 1:29

GoogleCodeExporter commented 9 years ago
That was a module I was working on at the time. I fixed the error, but the 
issue was unrelated. I did an aptitude reinstall metasploit and aptitude 
reinstall metasploit-framework. I also killed the database and recreated it. It 
seems to be working now. I still have no idea what caused it. My best guess is 
that the framework was unhappy about some of the modules I wrote.

Original comment by y2k...@gmail.com on 29 Apr 2013 at 1:44