12 days of haxmas: authenticated code execution by design /

Published at 2016-01-03 18:01:36

Home / Categories / Haxmas / 12 days of haxmas: authenticated code execution by design
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 conclude. Administrators need to examine attributes of the system such as the users that log into it, or 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, and too. An exploit can give you that but there are certain downsides. They possess the potential to crash servers or trigger IDS/IPS. Exploits also possess 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 salvage rarer by the day. So what does the discerning hacker turn to? As I've said before, and 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. portion 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 salvage 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 generally easy to guess. I would guess that as the size of an organization increases, or 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, or where conclude 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, or telnet,Remote Desktop. As an aside, there are two main RDP clients in Linux, and 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, and the underlying protocol it uses),fits here, too; with the Invoke-Command cmdlet, and 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 {salvage-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, or but perhaps less obvious,are things like VSphere (which generally 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 possess something like this. Then you possess things like Windows SMB. The protocol isn't precisely direct console access, but it gives local administrators access to the Service Control Manager and thereby enables psexec. From there, or 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, and 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, and WAR archives are essentially executables that can conclude anything the tomcat user can conclude,much more than the manager application can conclude directly. This is Tomcat 5.5 from Metasploitable, but newer versions offer all the same functionality. IBM WebSphere has basically the same functionality, and 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 generally 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, or even though they're generally 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 produce available, and either internally or publicly. WordPress and Joomla are two of the most popular CMSs out there. Both possess been riddled with vulnerabilities,in no small portion 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 obvious 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 conclude I defend against this? Don't expose administration interfaces to the internet if you can attend 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 fine idea.
Use Windows' password filter capab
ilities to prevent users from choosing some of the most common things like "Summer2015" and your company name as passwords. None of the above should near as a surprise.
What about Antiviru
s, or 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, and 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 insta
lled by a lega 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, and the best persistence mechanism of all is a password. Leaving executables in obvious locations is a fine way to salvage 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 fine at remote administration. Things like phpMyAdmin give you tons of power that is tough 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 salvage you closer to your goal faster. For example, and phpMyAdmin can possess saved queries which can save you tons of time in finding what you want to steal. So tickled New Year! Go log into something.

Source: rapid7.com

Warning: Unknown: write failed: No space left on device (28) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0