greptrick.com
Incoherent ramblings of an InfoSec professional
Tag Archives: defense
Java – Can’t Uninstall? Whitelist it?
Posted by on 2013/10/27
As with most sizable organizations it is near impossible to uninstall or completely disable Java which sent us on a hunt for a feasible way to contain Java based attacks. What we came up with was restricting it to run only in trusted zones. This worked for APPLET tags when encountered in IE.
What this does is block any applet from running if it is not part of a trusted internet zone. First thing is to identify all the internal trusted zones and add them. Next allow the user to trust their own zones. Most of the time it seemed they knew when there was an applet they wanted to run. To enable this there is a simple registry change value 1C00 in
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 to a value of 0
*Note: (original 10000).
This will prohibit Java from running in the “Internet Zone.” Now for internal sites you can just whitelist them as a “Trusted Zone” for java to run properly. Of course this can be done via GPO for all internal sites and if there are some identified external sites that java is required.
For some fun stats, an enterprise of 15,000 endpoints went from ~1.5 take aways per day down to about 1-2 per month due to Java a java drive by style attacks.
For most organizations updating java is a Herculean effort. So the whitelisting method from within Windows can be a viable alternative that can be quite effective. In recent months Oracle has released Java 1.7U40 which includes whitelisting. This is nice because it will work for browsers other than IE but odds are if you can get to 7U40 you have a good handle on patching anyway so this is less of an issue (except for 0-day). Java calls their implementation “Deployment Rule Sets” (DRS).
A DRS is just a XML configuration file listing the location or hash of a jar and the action to take. You can bypass some of the pop-ups (some pop-ups can’t be disabled such as JAR unsigned), you can flat out block the jar or run the default actions as you would if DRS wasn’t defined. The XML file is parse sequentially so place your allowed jars at the top of the file and place a catch all block rule at the bottom.
Deployment of the rule set is as simple as packing in a signed (from a trusted 3rd party) jar file named DeploymentRuleSet.jar and deploying to the endpoints to be controlled.
Java based whitelisting is a very powerful feature but it is limited. With MSFT based whitelisting users can individually whitelist java for their own uses, but it is limited only to IE. Java based on the other hand does stop end users from whitelisting however it is a larger effort to whitelist and you either have to manage many lists for individual or groups of users or you have to whitelist sites for everyone, package and re-push.
Also, deploy EMET
Sources:
Oracle docs on the setup.
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_rules.html
https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets
Push TrustedSites via GPO
http://www.makeuseof.com/tag/configure-trusted-sites-internet-explorer-group-policy/
Java Whitelisting from MSDN
http://blogs.msdn.com/b/ieinternals/archive/2011/05/15/controlling-java-in-internet-explorer.aspx
Thwarting Client Side Attacks with Software Restriction Policy
Posted by on 2013/05/16
A few weeks ago I started looking at Windows Software Restriction Policy (SRP) and using it to stop client side attacks. This is going to go over some of the options, setup and the results once enabled.
SRP is easy to setup via Group Policy Object (GPO). Inside GPO editor create New Software Restriction Policy. Once create the default will be setup. You can look around to see basic options. Here is my tested setup.
Enforcement: Select “All Software files” and “All users except local administrators”
Under Designated File types: Remove type LNK – this will make sure that shortcuts placed outside of the designated execution directories will run. When I initially tested what I thought would work none of the shortcuts on the toolbar or desktop would launch an application and I found this to be the issue.
Ignore trusted publishers, this is used if we are limiting applications based on the certificate authority.
Select “Additional Rules”
The default execution directories will be selected.
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%
Since mine is 64bit Windows I added
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
Security level for these are all going to be “Unrestricted” I want them to be able to execute as normal.
Now back under “Security Levels” the default setting is Unrestricted, since we are changing users over to defined execution directories I want to set anything not specifically allowed in the Additional Rules section to “Disallowed.” So we change the default to Disallowed.
Save this and run gpupdate /force on the target machine.
Now to test a client side attack using SET. I am going to use the java attack method. 1 -> Social-Engineering Attacks, 2 -> Website Attack Vectors, 1 -> Java Applet Attack Method, 1 -> Web Templates, 1 -> Java Required, 2 -> Windows Reverse_TCP Meterpreter, 16 -> Backdoored Executable – Enter port of listener (default 443)
Fire it up and wait till it starts the payload handler.
Once the handler is started you are ready to test the attack. Go ahead and run the unsafe java applet.
You will notice that the the site is responding but the java applet is unable to execute the payload.
After attempting this and being successful, I tried running SET with PowerShell Injection and to my surprise the attack succeeded. I realized with PowerShell the payload was running from the C:\Windows\sysWOW64\WindowsPowerShell directory which by default is explicitly allowed. To defeat this attack I added the path to the list of Additional Rules and set it to “Basic User”, retested the attack with PS Injection and the attack failed as expected. I tested this with multiple payloads and encoding methods and everyone of them did not result in a successful attack. On 32bit systems PowerShell is located in C:\Windows\System32\WindowsPowerShell\v1.0\ so that directory will need to be accounted for as well.
I ran two other tests, the first was using EXE embedded PDF and an older version of Adobe Reader (9.3). SRP was able to successfully stop this attack.
Finally I tested a physical attack using a USB Rubber Ducky Human Interface Device (HID) from the folks over at hak5 (www.hak5.com). I used a great little payload generator found over on google code (https://code.google.com/p/simple-ducky-payload-generator/ ) It is pretty slick and simple, I used a meterpreter powershell injection payload that didn’t attempt to elevate privileges. SRP was able to successfully stop this attack. If the user had admin privileges and entered in creds in the UAC window it would have worked since I allow Local Admins unrestricted access.
In Production the are likely other directories where code needs to execute, those will need to be added to the allow list. As the config is done, administrators will be able to bypass these rules for installation of software etc. Administrators will also need to ensure that ACLs are properly set since a curious user could move executables into the approved directories and run them. While this is like a bit tough to implement in a very large organization this is a very effective method for stopping client side attacks.
To find other executable directories in use in your environment enable SRP with defaults (fully unrestricted) and set the following registry key:
“HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers”
String Value: LogFileName, <path to log file>
This will log the executable and the directory it was run from a little data mining can determine were applications need to execute from. Also Inventory Collector from Application Compatibility toolkit can assist in this task.
greptrick.com 