This is the sixth post in the series, "The Twelve Days of HaXmas."
Well, the year is coming to a close, and it's just about time for the annual breakdown of Metasploit commit action. But before we get to that, I wanted to take a moment to highlight the excellent work we landed in 2015 in adding new web application login support to Metasploit. After all, who needs exploits when your password is "public" or "admin" or "password" or any other of the very few well-known default passwords? Maybe it's not the sexiest way to get a foothold on a network, but we are increasingly living in a network environment that hosts loads and loads of unconfigured, insecure Internet of Things devices.
So, let's take a stroll through the new web application login support added over the first half of 2015. Maybe you missed them the first time around, so this sixth day of HaXmas is a fine time to catch up.
Chef and Zabbix
In February of 2015, HD Moore picked up a request for a couple of brute force modules designed to guess the passwords to the web front ends for Chef, the popular DevOps deployment tool, and Zabbix, an enterprise monitoring system. Most web application authentication systems are uniquely implemented; rarely do web applications use HTTP basic authentication any more.
Sussing out the basic API for entering a username and password can take a little time and effort. While there are automatic methods for determining the right format (namely, Rapid7's AppSpider), if you have the wherewithal to do a little investigative work, reading the pull request for the Chef and Zabbix modules is a pretty great example of how to toss off a quick web application brute force module, with the initial work from HD and the landing work from David TheLightCosine Maloney being pretty illuminating.
In March of 2015, contributor Ben Meatballs Campbell of MWR Labs published an advisory about a user enumeration information leak in GitLab. GitLab is a popular open source alternative to GitHub Enterprise, used to host GitHub-like repositories internally for software development.
While he was in that neighborhood, he put together a quick login scanner for GitLab as well, presumably to start guessing passwords for the users just identified via this leak. Again, we can see from the pull request that this kind of web application protocol implementation has gotten pretty straightforward.
In April of 2015, contributor Waqas voidin Ali offered up a login scanner for Nessus, the popular vulnerability scanner. It is suffice to say, if an attacker gets a hold of your vulnerability scanner's authentication credentials, you have some pretty serious problems.
Vuln scanners are one of those network services that makes for an ideal attack platform - they tend to touch a lot of machines through unsolicited connections, which will mask any lateral movement attempts an attacker is likely to make, they have loads of information about the internal network, making an otherwise noisy scanning operation a moot point, and they tend to already be ignored by any sort of internal security control, given how noisy they are normally on the wire.
Routinely checking your vulnerability scanner for weak, guessable, and known passwords is pretty basic internal security hygiene, since the consequences of compromise are so dire. This module makes this task pretty easy.
In March, Wei sinn3r_ Chen put together a login scanner for Symantec Web Gateway, a web proxy used to filter for malware and other sorts of evil from malicious or compromised web sites. While this was an exercise similar to the above web application login modules, the most significant effort in this area happened in May of 2015.
Using his recent Symantec Gateway module as an example, Wei put together the One True Way for writing web application login scanners. This is a pretty critical chunk of documentation, since it's a pretty great HOWTO on quickly and reliably figuring out the login sequence for pretty much any normal web application.
Looking ahead to 2016
Why am I devoting a whole HaXmas post to this corner of 2015 development work? Well, I don't know if you've noticed, but we've been deluged with a massive pile of Internet of Things gear that (a) offer little in the way of built-in security, and (b) offer a lot in the way of default passwords, and (c) are nearly always managed via some custom web application front end. Oh, and (d): I don't -- can't -- imagine a future where we will have fewer of these things.
Today, we have some solid documentation on writing web application login scanners, and a fistful of example implementations. Now, take the fact that most of these devices never get their default passwords changed, we have pretty great chances of guessing correctly if we're on the same network and make a few guesses. As an added bonus, there's now a whole bunch more of these IoT devices which just got unboxed, powered on, and network connected on Christmas morning.
We really do need to get ahead of this problem, and about the best way I can think of to tackle it is to actively explore this space in an open source environment like the Metasploit Framework. So, while you're enjoying this holiday season, maybe take an hour or two to audit your own local home network, see how many web applications you can find, and consider kicking out a corresponding Metasploit module in order to highlight the risk of factory default passwords on these devices.