Costco, BestBuy, Walmart really want to send you a package!
Yes, it's this time of the year again. There's a new wave of email making the rounds, with a message that looks as follows
The URLs look like this
The subject seems to be one of "Delivery Canceling", "Express Delivery Failure" or "Standard Delivery Failure". Next to Costco, the same scam is currently ongoing for BestBuy and Walmart, maybe others. The links are (appear to be) random or encoded, there is no repeat occurrence of the URL and "package number" for the entire sample set that we have. It could well be that the BASE64 portion of the URL contains an encoded hash of the email address to which the phish was sent, so when you play with one of the samples, be mindful that you could be confirming the email address back to the bad guys [for that reason, the two URLs above are facsimile only, and not the real thing]
For a change, clicking on the link doesn't bring up a web form asking for your credit card number. Instead, it quite bluntly downloads a ZIP which contains an EXE. What makes this particular version more cute than others is that the EXE inside the ZIP is re-named on the fly, based on the geolocation of your download request. In my case, this spoiled the fun some, because "CostcoForm_Zürich.exe" and "CostcoForm_Hamburg.exe" didn't look all that credible: There are no Costcos in Switzerland or Germany :).
We have seen this "geolocation" approach at malware delivery used more frequently in the past weeks, for example also in a WhatsApp spam spree ten days ago. I assume someone who would click on "CostcoForm.exe" might be even more inclined to do so if the file is called "CostcoForm_DesMoines.exe" or the like, and the user is in fact residing in that same town.
As for the malware: Lowish detection as usual, Virustotal 12/44 . Malwr/Cuckoo analysis. The malware family so far seems to have a MUTEX of "CiD0oc5m" in common, and when run, it displays a Notepad that asks the user to try again later (while the EXE installs itself in the background). Further analysis is still ongoing.
Hosts currently seen pushing the malware include
bmaschool.net Address: 61.47.47.35
bright-color.de Address: 78.46.149.229
am-software.net Address: 64.37.52.95
artes-bonae.de Address: 81.169.145.149
automartin.com Address: 46.30.212.214
almexterminatinginc.com Address: 50.63.90.1
brandschutz-poenitz.de Address: 81.169.145.160
All these sites have been on the corresponding IP addresses since years, which suggests that these are legitimate web sites that have been compromised/hacked, and are now being abused to push malware.
If you have additional info on this scam, especially if you have seen the same scam for companies besides Costco, Walmart and Bestbuy, please let us know in the comments below, or share a sample via our contact form.
VMWare ESX/ESXi Security Advisory
On Sunday, VMWare released a security advisory VMSA-2013-0016 and involves the ESX (versions 4.0 & 4.1) and ESXi (versions 4.0 through 5.5) products. A vulnerability exists within the products which could allow an unpriviledged vCenter user to arbitrarily have read or write access to files. Removing the "Add Existing Disk" permission or limiting the number of vCenter users with this priviledge can reduce the risk of exploitation until updates can be applied. More details are available at the VMWare Security Advisory page located at http://www.vmware.com/security/advisories/VMSA-2013-0016.html
--
Scott Fendley
ISC Handler
How-To's for the Holidays - Java Whitelisting using AD Group Policy
When Java 7 Update 21 came out in March ( https://isc.sans.edu/forums/diary/Java+7+Update+21+is+available+-+Watch+for+Behaviour+Changes/15620 ), there was a fair amount of discussion about Java Whitelisting. This is a valuable feature, allowing you to permit execution of specific business applications based on Java, right down to nailing down specific Java versions for each app, and deny all other Java applications (from untrusted internet sites for instance). However, making this happen in a corporate environment (which in many cases means Active Directory) is not as straightforward as you might think - folks seem to think this is just too complex to tackle, and as a result we're not seeing a lot of folks using this feature.
Let's cover this challenge from beginning to end. If you find a step that I describe that might be done better or differently, please let us know in the comment form at the bottom of this page.
The first step of course is to define the business applications require Java, so that we know what to whitelist. I'll pick administration of my home firewall - the GUI admin for Cisco ASA firewalls is a java app.
So for me, that app is https://192.168.122.1. In a real corporate setting this would generally use DNS and possibly a more complete URL. I still trip over business apps accessed by IP address, but we try to kill them off as we find them.
Optionally you can also use the hash of the public certificate for the Java app. This is a better definition for the application, as this will remain consistent if you migrate to a different host or if you place the app on a load balanced farm of servers.
Given that this is for my home firewall, I have a self-signed cert, but hashing it still works. Generally you can get the public certificate from the server (or load balancer) admins, or you can pull it off the server directly. We'll use the keytool app distributed with Java:
C:\work>"\Program Files (x86)\Java\jre7\bin\keytool.exe" -printcert -sslserver 192.168.122.1:443
Certificate #0
====================================
Owner: CN=ASA Temporary Self Signed Certificate
Issuer: CN=ASA Temporary Self Signed Certificate
Serial number: 23e1af52
Valid from: Tue Dec 17 00:29:07 EST 2013 until: Fri Dec 15 00:29:07 EST 2023
Certificate fingerprints:
MD5: 26:56:67:AB:FC:97:B7:41:45:79:99:E2:4E:32:4F:35
SHA1: 12:D5:FC:89:EF:5D:24:CE:42:4B:63:76:1E:A3:22:C7:F9:AC:87:55
SHA256: 4D:F7:47:31:BD:35:F6:99:64:3B:11:C5:EE:35:DB:FF:90:71:CB:2F:EC:
0A:35:AA:E9:5F:19:F5:87:90:11:82
Signature algorithm name: SHA1withRSA
Version: 3
We want the SHA256 hash, with the separators removed: 4DF74731BD35F699643B11C5EE35DBFF9071CB2FEC0A35AAE95F19F587901182
With that in hand, we're ready to create a ruleset.xml file to hold the rules that make up our policy. In a corporate setting you'll likely have several whitelisted apps in this file, they all go in the file. There are a few shown in this file (based on Java's example):
<!-- Based on the Example Deployment Rule Set that allow a desktop administrator to control end-user's execution of browser applets.
See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_rules.html
Firewall administration for defaultroute.ca -->
<ruleset version="1.0+">
<rule>
<id location="https://192.168.122.1" />
<certificate algorithm="SHA-256"
hash="4DF74731BD35F699643B11C5EE35DBFF9071CB2FEC0A35AAE95F19F587901182"
<action permission="run" />
</rule>
<rule>
<id location="https://someother.permittedapplication.com/program" />
<action permission="run" version="SECURE-1.6" /><!-- For example if an application is known not to work on Java 1.7 -->
</rule>
<rule>
<id location="http://localhost" />
<action permission="run" />
</rule>
<rule>
<id>
<certificate algorithm="SHA-256"
hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" /><!-- Oracle's public certificate hash. Having this will allow things like the Java.com
secure version check applet. -->
</id>
<action permission="run" />
<rule>
<id /><!-- Because this is both blank and shown last, it will be the default policy. -->
<action permission="block">
<message>Blocked by corporate. Contact myemail@mycompany.com if you need to run this app.</message>
<message locale="fr">Bloqué par l'entreprise. Contacter myemail@mycompany.com si vous avez besoin d'exécuter cette application.</message>
</action>
</rule>
</ruleset>
Full docs for this file can be found here: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_rules.html
We now take this file and package it in a JAR file using a trusted certificate. This prevents your users from editing this file after it's distributed to bypass your defined policies. You'll need the full JDK for this (jar.exe is not in the JRE distribution).
C:\work>"\Program Files\Java\jdk1.7.0_45\bin\jar.exe" -cvf deploymentruleset.jar ruleset.xml
added manifest
adding: ruleset.xml(in = 341) (out= 185)(deflated 45%)
C:\work>"\Program Files\Java\jdk1.7.0_45\bin\jarsigner.exe -verbose -keystore "c:\work\javakeystore_keepsecret.jks" -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar defaultroute-ca
Enter Passphrase for keystore:
updating: META-INF/MANIFEST.MF
adding: META-INF/COSTLOW-CA.SF
adding: META-INF/COSTLOW-CA.RSA
signing: ruleset.xml
Finally, we need to copy the final file to the corporate workstations, to specific locations:
Windows: C:\Windows\Sun\Java\Deployment
Mac, Linux, Unix: /etc/.java/deployment
In a typical organizaation, you might have 7 or 10 different rulesets to whitelist various combinations of applications. How do we get these various combinations to the desktop? Note that the location is NOT in the specific user directories. So what happens when someone governed by a different policy logs into the host?
You could copy your file in the login script, maybe using the IFMMEMBER command (from the Windows Server Resource Kit)? Something like:
ifmember Marketing then GOTO MKTLOGIN
ifmember Engineering then GOTO ENGLOGIN
....
:MKTLOGIN
xcopy \\servername\sharename\wljava.jar c:\windows\sun\java\deployment /y
However, as time goes on the lengthy and convoluted login scripts we had in the '90's are dwindling, and in many cases are now empty - people are using Group Policy for many of the things we used to get done in login scripts.
So how do we do this in AD?
========= Group Policy Method #1 =========
We'll use User Configuration \ Preferences \ Windows Settings \ Files (there's a matching setting under Computer Configuration, but that's not so applicable to User Groups).
Choose "New / File", and change the default to "Replace" - remember that there might be a file in the destination location, copied there for another user who might have different policy requirements. Update the source and destination paths.
Save it, apply it as you would any other Group Policy ,and you're done!
========= Group Policy Method #2 =========
If you've got other Group Policy functions that you need to combine with this, you can use User Configuration \ Policies \ Windows Settings \ Scripts (Logon/Logff) \ Logon. Consider this Group Policy setting to be today's version of yesterday's login scripts.
Be sure to store the script files in the Domain Policy directory:
c:\SysVol\defaultroute.ca\Policies\{Policy GUID}\Machine\Scripts\Startup, so on my server, that's in:
C:\Windows\SYSVOL\sysvol\defaultroute.ca\Policies\{CD37CDDF-8486-41DE-81A7-62F596F1BCFD}\User\Scripts\Logon
The file copy line in the script might look like:
xcopy \\%LOGONSERVER%\NETLOGON\javawl.mktg.jar c:\windows\sun\java\deploymentruleset.jar /y
If you use this second file copy approach, you'll likely want the files to reside in the NETLOGON directory so that AD replication will copy it to all DC's. The NETLOGON directory is at:
c:\windows\sysvol\sysvol\domainname\scripts, in my domain's case:
c:\windows\sysvol\sysvol\defaultroute.ca\scripts
This second method is quite a bit more complex - there's a number of file locations that need to be exactly right, and scripts that need to match them, but if you need more scripting done in your Group Policy than just copying the JAR files or other things that you can accomplish in other Group Policy settings, it's a good way to go.
======================================
Either way you copy your JAR files, Group Policies are a central place to administer almost everything - if you can bolt on generic file copies to that, and can keep everything in one place, that's a HUGE win for simplified administration!
And speaking of a "win" - once this is in place, your user community will have access to "blessed" java apps, but will not be able to execute any other java applications. Which means that when the next Java zero day is announced, you'll likely be able to sleep that night and not worry about what the next day will bring you at work!
Again, if you've got a simpler or alternative way to get this job done, I'm certainly interested and so are our readers - please use our comment form to share!
==========================
Rob VandenBrink
Metafore
Comments