Threat Intelligence

2/6/2018
02:30 PM
Rami Sass
Rami Sass
Commentary
50%
50%

AutoSploit: Mass Exploitation Just Got a Lot Easier

But the response to the new hacking tool, now readily available to the masses of script kiddies, has been a mix of outrage, fear, some applause, and more than a few shrugs.

Hacking, like any form of security, is a numbers game. Attackers, even very capable ones, are limited in the number of targets that they are able to hit in accordance with the level of resources at their disposable. A larger team can attempt to seek out more targets, pinging them for vulnerabilities, but there are only so many hours in the day to compile lists of potential systems to p0wn and find the right exploit to break into a system and make off with the goods.

Now a new hacking program, AutoSploit, which was released last week on GitHub by a security researcher and hacker who uses the Twitter nom de guerre VectorSEC, is making it easier to erase this balance between resources and capacity.

AutoSploit is an apt name for this new tool, which essentially automates the majority of the hacking process. VectorSEC has combined two existing tools: Shodan.io,  which works like Google for searching out connected devices, and the penetration testing tool Metasploit to create something interesting to some, dangerous to others. Essentially, the program uses the Shodan API for finding potential targets. As VectorSEC explains on his GitHub page, "The program allows the user to enter their platform specific search query such as Apache, IIS, etc, upon which a list of candidates will be retrieved."

Apache, for example, is a very commonly used open source project, which GitHub shows to have over 9 million commits. Being such a large project, many of its libraries are likely to have vulnerable versions that could be exploited, which is where VectorSEC uses Metasploit. Instead of looking up which versions of Apache (or any other project that the hacker wants to target) have known vulnerabilities, AutoSploit uses a "Hail Mary" method to try the system for all possible exploits until it determines that there are no holes in the security, or it hits paydirt. The bad news: because this entire process is automated, it could possibly be used by low-level hackers for great gain. It is safe to say that the thousands of organizations using popular Apache projects such as Struts and Tomcat could find themselves in a world of hurt if their systems are not patched.

Mixed Reaction
So far the response to AutoSploit has been a mix of outrage, fear, some applause, and more than a few shrugs. Many have voiced concern that the tool could change the battlefield of security from a game of bows and arrows to one of carpet bombing, calling VectorSEC wildly irresponsible for putting a cyber weapon of this sort out for public consumption. Although these two tools have been around for some time, it is the combination of them in a single package that has folks worried. Others, like security expert Dan Tentler, point out that by taking two tools that can cause trouble on their own and then combining them in an automated process, VectorSEC has dumbed down the field of hacking.

The idea of people using tools developed by others for carrying out hacks is hardly new. Black markets for exploit kits have been around for years, populated by criminals who lack the proper technical understanding to write the malware themselves. However, by posting his tool on GitHub as open source under a GNU license for all to play with, VectorSEC has taken the hacking of systems to a whole new level with increased availability.

Those who view AutoSploit as a positive measure contend that by making exploitation so easy and available to the masses of script kiddies, it could encourage organizations to really implement solutions that can keep them safe not only from this exploit kit but from more-experienced hacker teams as well.

In the meantime, others in the open source community have stepped up to prevent some of the worst potential damage from AutoSploit. Security expert Jerry Gamblin posted to GitHub his own bit of code that he says will block Shodan from being able to scan your systems. However, it is questionable as to whether this response will be widely used, considering the generally poor performance of the software industry for implementing critical patches when they are announced from the project managers themselves.

Related Content:

Rami Sass is CEO and co-founder of WhiteSource. Rami is an experienced entrepreneur and executive with vast experience in defining innovative products, leading technology groups and growing companies from seed level to business maturity. Before founding WhiteSource, Rami ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Ram.Sass
50%
50%
Ram.Sass,
User Rank: Author
2/15/2018 | 7:29:02 AM
Re: MSF and Mobile
So the short answer is probably not a big issue for mobile at this point. As far as I know, Shodan searches only for IP addresses, finding the folks who were negligent in adding protections. Mobile only really has an IP when it connects to a router for wifi connectivity. Android, arguably the largest open source project, would probably have quite a number of exploits that could be hit, but I'm not sure that Autosploit would really know how to find the devices, since it is dependent on Shodan for building its target list. I hope that this makes sense. I'll of course be following this story to see how it evolves.
Ram.Sass
50%
50%
Ram.Sass,
User Rank: Author
2/11/2018 | 11:19:50 AM
Re: Example
At this point, it's hard to tell which projects it will impact most, but we can assume that the most popular ones will be most affected since there are more targets to hit with this wide net approach. For example, a lot of IoT type devices (which are basically small servers) are based on Linux-based toolkits and are rarely if ever patched. What will be interesting to follow is whether this leads to more folks getting on top of their patching ops, although this is unlikely to make it to the airwaves.
ragediver24
50%
50%
ragediver24,
User Rank: Strategist
2/8/2018 | 8:34:57 PM
MSF and Mobile
Will this work for mobile devices as well? Since MSF can hack Android on Kali? 
aumickmanuela
50%
50%
aumickmanuela,
User Rank: Strategist
2/7/2018 | 9:57:36 AM
Example
What other examples can you add? Any other projects? 
aumickmanuela
50%
50%
aumickmanuela,
User Rank: Strategist
2/7/2018 | 9:57:22 AM
Example
What other examples can you add? Any other projects? 
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
White Hat to Black Hat: What Motivates the Switch to Cybercrime
Kelly Sheridan, Staff Editor, Dark Reading,  8/8/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-13106
PUBLISHED: 2018-08-15
Cheetahmobile CM Launcher 3D - Theme, wallpaper, Secure, Efficient, 5.0.3, 2017-09-19, Android application uses a hard-coded key for encryption. Data stored using this key can be decrypted by anyone able to access this key.
CVE-2017-13107
PUBLISHED: 2018-08-15
Live.me - live stream video chat, 3.7.20, 2017-11-06, Android application uses a hard-coded key for encryption. Data stored using this key can be decrypted by anyone able to access this key.
CVE-2017-13108
PUBLISHED: 2018-08-15
DFNDR Security Antivirus, Anti-hacking & Cleaner, 5.0.9, 2017-11-01, Android application uses a hard-coded key for encryption. Data stored using this key can be decrypted by anyone able to access this key.
CVE-2017-13100
PUBLISHED: 2018-08-15
DistinctDev, Inc., The Moron Test, 6.3.1, 2017-05-04, iOS application uses a hard-coded key for encryption. Data stored using this key can be decrypted by anyone able to access this key.
CVE-2017-13101
PUBLISHED: 2018-08-15
Musical.ly Inc., musical.ly - your video social network, 6.1.6, 2017-10-03, iOS application uses a hard-coded key for encryption. Data stored using this key can be decrypted by anyone able to access this key.