Mastodawn

OJ 🧗Apr 7, 2017

@[email protected] @0xbc The short answer would be "yes, I think it can be". This is coming from someone who 1) Is currently an active committer to Metasploit, and 2) works on offsec tools for his own purposes.

MSF and the like have grown organically. MSF is where everyone submits their exploits if they want them to live on. Most of those modules are security artifacts now, and very rarely used.

I think the core is still important, and complex though.

Show thread

OJ 🧗Apr 7, 2017

@0xbc @[email protected] A good example of something that requires a great deal more engineering is the direct support for the likes of SMB(1|2|3) directly in the framework. Ability to handle routes through existing sessions is another. Pivoting across sessions through other sessions. There are lots of nuances. But the crux of the exploitation side is definitely loose, and doesn't need the volume it has now.

Show thread

Ben Cheney ❌Apr 7, 2017

@OJ @[email protected] re. volume, are you saying that keeping CVE-1954-whatever around in MSF means that the core implementation around running exploits has cruft in it that would be otherwise unnecessary? Or just that in general it could use a refactor?

FWIW, my use-case for MSF tends to pretty much boil down to Meterpreter and post-exploitation.

(... and still over 100 chars left on the table! :sunglasses: )

Show thread

OJ 🧗

@0xbc @[email protected] I'm modules get pre-parsed and loaded in MSF on start. So yes, any module adds overhead. Same with any software, MSF has a "working set" and reducing that where possible can't be anything but good, especially given it's ruby! The sad thing is that every now and then you'll find some client that has an old device around that's vuln to some crusty old CVE.