Last updated at Mon, 17 Apr 2023 21:40:07 GMT
This post is the tenth in the series, "The 12 Days of HaXmas."
What's your favorite exploit?
My favorite exploit is not an exploit at all. It's authenticated code execution by design.
As an attacker, what you're really looking for is the ability to control a system in all the same ways that a system's normal users and administrators do. Administrators need to examine attributes of the system such as the users that log into it, the software installed on it, the services running on it, and most importantly the data it is meant to process. All of which are important for attackers, too.
An exploit can give you that but there are certain downsides. They have the potential to crash servers or trigger IDS/IPS. Exploits also have a half life before they're patched out of existence. Sure, you'll still find an occasional Windows 2000 box vulnerable to everything, but they get rarer by the day. So what does the discerning hacker turn to?
As I've said before, my absolute favorite type of vulnerability is authenticated code execution by design. What I mean by that is taking advantage of services that already exist on a network for administrators and users to login to and run commands or executables in the normal course of doing their job. Part of why it's my favorite is because it's not really a vulnerability -- it's just using the system how it was meant to be used.
How does the enterprising attacker get these credentials, you ask? Talk to any penetration tester and they'll give you a list of their favorite ways. Most of those lists will include mimikatz but it is not the only thing by any means. Many tools and devices leave creds lying around in plaintext (or an obfuscated plaintext equivalent) all over the place. If an attacker can't find credentials, they're usually easy to guess. I would guess that as the size of an organization increases, the probability of at least one user having a password like "Summer2015" approaches 1. Suffice it to say that once an attacker has a foothold into an organization, the credentials will rain down in a flood of access.
Ok, I see your point, where do I use all these stolen credentials?
Well, lots of places, that's why it's my favorite.
Login services
The most obvious servers are those that give direct console access: SSH, telnet, Remote Desktop. As an aside, there are two main RDP clients in Linux, rdesktop(1) and xfreerdp(1). The latter is capable of connecting to newer servers that require network authentication as opposed to typing creds into the normal Windows logon screen.
For bonus points, sometimes VNC is configured with no password, turning it into unauthenticated code execution by design.
Powershell remoting (along with WinRM, the underlying protocol it uses), fits here, too; with the Invoke-Command cmdlet, you can run arbitrary powershell commands on a target server with the current user's (or a supplied user's) rights. Here's an example of what that looks like, directly from MSDN:
PS C:\> Invoke-Command -ComputerName S1, S2 -ScriptBlock {Get-Process PowerShell}
PSComputerName Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
-------------- ------- ------ ----- ----- ----- ------ -- -----------
S1 575 15 45100 40988 200 4.68 1392 PowerShell
S2 777 14 35100 30988 150 3.68 67 PowerShellAlso in this category, but perhaps less obvious, are things like VSphere (which usually runs on TCP port 902) that allow you to manage virtual machines via some sort of console access. All of the major virtualization technologies and VPS providers have something like this.
Then you have things like Windows SMB. The protocol isn't exactly direct console access, but it gives local administrators access to the Service Control Manager and thereby enables psexec. From there, you can run powershell commands, avoiding all the unpleasantness associated with dropping files.
Server administration
In the java web app world, there are tons of middle-ware doohickeys intended to ease deployment. They vary in complexity and scale, but most of them offer some sort of administration console as a webapp. The one you're most likely familiar with is Tomcat, since it's installed on Metasploitable2. Tomcat's /manager application is intended for administrators to manage installed applications, including the ability to deploy new applications by uploading a WAR archive. Once deployed, WAR archives are essentially executables that can do anything the tomcat user can do, much more than the manager application can do directly.
This is Tomcat 5.5 from Metasploitable, but newer versions offer all the same functionality.
IBM WebSphere has basically the same functionality, with the added fun that it often manages multiple servers in a cluster.
Then there are the tools that aren't direct login services, but which are intended for doing all the tasks an administrator would want from such services in a web interface; Plesk and CPanel are popular examples. They provide filesystem access including uploads, often direct command execution, and usually an extension/plugin system that allows code execution in whatever language they're written in. In addition, you can use them to enable direct console access, e.g. through CPanel's SSH key manager:
I place phpMyadmin / phpPgAdmin in this group as well, even though they're usually not code execution in the sense of running an executable or a command. The potential they offer is incontrovertible, though.
Content Management Systems
A CMS is ostensibly just for content, i.e. blog posts or other such user-facing things an organization wants to make available, either internally or publicly. WordPress and Joomla are two of the most popular CMSs out there. Both have been riddled with vulnerabilities, in no small part due to their flexible plugin systems and an ecosystem allowing anyone to publish their own code that end-users can easily install in a language that is notoriously difficult to write securely. But what may not be immediately apparent is those plugin systems themselves are also authenticated code execution by design. Themes and plugins in both WordPress and Joomla are just PHP code. An authenticated admin can load themes and plugins from anywhere.
How do I defend against this?
Don't expose administration interfaces to the internet if you can help it.
Audit successful logins. You should know if Bob from accounting logs into an engineering server at midnight on a Saturday. Likewise, you should know if anyone logs into a hundred boxes in ten minutes. And that activity should throw some red flags.
Segment your networks. Bob from accounting probably shouldn't be able to reach those engineering servers at all.
Change defaults.
Don't reuse passwords. Microsoft's Local Admin Password Solution (LAPS) seems like a pretty good idea.
Use Windows' password filter capabilities to prevent users from choosing some of the most common things like "Summer2015" and your company name as passwords.
None of the above should come as a surprise.
What about Antivirus, Intrusion Prevention Systems, Application Whitelisting?
With some technologies like SSH and Remote Desktop, AV evasion is not even a minor concern because you're using something that's already there, signed by the vendor, and approved by IT.
What about patching?
There's nothing to patch. It's not a vulnerability. There are no CVEs for "Remote Desktop is enabled" or "Your server works the way it is supposed to." These types of tools are everywhere and will live forever.
Conclusions
Using a remote administration tool that was installed by a legitimate administrator has a lot of advantages.
First, it isn't suspicious. AV will not freak out about using something that was installed by IT and whitelisted by an administrator. IPS doesn't care when a legit account logs into a legit app and uses it like it's supposed to be used.
Second, the best persistence mechanism of all is a password. Leaving executables in obvious locations is a good way to get caught by those meddling incident response folks but a successful login is at best ambiguous.
Third, it turns out that software intended for remote administration is pretty good at remote administration. Things like phpMyAdmin give you tons of power that is hard to match with a necessarily simpler payload. They're also preconfigured by kind administrators in anticipation of your arrival. Because they're setup specifically for the environment in which they run, their settings and their data can get you closer to your goal faster. For example, phpMyAdmin can have saved queries which can save you tons of time in finding what you want to steal.
So happy New Year! Go log into something.