30 March 2016

Using Symantec Endpoint Protection (SEP) Application & Device Control to Defeat PowerWare


Starting about a week ago, PowerWare ransomware began to propagate in email campaigns using Word documents laced with macros.  PowerWare works by launching cmd.exe via macros contained within the infected Microsoft Word document.  The resulting cmd.exe process in turn calls PowerShell to perform encryption of the files.

PowerWare is a “fileless” malware variant so protection technologies that rely on file signatures or static attributes of executable files have difficulty protecting against this threat.  In the case of PowerWare, opening a Word document and enabling macros can lead to your files being encrypted and held for ransom by the attackers.  This is decidedly bad for business!

Fortunately, Symantec Endpoint Protection (SEP) customers can use some of the granular controls contained in our product to protect against these types of threats.  In particular, the Application and Device Control feature of SEP can be used to provide much stronger controls.  

To protect against PowerWare and similar threats, we created an Application and Device Control policy with two new rule sets to protect against PowerWare and other similar malware that provides two major safeguards.  The resulting Application and Device Control policy is shown below and the two new rule sets are outlined in red.  The remainder of this document describes how these new rule sets function and how they can be created.  (More information on configuring Application and Device Control policies can be found here.)

 
Preventing Process Launch Attempts from Outlook, Word, etc.

In the first new rule set we created, we prevent processes such as Microsoft Word, Excel, Outlook, etc. from launching cmd.exe and/or powershell.exe directly from within these applications.  Preventing cmd.exe and powershell.exe from being directly launched by applications such as Microsoft Word attacks the tactics exhibited by the malware.  There are extremely few, if any, valid business reasons to allow cmd.exe and powershell.exe process launch activity from within Microsoft Word and the other monitored applications.  Hence, any impacts to generic end user workstations should be noted in testing and handled as exceptions. 

The configuration of this rule set is shown in the following images.


 
 
Prevent Monitored Application from Tampering with Critical Executables

In the second new rule set we created, we prevent the monitored Microsoft applications from being able to tamper with cmd.exe or powershell.exe.  This prevents future variants of the malware from simply making a copy of cmd.exe or powershell.exe and then launching the copy of those programs.  While we have not seen this behavior exhibited so far, it does not require much imagination to see that this would be a technique for bypassing the previously discussed controls around process launches from within the monitored applications.  

The configuration of this rule set is shown in the following images.

 

 
Lastly, Symantec provides a standard Application and Device Control rule set as part of the default SEP installation to prevent vulnerable Windows processes including Outlook, Excel, Word and others from being able to write executable files to disk.  This rule set is named  “Prevent vulnerable Windows processes from writing code [AC17]”.  By default, this rule set is not enabled.  However, enabling this rule set can provide a strong additional control that may prove useful in preventing endpoint compromise. 

As threats evolve, so must our endpoint protection solutions.  Paying careful attention to the tactics, techniques and procedures used by attackers and adjusting our endpoint protection posture accordingly can greatly reduce risk for our organizations.  With the flexibility of SEP and Symantec's multi-layered approach to protection, Symantec customers are well positioned to adjust their protection strategy as the threats change. 

15 October 2014

Do you have a POODLE?



There has been a good deal written about the SSL 3.0 POODLE vulnerability today.  SSL 3.0 is nearly 15 years old and, as it turns out, not very secure.  The most definitive description of the issues with SSL 3.0 was written by Google researchers and can be found here.  The official description of the vulnerability, CVE-2014-3566, is located here. 

While the researchers at Google did a nice job of explaining the risk and suggesting some alternatives (like disabling SSL 3.0), they left determining whether or not your server is vulnerable as an exercise for the reader.  If you manage a single site, you can visit this site from Symantec to run a quick test online. 

However, if you manage an entire data center or a corporate intranet, the problem is a little harder.  Never fear, though, because I used my lunch hour to solve the problem for you.  Take a look at this project.

The first script, ssl3_cipher_check.sh, checks a single target for the presence of SSL 3.0 support.  The results will be similar to the following: 

# ssl3_cipher_check.sh 192.168.1.51 443
Testing 192.168.1.51:443 for support of SSL3.0 ciphers...
YES - SSL 3.0 support detected on 192.168.1.51:443

The second script, ssl3_scan.sh, allows you to test an entire network range.  Using a network range specified in CIDR notation or a format compatible with nmap, the script detects and checks the standard and alternate ports commonly used for HTTPS on all hosts in the network range.  Results will be similar to the following:

# ./ssl3_scan.sh 192.168.1.0/24
Beginning test... please be patient...
192.168.1.17:443 - SSL3.0 NOT supported
192.168.1.35:443 - SSL3.0 NOT supported
192.168.1.34:443 - SSL3.0 NOT supported
192.168.1.51:443 - SSL3.0 supported
192.168.1.58:443 - SSL3.0 supported

How you decide to mitigate the risk is on you.  Happy testing!  ;-)

October 20 Update:  Patches are available from OpenSSL.org and are described here.