A couple days ago, AutoSploit.py was released by a person named Real__Vector. It’s safe to say that it’s made some waves in the security Twitterverse, and a few people have asked us here at Rapid7 what we think about it given the project’s inclusion of Metasploit, so we figured a short blog might be in order.
The debate around it is actually pretty nuanced. I don’t think anyone believes AutoSploit.py is 100% evil or 100% good, since rarely in the bleeding edge of security research and publication are things that black-and-white.
First, I do want to make it absolutely clear that Rapid7 is a strong supporter of open source security. That goes not only for the software projects that live in F/LOSS-land, and but also the notion of publishing and sharing security research in general. Public, coordinated disclosure of security issues seems to be the best mechanism we have for learning about these things, addressing them, and ultimately making the internet-connected world more secure and productive. That philosophy of open, honest sharing of security expertise is what got us this far, and I haven’t seen any compelling arguments that we should return to a time where only criminals, spies, and the occasional tech company knew the weaknesses and vulnerabilities present in the systems we depend on. Further, I don’t think this position on open source security is controversial — which itself is a testament to how far we’ve all come in this space.
We absolutely believe that the people responsible for defending online assets are best served with complete and accurate information about those online assets, up to and including working exploit code that demonstrates vulnerabilities and weaknesses. This is the rationale behind both Metasploit, and the extensive vulnerability research we conduct.
When it comes to automating aspects of security management, we have long been leaders in this realm. What could be better than a push-button penetration testing robot that automatically finds, categorizes, tests, and reports on all the most exposed, highest risk elements of my network? This was one of the reasons for developing Metasploit Pro, after all — so that offensive security could become more automated and efficient, highlight up-to-the-minute attacker techniques and exploits.
So, given these overall philosophies — open security information sharing coupled with a devotion to automating away what can be automated — we’d like to be able to support AutoSploit.py. Unfortunately, in its current form, the tool really concerns us.
Autosploit.py is unlike the automated platforms for exploitation that are already out there. Tools like Metasploit, Nmap NSE, Armitage, CORE Impact, and the many home-grown scripts that people have cobbled together all have one very important distinction: the targeting is left to the end user, not to a third-party service.
Unfortunately, Autosploit.py depends entirely on the Shodan API to pick targets, and doesn’t appear to offer any mechanism to assess and exploit targets that /aren’t/ picked essentially at random. This is a major bummer, and what throws Autosploit.py into another category of software, apart from those listed above. Sure, people have been using Shodan and Google Dorks to identify exposed systems for years, and we run Project Sonar in order to get a sense of what all’s out there on the internet, insecure and secure alike. In the end, I can’t figure out how to use Autosploit.py in a way that isn’t merely a random act of vandalism. As a user, I have little to no control over target selection, which means I am necessarily going to cause headaches and harm to innocent bystanders.
So, if you ask me what I think of Autosploit.py, I will tell you that I wouldn’t ever run it in its current form, nor would I encourage anyone else to. As written, it is impossible to use in a safe, legal, and ethical way; using it, even just to try it out, would almost certainly land the user in some CFAA hot water if they manage to get a shell with it. I am 100% comfortable with producing Metasploit, because I know all sorts of legal and ethical use cases for it, all of which rely on accurate targeting. I am sure that Real__Vector has (ultimately) good intentions, but handing out a random shell generator just isn’t safe.
Update, Feb 7, 2018: According to this tweet from the author of Autosploit.py, an upcoming version will allow for manual targeting that does not rely on random Shodan-selected targets. Presumably, this functionality will allow users to target only the systems and services they have authorization to test. This is a step in the right direction for this kind of automated exploitation tooling.