State of the Framework Address: Recent Developments in the Metasploit Framework
•
0 likes•609 views
The document summarizes the past, present, and future of the Metasploit framework. In the past, the framework was tied to its directory structure and modules would break if moved. Currently, the focus is on usability, scalability, passwords, better payloads, and post exploitation. Going forward, there will be continued work on authenticated code execution, payloads for additional platforms, and improving post exploitation modules and APIs.
More Related Content
Similar to State of the Framework Address: Recent Developments in the Metasploit Framework
Similar to State of the Framework Address: Recent Developments in the Metasploit Framework (20)
More from egypt
More from egypt (12)
Recently uploaded
Recently uploaded (20)
State of the Framework Address: Recent Developments in the Metasploit Framework
- 2. We interrupt your regularly scheduled programming to bring you…
- 3. The State of the Framework
- 4. Past
- 5. We must know where we came from to know where we are going
- 9. 4.0 3.0 3.6 3.1 3.2 3.4 BSD 2003 … 2007 2008 2009 2010 2011 2012
- 10. Modules by type and release 1400 1200 1000 800 Post 600 Auxiliary Exploit 400 200 0 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4.0
- 11. Auxiliary Exploit Post 1-Jul-2011 Modules Over Time 1-Mar-2011 1-Nov-2010 1-Jul-2010 1-Mar-2010 1-Nov-2009 1-Jul-2009 1-Mar-2009 1-Nov-2008 1-Jul-2008 1-Mar-2008 1-Nov-2007 1-Jul-2007 1-Mar-2007 0 800 700 600 500 400 300 200 100
- 12. Module Format • Originally tied to directory structure – Now more flexible • Module broke if you mv'd it
- 13. Uses for Metasploit • Running exploits, getting shells • Creating exploits
- 15. Present
- 17. Focuses for 4.0 • Usability • Scalability • Passwords • Better payloads • Post exploitation
- 18. Usability • Installers that make everything easy • Help for most commands • Database command improvements • Msfvenom
- 19. Everything Works Out of the Box • Ruby 1.9.2 • Postgres • Java (for msfgui, armitage) • Option to automatically update • pcaprub
- 20. The Database • Auto configured by installer • Now a core feature used by lots of modules – Almost all auxiliaries, many posts • Scales much better than before • Better search capabilities • Workspaces for logical separation
- 21. Scalability
- 22. Recent Focus on Passwords • Authenticated code execution by design is better than an exploit • Obvious: SSH, Telnet, RDP, VNC • Less obvious: – MySQL/MSSQL/PostgreSQL – Tomcat/Axis2/JBOSS/Glassfish – ManageEngine
- 23. Payloads • Dozens of formats and architectures – PHP; Java (jar, war, jsp); Win32, 64; BSD; OSX – x86, PPC, ARM, MIPS, cmd exec, … • Reverse HTTP(s) stagers for Win32, Java meterpreters • Railgun
- 24. Post Modules • Biggest change in a long time • Replaces meterpreter scripts • More comprehensive Post-exploitation API – OMG Railgun – Shell sessions, too – You should have been in Rob and Chris' talk • My utopian ideal: post mods work on all kinds of sessions on all supported platforms
- 25. Moar Passwerdz
- 26. Uses for Metasploit • Running exploits, getting shells • Creating exploits • Auxiliary modules, discovery, systems admin • Post exploitation, looting pwned boxes • Data collection and correlation
- 27. Future
- 28. Future of Exploits • Continued focus on Authenticated Code Exec – Oracle, various CMSes • Hack all the things
- 29. Future of Payloads • Linux meterpreter – Yes, I know I've been saying this for 3 years • Java meterpreter to keep pace with Win32 – Thanks to mihi • Meterpreter needs to only load stuff that makes sense for the platform • IPv6 support for more stuff – Mostly works, 32-bit Windows and Linux payloads – Toredo
- 30. Future of Post Exploitation • Huge amount of community dev going into Post modules • Password stealers for every conceivable application that stores them – Thanks TheLightCosine! • More local privesc exploits
- 31. More Post Exploitation • More and better APIs – Cross-platform pilfering • Easier
- 32. Future of Modules in General • Some form of exploit abstraction • Transport should be a user option – Not a whole different module with the same exploit code – Example: PDF exploits over HTTP, FTP, SMB, email
- 33. Startup Time
- 34. Contributing Should be Easy
- 35. Contribution Workflow Ask about it in Find a bug Submit a ticket IRC Get tired of Tell me I forgot waiting, fix it Submit a patch about it yourself Remind me Give up again
- 37. Documentation • Two main sources of documentation right now – Reading 500k lines of ruby source – Asking me in IRC • It was hard to write, it should be hard to read, dammit!
- 38. Documentation • Updated users' guide • Updated developers' guide • Clean up rdoc
- 39. Installation Should be Easier • Everything should *really* work out of the box • Everything should be configurable from the commandline • Install Express/Pro without another big download of mostly the same stuff – I know, shameless plug, but hey it pays for all the rest of this
- 40. Uses for Metasploit • Running exploits, getting shells • Creating exploits • Auxiliary modules, discovery, systems admin • Post exploitation, looting pwned boxes • Data collection and correlation • And….
- 42. Why? • Metasploit should be the first and the last tool you need • Anything that gets you access – Proof positive tool – Not just exploits, identities • Maintain that access • Use your access to achieve your goals • Store all of the above in a manageable way
- 43. Questions? • If I have ever kickbanned you in #metasploit, I'm sorry – But not that sorry, you should have googled more