hype-free
I want to preface this with the fact that I have an big respect for HDM and his colleagues, both because of technical achievements and for creating this framework in the open, with an enthusiastic community around it. However... :-)
Some time ago I played around a little with Metasploit for the latest Ethical Hacker Challenge and found it incredibly frustrating. My main gripes are:
It is incredibly slow. Just to give you an idea: to generate a small executable (couple of hundred bytes long), it takes well over a minute! I assume that mostly this is because it is written a Ruby, a decision which I can't understand. Version 2.x was written in Perl, and for some reason (most probably because some thought that this was the "next big thing" and wanted to play around with it) they rewrote the whole thing in Ruby, more than doubling the line count by their own admission.
Now I'm the first to admit that LOC is not a very useful measure, however abandoning an existing codebase running on a mature interpreter with some very useful tools is a questionable decision, to put it mildly.
The utter lack of documentation. Their "user manual" is 30 page of uselessness. All the materials that I could find out there were videos, which (a) wastes my time, because I can't scan it rapidly to find the important information (b) wastes bandwidth and (c) is not properly indexable by the current search engines. Also, a lot of documentation is outdated. For example, almost none of the documentation I found seems to mention that msfpayload can now produce Windows executables, without going trough msfencode:
./msfpayload windows/meterpreter/bind_tcp X > runme.exe
This is somewhat faster but still sloooooow. Did I mention that the documentation is lacking? Starting msfpayload only tells you that there is an X option, but it doesn't tell you what it does!
The structure of the program is a mess and lacks any apparent logic. Just take a look at the steps you have to perform to connect to a meterpreter deployed with an executable:
- Create the executable as shown previously and run it on the target.
- Use the "exploit/multi/handler", which isn't an exploit per-se and we don't want to handle multiple connections!
- Specify the payload "windows/meterpreter/bind_tcp". Never mind the fact that we specified this when we created the executable!
- Specify the host and the port
- "Launch" the exploit (in fact connect to the running executable or wait for the incoming connections.
Easy and logical, isn't it ;-)? Especially when you don't have any written tutorials telling you about it.
Update: one of the better video tutorials I found was this one. Also the synjunkie blog has some information on the subject.
Subscribe via e-mail
Re: slowness: its loading all ~500 modules on start, even for msfpayload, by just loading nops/payloads/encoders, we could speed this up
ReplyDeleteRe: documentation: honestly it changes fast enough that our documentation is NEVER up to date. the trend lately has been to post wiki howtos for various features, but unless we get a full-time tech writer, its going to be tough to keep up. it really needs a book-length guide to cover every feature, until then docs are going to be sporadic
Re: logic for msfpayload+handler. support for this was never really designed into the framework, its something we managed to hack in later on, you have to specify the payload twice because its two different steps, one possible improvement is to create a new exploit module which just generates the EXE for you in one step
Feel free to email the mailing list or come on our SILC channel to vent - being an open-source, volunteer-only project, we may take a while to resolve everything, but its not through a lack of trying
Heads up, we fixed the msfpayload/msfencode tools to only load the module types they need. This changes the start time from ~15 seconds (no modcache) to less than 1 seconds for msfencode and less than 6 seconds for msfpayload. There are a ton of other speed improvements in the works, and Ruby is indeed slower than Perl for some things, but our biggest enemy right now is growth. The module count between 2.x and 3.x basically doubled and 2.7 was hitting the ceiling in terms of scalability then. Thanks again for the feedback, its nice to see Metasploit used enough that people complain about its warts :-)
ReplyDeleteRegarding documentation, Chris Gates has taken the lead in putting together useful/up-to-date docs. We are working with the Offensive Security folks to build some better/free guides as well, its just going to take some time to get it together. As always, we can use help :-)
ReplyDeleteI love the framework and think HDM is a lower case god for making it free. The idea of stealing my neighbors wireless when I was 17 has now at 23 turned into an IT career i nno small part because this tool made security interesting to learn
ReplyDeleteMade me learn C++ and I got to this page trying to learn more about windows API's. MSF opened the trp door so I can see how deep IT really goes. Thanks to HDM and the core group of nameless folks who do so much to keep the project going.
And while you rant in other threads about the freetards - MSF show a perfect example of keeping a solid core application free while selling additional services. I really hope it works as a model for all the freetards in the world - even those of us that just greatly enjoy the work.