In follow up to yesterday's discussion re invoking OS commands with R's system function, I wanted to show you just a bit of how straightforward it is to then use the resulting data.

After grabbing the Windows security event log with a call to Log Parser and writing it out to CSV, you have numerous options driven by what's interesting to you. Perhaps you're interested in counts per Event ID to say what your Top 10 events are. The issue is, that Log Parser just grabbed all of the security event log, which results in large, unwieldy CSV that includes large message data entries. No big deal, reduce the raw CSV to only data you need. As an example:

secevt <- read.columns("security.csv",c("EventID","TimeWritten","EventTypeName","Message"), sep=",") 

This writes the EventID, TimeWritten, EventTypeName, Message columns into a new data frame, the contents of which are stored in secevt,the other 11 columns are no longer cluttering to the in-memory data set. Want to count Event IDs? 

ct <- count(secevt$EventID)

Result snippet:

      x  freq
1  1108   734
2  4611     4
3  4616     1
4  4624   159
5  4634    49
6  4648   272
7  4656  2653
8  4658  1900
9  4662 27602

Want to sort that count decreasing by frequency?

srt <- ct[order(ct$freq, decreasing = TRUE), ]

Now to return the Top 10 specifically:

top10 <- head(srt,10)

Result snippet:

      x  freq
22 4703 81437
9  4662 27602
7  4656  2653
8  4658  1900
16 4690   931
1  1108   734
14 4688   618
15 4689   617
35 4957   400
11 4664   355

Bam, fast and flexible. My security event log has 81,437 Event ID 4703 (A user right was adjusted) entries, these parsed quickly from 118,154 total entries (147MB local file). How about visualizations of that same data? Yep, it all starts with something as simple as barplot(top10$freq,top10$x).

Hopefully you're intrigued regarding options and available capabilities here. Feel free to comment or email me if you'd like further information or resources with which to start exploring R.

Cheers.

Russ McRee | @holisticinfosec

The froxlor Server Management Panel is lightweight server management software. Your Handler on  Duty was unaware of foxlor, if diary readers are users, feel free to comment or email regarding your user experience and past security issues.

Per froxlor: 

Due to a severe security issue in the database logging system, we strongly recommend to update your current froxlor installation to 0.9.33.2. We also recommend to remove any content from the /froxlor/logs/ directory.

Download: 0.9.33.2

Note: Gentoo-ebuild and Debian packages are now available..

Visit http://www.froxlor.org or join our IRC channel #froxlor on irc.freenode.net.

Russ McRee | @holisticinfosec

I spend a lot of time using R, the programming language and software environment for statistical computing and graphics. It's incredibly useful for visualization and analysis, consider Data-Driven Security as a great starting point and reference, along with this article, if you're further interested. 

One of my recent discoveries (I'm new to R use, a terrible programmer and a worse statistician), is the use of system to invoke the OS command specified. As an example, I love Log Parser and often use it to parse or write out log events to CSV. Once in CSV they can be transformed and analyzed further in so many ways. One of the great things about R is the ability to ingest CSV and apply statical or visual methods to the data. With system, in two lines I can call Log Parser, pull the Windows security event log, write it to CSV, and create a data frame out of it that I can then do any number of other cool things with. Note: to pull the Windows security event log you need to be running with elevated privilege and need to run R as admin for this example scenario.

In short:

Set a working directory: setwd("D:/coding/R/EventVizWork")
Call Log Parser with system: system('logparser "Select * into security.csv from Security" -i:evt -o:csv')

Statistics:
-----------
Elements processed: 112155
Elements output:    112155
Execution time:     26.80 seconds

Read the results into a data frame: secevtlog <- read.csv("security.csv")

Tomorrow I'll show you what we can do with it. :-)

Russ McRee | @holisticinfosec

Introduction

In January 2015, the Asprox botnet switched from sending malware attachments to spamming pornography and diet-related scams [1].  Since then, we've noticed an increase is a different type of malicious spam (malspam).  This malspam has zip attachments containing javascript files (.js), and it uses the same type of subject lines we saw from the Asprox botnet prior to 2015 [1].

We still see malspam using zipped .js attachments.  One popular theme with this sort of malspam is fake resumes [2].  A reader sent us an example last week on Friday 2015-07-24 [3].  That example infected a computer with CryptoWall 3.0 when we checked it out in our lab environment.

We saw a different malspam campaign on Monday 2015-07-27 deliver Kovter and Miuref/Boaxxe.

The malspam

As usual, botnet-based malspam comes from a variety of sources, and it uses variations for the subject line.  There's no easy way to filter your queries when trying to retrieve this sort of malspam.  After a bit of searching on Monday 2015-07-27, we found malspam spoofing E-ZPass toll charges, FedEx delivery, and a notice to appear in court.

I gathered seven of these malspam examples.  Details follow:

Date/time: 2015-07-27 08:28 UTC
From: "E-ZPass Manager" ( maurice.mccarthy@server.neleryaptik.com )
Subject: Indebtedness for driving on toll road #00383521
Attachment name: Invoice_00383521.zip - 1,834 bytes - MD5 hash: 9225b83e28ee6bc7cd45e99e50848bc6
Extracted file: Invoice_00383521.doc.js - 11,387 bytes - MD5 hash: c4754dadf67b40e96ecf50694d90e9eb

Date/time: 2015-07-27 08:45 UTC
From: "E-ZPass Support" ( julio.miller@enggdesign.com )
Subject: Payment for driving on toll road, invoice #000460414
Attachment name: E-ZPass_Invoice_000460414.zip - 1,841 bytes - MD5 hash: 509e4f3dd518113e665423d0068f5d7e
Extracted file: E-ZPass_Invoice_000460414.doc.js - 11,709 bytes - MD5 hash: 4750ea90c5c31ab622153025e0537d60

Date/time: 2015-07-27 11:10 UTC
From: "E-ZPass Support" ( franklin.belcher@whizpress.com )
Subject: Indebtedness for driving on toll road #00000708707
Attachment name: 00000708707.zip - 1,826 bytes - MD5 hash: 25f07fc22952453665a2c1b6deb0b9d8
Extracted file: 00000708707.doc.js - 11,454 bytes - MD5 hash: 1be977c85a8c4fc9ca6b6be0e41510d7

Date/time: 2015-07-27 12:12 UTC
From: "County Court" ( seth.herring@navratanindia.com )
Subject: Notice to appear in Court #00336511
Attachment name: Notice_to_Appear_00336511.zip - 1,878 bytes - MD5 hash: 9efe9f44061259a53b32758c77ae8772
Extracted file: Notice_to_Appear_00336511.doc.js - 11,208 bytes - MD5 hash: d84a2d821108301077b681f4a93ecefc

Date/time: 2015-07-27 12:32 UTC
From: "FedEx Standard Overnight" ( eric.bowman@33d33.com )
Subject: Courier was unable to deliver the parcel, ID00888397
Attachment name: 00888397.zip - 1,803 bytes - MD5 hash: 594f788933ab6dc05ffc03f528e11c58
Extracted file: 00888397.doc.js - 11,430 bytes - MD5 hash: 2a90f4866bc98479ab5b0c44c8add551

Date/time: 2015-07-27 12:56 UTC
From: "E-ZPass Agent" ( sam.hickman@203-189-109-222.virt.lolipop.jp )
Subject: Indebtedness for driving on toll road #00118934
Attachment name: E-ZPass_Invoice_00118934.zip - 1,883 bytes - MD5 hash: d0642234e722f9d9bcd9486c1c6bbb44
Extracted file: E-ZPass_Invoice_00118934.doc.js - 11,973 bytes - MD5 hash: 6af16117fe73ca903884c3684099c695

Date/time: 2015-07-27 14:39 UTC
From: "E-ZPass Agent" ( marcus.blackburn@sg2nw8shg132.shr.prod.sin2.secureserver.net )
Subject: Indebted for driving on toll road #0000161034
Attachment name: E-ZPass_0000161034.zip - 1,798 bytes - MD5 hash: c616720fa03b0238459830466657e80c
Extracted file: E-ZPass_0000161034.doc.js - 11,064 bytes - MD5 hash: 38f27b7a6c36762d75ea858134f3d5ea

The attachment

Extract the .js file from the zip archive, and you'll find a highly obfuscated javascript.  This is merely a javascript-based file downloader.

Tools like jsdetox can deobfuscate the script for you.  However, you can easily execute the .js file on a Windows virtual machine to find URLs for the malware.  Below is a Wireshark display of traffic generated after executing all seven of the .js files found on 2015-07-27.

The IP addresses and domains hosting the follow-up malware are:

• 209.200.253.29 - avolonage.com
• 67.195.61.46 - ayuso-arch.com
• 205.144.171.10 - brigand-001-site2.smarterasp.net
• 50.116.104.205 - ihaveavoice2.com
• 205.144.171.57 - mes-sy.com
• 67.195.61.46 - mrflapper.com
• 205.144.171.28 - readysetgomatthew.com
• 174.137.191.22 - selmaryachtmarket.com
• 104.28.20.89 - www.alec.gr

The traffic

I infected a Windows host in a lab environment with one of the .js files, E-ZPass_0000161034.doc.js (MD5 hash: 38f27b7a6c36762d75ea858134f3d5ea).  This provided a full infection chain of traffic.  Three EXE files were downloaded by the .js file.  We then saw HTTP POST requests associated with Kovter malware.  Traffic also triggered an alert for Miuref/Boaxxe.  Later in the pcap, we see click-fraud activity.

Click on the above image for a full-size view.

Below are alerts for the infection traffic using Security Onion with the EmergingThreats signature set.

HTTP GET requests for the three EXE files happened first.  All were identified as images in the HTTP response headers, but they were clearly executable files.  

Below is an example of callback traffic from the Kovter malware.

Below is an example of callback traffic from Miuref/Boaxxe.

Below is a Wireshark display for some of the click-fraud traffic seen.

The malware

Below are examples of EXE files from the infected host:

• Kovter - C:\Users\username\AppData\Local\Temp\36140203.exe  -  508.1 KB ( 520,246 bytes )  -  hybrid-analysis link
• Miuref/Boaxxe - C:\Users\username\AppData\Local\Temp\50728360.exe  -  84.0 KB ( 86016 bytes )  -  hybrid-analysis link
• Third executable - not found on host  -  1.5 KB ( 1536 bytes )  -  hybrid-analysis link

A pcap of the 2015-07-27 malspam infection traffic is available at:

• http://malware-traffic-analysis.net/2015/07/27/2015-07-27-malspam-infection-traffic.pcap

A zip file of the associated malware and sanitized malspam examples is available at:

• http://malware-traffic-analysis.net/2015/07/27/2015-07-27-malspam-associated-malware.zip

The zip file is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

Final words

Malspam with zipped .js attachments has continued since I first looked into it earlier this year.  We're fairly certain this style of malspam will remain an issue.  Most spam filters keep these messages from getting to their intended recipients, but filters are never a full-proof method.  As botnets continue to send malicious content to the world's inboxes, we should always remain aware of the current threat landscape.

---
Brad Duncan
ISC Handler and Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] https://isc.sans.edu/forums/diary/What+Happened+to+You+Asprox+Botnet/19435/
[2] https://www.trustwave.com/Resources/SpiderLabs-Blog/Cryptowall-and-phishing-delivered-through-JavaScript-Attachments/
[3] https://malwr.com/analysis/ODRiNDRlNDIxYmM0NDRmZThjYWExZTI1OGY5MDJkOWU/

[Guest Diary: Xavier Mertens] [Integrating VirusTotal within ELK]

Visualisation is a key when you need to keep control of what’s happening on networks which carry daily tons of malicious files. virustotal.com is a key player in fighting malwares on a daily basis. Not only, you can submit and search for samples on their website but they also provide an API to integrate virustotal.com in your software or scripts. A few days ago, Didiers Stevens posted some SANS ISC diaries about the Integration of VirusTotal into Microsoft sysinternal tools (here, here and here). The most common API call is to query the database for a hash. If the file was already submitted by someone else and successfilly scanned, you’ll get back interesting results, the most known being the file score in the form “x/y”. The goal of my setup is to integrate virustotal.com within my ELK setup. To feed virustotal, hashes of interesting files must be computed. I’m getting interesting hashes via my Suricata IDS which inspect all the Internet traffic passing through my network.

The first step is to configure the MD5 hashes support in Suricata. The steps are described here. Suricata logs are processed by a Logstash forwarder and MD5 hashes are stored and indexed via the field ‘fileinfo.md5‘:

(Click to enlarge)

Note: It is mandatory to configure Suricata properly to extract files from network flows. Otherwise, the MD5 hashes won’t be correct. It’s like using a snaplen of ‘0’ with tcpdump. In Suricata, have a look at the inspected response body size for HTTP requests and the stream reassembly depth. This could also have an impact on performances, fine tune them to match your network behavior.

To integrate VirusTotal within ELK, a Logstash filter already exists, developed by Jason Kendall. The code is available on github.com. To install it, follow this procedure:

# cd /data/src
# git clone https://github.com/coolacid/logstash-filter-virustotal.git
# cd logstash-filter-virustotal
# gem2.0 build logstash-filter-awesome.gemspec
# cd /opt/logstash
# bin/plugin install /data/src/logstash-filter-virustotal/logstash-filter-virustotal-0.1.1.gem

Now, create a new filter which will call the plugin and restart Logstash.

filter {
    if ( [event_type] == "fileinfo" and
         [fileinfo][filename] =~ /(?i)\.(doc|pdf|zip|exe|dll|ps1|xls|ppt)/ ) {
        virustotal {
            apikey => ''
            field => '[fileinfo][md5]'
            lookup_type => 'hash'
            target => 'virustotal'
        }
    }
}

The filter above will query for the MD5 hash stored in ‘fileinfo.md5‘ to virustotal;com if the event contains file information generated by Suricata and if the filename contains an interesting extension. Of course, you can adapt the filter to your own environment and match only specific file format using ‘fileinfo.magic‘ or a minimum file size using ‘fileinfo.size‘. If conditions match a file, a query will be performed using the virustotal.com API and results stored into a new ‘virustotal‘ field:

(Click to enlarge)

Now, it’s up to you to build your ElasticSearch queries and dashboard to detect suspicious activities in your network. During the implementation, I detected that too many requests sent in parallel to virustotal.com might freeze my Logstash (mine is 1.5.1). Also, keep an eye on your API key consumption to not break your request rate or daily/monthly quota.

The CVE's for these vulnerabilities are:

CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828, CVE-2015-3829

​It should be assumed that almost all Android devices are vulnerable, so please keep an eye out for updated firmware for your device and apply the firmware as soon as available.

Update: Ugo sent a link to a blog post by Greg Bauges which describes some configuration changes which can be made on the Android device which will disable the automatic loading of MMS messages. While these changes do not stop the vulnerability from being exploited it at least makes it so the device user is aware the malicious MMS was received and run.

Update: I have been having discussions about the potential of these vulnerabilities for weaponization into a worm. Bruce Schneier has waded in with a similar idea.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

Nope, not the kind of angler whose best friends are rubber boots, strings tied into "flies", or a tape measure that starts with "5inches" where others have a zero. This is about the "Angler Exploit Kit", which currently makes rampant use of the recent Adobe Flash "zero-days" to exploit the computers of unsuspecting users, and to push Cryptowall 3.0 on to them. Fellow ISC Handler Brad has covered before how this works.

Looking though our quite exhaustive (but likely nowhere near complete) list of IP addresses that were seen hosting Angler EK over the past 30 days or so, it is obvious that the crooks behind this exploit kit have a pretty savvy operation going on. First of all, they seem to "test the waters" at a new hosting provider, probably to see how quickly they get evicted. If no or slow action is forthcoming, the same provider will likely become the "main" Angler hoster a couple of days down the road. Obviously, this is bound to create some ruckus and lead to some complaints with said provider, but by the time the provider gets around to investigating, the bad guys usually have hopped one house down the road.

Amazingly, they seem to get away with this - staying at the same provider, but just switching to another IP address. With most providers these days touting the features of their "Cloud", including the ability to "spin up your image in any of our 20 data centers around the globe within a matter of seconds", this isn't really surprising. But it sure is highly unwelcome from a malware fighting point of view.  We used to hate the "fast flux" domain name switcheroo, but now increasingly we're getting "fast instance", where the exploit hosting site itself moves every hour or two.

The statistics from this month also look like it takes the average hoster/provider about a week to "catch on" that the bad guys are simply moving onto the adjacent vacant lot, and to start evicting them for good. Though even this is hard to tell from the data - it could well also be that the providers never really caught on, and the bad guys just moved on their own to a new neighbourhood, for opsec reasons.

Without further ado, here's an excerpt from the list of Angler hosting sites that we've observed recently.

July 1	148.251.167.57		Hetzner Online AG, Germany
July 1  148.251.167.107		Hetzner Online AG, Germany
July 8  176.9.245.141		Hetzner Online AG, Germany
July 9  176.9.245.140		Hetzner Online AG, Germany
July 10 176.9.245.142		Hetzner Online AG, Germany
July 12 176.9.245.142		Hetzner Online AG, Germany
July 14	206.190.134.189		Westhost Salt Lake City, USA
July 15 185.48.58.51		Sinarohost, Netherlands
July 16 206.190.134.188		Westhost Salt Lake City, USA
July 16 206.190.134.190		Westhost Salt Lake City, USA
July 17 69.162.90.107		Limestone Networks, Dallas, USA
July 19 69.162.64.156		Limestone Networks, Dallas, USA
July 20 69.162.116.123		Limestone Networks, Dallas, USA
July 20 185.43.223.165		Wibo/Hostlife, Netherlands and Czech Republic
July 21 69.162.116.125		Limestone Networks, Dallas, USA
July 23 216.245.213.141		Limestone Networks, USA and Ntherlands	
July 23 69.162.86.36		Limestone Networks, Dallas, USA
July 23 69.162.64.158		Limestone Networks, Dallas, USA
July 24	216.245.213.138		Limestone Networks, USA and Ntherlands	
July 24 185.43.223.164		Wibo/Hostlife, Netherlands and Czech Republic
July 25 185.43.223.162		Wibo/Hostlife, Netherlands and Czech Republic

Now, of course, I'm not insinuating that this misuse occurs with the tacit or implicit approval of the providers, likely, they are just being taken for a ride, but if you are such a provider, and you receive a complaint about one of your IPs hosting Angler EK, how about:

- checking ALL your IPs, not just the one that was reported, and keep checking over the next week or two
- correlating the data used to purchase these IPs, and proactively suspend, or at least activate a full packet trace, on all others that match similar info?

Icing on the cake would be if you as the provider could spend some brain cycles to translate the awesome Emerging Threat signatures from matching on client traffic to matching on server traffic (no big deal, primarily, you just need to flip $HOME_NET and $EXTERNAL_NET, and maybe adjust the "from_server" flow direction, depending on the rule match) and then apply these onto your inbound stream. You know, 20+ days after a signature became available for the current Angler EK landing page traffic .. one would think that you, as a professional web hoster, had some way to detect such traffic into your datacenters, and that it would take you less than a week to put a lid on it?

Also, it would help a lot if all you hosters could submit ALL your intelligence on this incident to Law Enforcement. Eventually (like, 3 years down the road...), the law will catch up with the perps, and decent evidence is what makes a conviction stick. I also suspect that it would work wonders if Law Enforcement could stop by for a chat with the CEOs of the hosters who seem to be having a hard time keeping the Angler from fishing in their waters, and offer suitable assistance. Most of these hosters are in cut-throat competition, and any revenue seems to be good revenue, but a little visit from the Feds might help to put things into perspective.

With all the patching you have been doing lately I thought it would be opportune to have a look at what can and can't be done within two days.  Why two days? Well quite a few standards want you to, I guess that is one reason, but the more compelling reason is that it takes less and less time for attacks to be weaponised in the modern world.  We have over the past year or so seen vulnerabilities released and within hours vulnerable systems are being identified and in many cases exploited.  That is probably a more compelling reasons than "the standard says to". Mind you to be fair the standard typically has it in there for that reason. 

So why does patching instill such dread in many? It tends to be for a number of reasons, the main objections I come across are: 

• It might break something
• It is internal therefore we're ok AKA "we have a firewall"
• Those systems are critical and we can't reboot them
• The vendor won't let us

It might break something 

Yes it could, absolutely. Most vendors have pushed patched that despite their efforts to test prior to deployment will actually break something. However in reality the occurrences are low and where possible you should have pushed it to test systems prior to production implementation anyway, so ...

It is internal therefore we're ok AKA "we have a firewall"

This has to be one of my favourites.  Many of us have M&M environments, hard on the outside and nice gooey soft on the inside. Which is exactly what attackers are looking for, it is one of the reasons why Phishing is so popular. You get your malware executed by someone on the inside. To me this is not really a reason.  I will let you use this reason to prioritise patching, sure, but that is assuming you then go patch your internet facing or other critical devices first.

Those systems are critical and we can't reboot them

Er, ok. granted you all have systems that are critical to the organisation, but if standard management functions cannot be performed on the system, then that in itself should probably have been raised as a massive risk to the organisation.  There are plenty of denial of service vulnerabilities that will cause a reboot. If an internet facing system can't be rebooted I suspect you might want to take a look at that on Monday. For internal systems, maybe it is time to segment them as much of the normal network as you possibly can to reduce the risk to those systems. 

The vendor won't let us

Now it is easy for me to say get a different vendor, but that doesn't really help you much.  I find that when you discuss exactly what you can or can't change the vendor will often be quite accommodating. In fact most of the time they may not even be able to articulate why you can't patch. I've had vendors state you couldn't patch the operating system, when all of their application was Java. Reliant on Java, sure, reliant on a Windows patch for IE, not so much.  Depending on how important you are to them they may come to the party and start doing things sensibly.  
If you still get no joy, then maybe it is time to move the system to a more secure network segment and limit the interaction between it and the rest of the environment, allowing work to continue, but reduce the attack platform.  

So the two days, achievable?

Tricky but yes.  You will need to have all your ducks lined up and have the right tools and processes in place. 

Lets have a look at the process first.  Generally speaking the process will be pretty much the same for all of you.  A high level process is below, I suspect it is familiar to most of you. 

Evaluate the patch. 

There are a number of different approaches that organisations take. Some organisations will just accept the vendor recommendation. If the vendor states the patch is critical then it gets applied, no questions asked. Well one, do we have the product/OS that needs to be patched? Yes, then patch. 

Other organisations take a more granular approach, they may not be quite as flexible in applying all patches as they are released, or possibly rebooting systems is a challenge (we have all come across systems that when rebooted have a hard time coming back).  In those organisations the patch needs to be evaluated.  In those situations I like using the CVSS scores and apply any modifiers that are relevant to the site to get a more accurate picture of the risk to my environment (https://nvd.nist.gov/cvss.cfm).  If you go down this path make sure you have some criteria in place for considering things critical.  For example if your process states a CVSs score of 10 is critical. Scores of 9.9 or lower are High, medium low etc. I’d probably be querying the thoughts behind that.  Pick what works for you, but keep in mind most auditors/reviewer will question the choice and you will need to be able to defend it.

Many patches address a number of CVEs. I generally pick the highest scoring one and evaluate it. If it drops below the critical score we have specified, but is close. I may evaluate a second one, but if the score remains in the critical range I won’t evaluate the rest of the CVEs. It is not like you can apply a patch that addresses multiple CVEs for only one. 

Prioritise

You already know which servers, workstations and devices are critical to the organisation, if not that might be a good task for Monday, junior can probably do most of this.  Based on the patch you will know what it patches and most vendors provide some information on the attack vector and the expected impact.  Use this information to identify which types of servers/workstations/devices in your organisation should be at the top of the patching list. Are they internet facing machines? machines running a particular piece of software?

You might want to check our site as well.  On patch Tuesday we publish patching information and break it down into server and client patches as well as priorities (PATCH NOW means exactly that). Based on these answers you may be able to reduce the scope of your patching and therefore make the 48 hours more achievable. 

Deploy to Dev/Test environment

Once the patches are know, at least those that must be applied within the 48 hours, push them to your Dev/Test servers/workstations, assuming you have them. If you do not you might need to designate some machines and devices, non-critical of course, as your test machines.  Deploy the patches as soon as you can, monitor for odd behaviour and have people test.  Some organisations have scripted the testing and OPS teams can run these to ensure systems are still working. Others not quite that automated may need to have some assistance from the business to validate the patches did’t break anything.   

Deploy to UAT/Staging/Pilot

Once the tests have been completed the patches can be pushed out to the next stage a UAT or staging environment. If you do not have this and you likely won’t have these for all your systems, maybe set up a pilot group that is representative of the servers/devices you have in the environment. In the case of workstations pick those that are representative of the various different user groups in the organisation. Again test that things are still functioning as they should. These test should be standardised where possible, quick and easy to execute and verify. Once confirmed working the production roll out can be scheduled. 

Deploy to Production

Schedule the non critical servers that need patching first, just in case, but by now the patches have been applied to a number of machines, passed at least two sets of tests and prior to deployment to production you quickly checked the isc.sans.edu dairy entry to see if people have experienced issues. Our readers are pretty quick in identifying potential issues (make sure you submit a comment if you come across one). Ready to go.

Assuming that you have the information in place and the processes and have the resources to patch, you should be able to patch dev/test within the first 4 hours after receiving the patch information. Evaluating the information should not take long.  Close to lunch time UAT/staging/Pilot groups can be patched (assuming testing is fine).  Leave them overnight perhaps.  Once confirmed there are no issues start patching production and schedule the reboots if needed for that evening.  

Patched within 2 days, dreaming? nope, possible, tough, but possible.  

For those of you that have patching solutions in place your risk level and effort needed is probably lower than others.  By the time the patch has been released to you it has been packaged and some rudimentary testing has already been done by the vendor. The errors that blow up systems will likely already have been caught.  For those of you that do not have patching solutions have a good look at what WSUS can do for you.  With the third party add on it can also be used to patch third party products (http://wsuspackagepublisher.codeplex.com/)  You may have to do some additional work to package it up which may slow you down, but it shouldn’t be to much.

It is always good to improve so if you have some hints, tips good practices, horrible disasters that you can share so others can avoid them, leave a comment. 

Happy patching we'll be doing more over the next few weeks.

Mark H - Shearwater

For those of us that are in patching world the last few weeks has not been fun.  It seemed like there was a new critical issue almost every other day and almost certainly just after you finished the previous round of patching. I guess that is what happens when a hacking firm is breached. 

Well unfortunately I'm here to add to your woes.  BK wrote in (thanks) to remind me that on the same day that Microsoft patched a critical issue, ZDI released four vulnerabilities that, whilst based on their CVSS score may not quite reach critical (in Microsoft world), will likely result in a patch for most systems (including Windows phone).  

• http://www.zerodayinitiative.com/advisories/ZDI-15-359/
• http://www.zerodayinitiative.com/advisories/ZDI-15-360/
• http://www.zerodayinitiative.com/advisories/ZDI-15-361/
• http://www.zerodayinitiative.com/advisories/ZDI-15-362/

In this case all four were discovered in-house, disclosed to the vendor over 120 days ago and as of release unlikely to have an exploit associated with it. That is however likely to change. 

Mark H

Introduction

Earlier this year, we started seeing reports of macro-based Bartalex malware [1].  Bartalex has been used in Microsoft Office documents sent through malicious spam (malspam).  On Tuesday 2015-07-21, we found a sample to examine for today's diary.  We used this example of Bartalex to infect a Windows host with Pony malware that downloaded a Dyre banking Trojan [2].

Example of the malspam

This malspam sample has ADP as a spoofed sender.  The message discusses a rejected ACH payment.

The email headers show this email didn't actually come from ADP.

There's nothing particularly revealing about the attached Word document, at least as far as its metadata.

The malicious attachment

A sample of the Bartalex Word document is available here.  Before opening the Word document on a test host, we reviewed it with OfficeMalScanner.  Using OfficeMalScanner's "info" mode, we extracted macros from rejected_ach_batch.doc.

OfficeMalScanner generated some text files, and we could examine the macro code.  The largest file contained the most useful information.

There's a bit of obfuscation, but we found some URLs used by the malware.  Examples are highlighted below.

Opening the Word document will execute the associated macro(s) if they are enabled.  Here's what the document looks like when it's first opened:

Traffic generated by the malware

We opened the Word document on a virtual machine (VM) and enabled macros.  Unfortunately, the VM had only one processor core.  Why is that unfortunate, you ask?  Earlier this year, Dyre began checking if a machine has only one processor core.  On a single-core VM, Dyre will terminate itself before doing anything [3], which is what happened on this VM.  Below is an image of the traffic filtered in Wireshark.  It shows the infection chain of events, which stopped after Dyre was downloaded to (and executed on) the VM.

Click on the image above for a full-size view.

Doing the same thing on a dual-core host generated additional post-infection traffic.  Below is an image of Wireshark from the dual-core host.  On this host, post-infection traffic shows patterns associated with Dyre.

​
Click on the image above for a full-size view.

We reviewed some of the Dyre post-infection traffic in Wireshark.  The image below shows one of the TCP streams using SSL over port 4443.  In Wireshark's "Analyze" menu, use "Decode As" and select SSL to see the information properly parsed.  We found certificate data typically seen in SSL traffic generated by Dyre.

After reviewing the initial infection traffic using Security Onion with the EmergingThreats signature set, we found a number of events related to Bartalex malware and the Pony downloader.

Traffic from a host infected by the Dyre sample generated events related to Dyre.

Final words

Below are links for two EXE files found on the infected host.  The hybrid-analysis pages contain links to download the malware samples:

• C:\Users\username\AppData\Local\Temp\8.exe - 263.0 KB ( 269,312 bytes ) - hybrid-analysis.com link
• C:\Users\username\AppData\Local\Temp\165173.exe - 541.5 KB ( 554,496 bytes ) - hybrid-analysis.com link

Bartalex malspam continues to be a concern.  In some cases, these attachments may slip through spam filters before anti-virus programs can detect them.  Fortunately, post-infection traffic should trigger network alerts.  If your organization has adequate network security monitoring, you can detect any users that fall for this malspam.

---
Brad Duncan
ISC Handler and Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] http://blog.trendmicro.com/trendlabs-security-intelligence/enterprises-hit-by-bartalex-macro-malware-in-recent-spam-outbreak/
[2] http://www.zdnet.com/article/dyre-wolf-attacks-your-corporate-bank-account-door/
[3] http://www.seculert.com/blog/2015/04/new-dyre-version-evades-sandboxes.html

Now that my overview of Sysinternals tools with VirusTotal support is complete (Process Explorer, Autoruns and Sigcheck), let's address a couple of remarks I received (BTW, if I missed a Sysinternals tools, let me know with a comment).

1) Upload of files. Some people are worried that the Sysinternals tools will upload (confidential) files to VirusTotal. That is a valid concern, but for each tool I described, I showed how to enable hash searching first. Configured like this, the Sysinternals tools will only submit hashes to VirusTotal, and not upload files. The Sysinternals tools can upload files, but this has to be done manually (Process Explorer) or configured explicitly (Autoruns and Sigcheck).

2) Internet access. It is obvious that these tools require Internet access to connect to VirusTotal (BTW, if you have a proxy, read the comments for Process Explorer). But that is not always possible or desirable. Several years ago, I needed a tool to search through the VirusTotal database for a list of MD5 hashes. At that time, I found no programs or scripts that searched the VirusTotal database via the API (though there were scripts to submit files, but not search). Thus I wrote my own tool: virustotal-search.py. You need to obtain a VirusTotal API key to use with virustotal-search.py (create a free VirusTotal account and you'll get one). And then you let virustotal-search.py run with a list of search terms (MD5, SHA1 or SHA256 hashes) and it will produce a CSV file with the results. This will take some time, as virustotal-search.py respects VirusTotal's quota for free accounts: 4 requests per minute and maximum 4 search terms per request. I won't go into al the features of virustotal-search, if you are interested, visit my virustotal-search page. Here is an example of a CSV file produced by virustotal-search.py:

In an upcoming diary entry, I'll give some pointers to produce lists of hashes (tip: some Sysinternals tools can calculate hashes).

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Microsoft just released a special "out fo band" security bulletin with a patch for a remote code execution vulnerability in Windows' OpenType font drivers. The update replaces a patch released last week (MS15-077). Microsoft rates the vulnerability critical for all currently supported versions of Windows. Microsoft says in it's bulletin, that it had information that the vulnerability was public, but had no indication that it was actively exploited. MS15-077 had been exploited at the time the MS15-077 bulletin was released last week. As a workaround, users may remove the font driver, but this may cause applications that rely on it to not be able to display certain fonts.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Continuing my diary entries on Sysinternals tools with VirusTotal support, I'm taking a look at sigcheck.

Sigcheck is a command-line utility to check the digital signature of files like PE files (EXEs).

Sigcheck also supports VirusTotal searches. When you use option -v, the hash of the file will be submitted to VirusTotal. The first time you run it, you'll have to accept VirusTotal's terms (or use option -vt to accept and avoid the prompt):

You'll get the score and a link to the report for the checked file.

If a hash is not present in VirusTotal's database, the file will not be submitted, unless you use option -vs:

You can scan a complete disk with option -s and specifying the root folder of the disk (e.g. c:\), and you can produce a CSV report with option -c:

As can be seen from this last screenshot, files without digital signature are also checked with VirusTotal.

Sysinternals: http://technet.microsoft.com/en-us/sysinternals

VirusTotal: https://www.virustotal.com/

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Continuing my diary entries on Sysinternals tools with VirusTotal support, I'm taking a look at autoruns.

Autoruns is another fine Sysinternals tool that comes with VirusTotal integration. If you are not familiar with autoruns, it scans all auto-starting locations in Windows and provides a comprehensive report. This gives you an overview of all programs that start automatically on the scanned Windows machine.

When you start autoruns it will start scanning the Windows machine. Wait for the scan to terminate, or abort it with the Escape key.

Go to the scan options:

And enable "Check VirusTotal.com":

With this option, autoruns will only submit hashes to VirusTotal. If a file is not known by VirusTotal, you won't have a score. But if you enable "Submit Unknown Images" too, then autoruns will submit (upload) files that are not in VirusTotal's database, and you will have a score after VirusTotal finishes scanning the file (this takes a couple of minutes).

You have to agree to VirusTotal's terms of use to enable this feature:

Hashes will be submitted:

And soon you'll have the VirusTotal scores for known entries:

Sysinternals: http://technet.microsoft.com/en-us/sysinternals

VirusTotal: https://www.virustotal.com/

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

About a year ago, Rob had a diary entry about checking a file from Process Explorer with VirusTotal.

Did you know you can have all EXEs of running processes scanned with VirusTotal?

In Process Explorer, add column VirusTotal:

Enable VirusTotal checks:

And accept the VirusTotal terms:

(update: as you can see, by default Process Explorer only submits hashes to VirusTotal, not files, unless you explicitly instruct it to submit a file).

And now you can see the VirusTotal scores:

Process Explorer is not the only Sysinternals tool that comes with VirusTotal support. I'll showcase more tools in upcoming diary entries.

Sysinternals: http://technet.microsoft.com/en-us/sysinternals

VirusTotal: https://www.virustotal.com/

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Introduction

Adobe has received some bad publicity regarding zero-day Flash player exploits due to the recent Hacking Team compromise [1,2].  This certainly isn't the first time Adobe has had such issues [3].  With HTML5 video as an alternative to Flash player, one might wonder how long Flash player will be relevant.  Google has announced the next stable version of Chrome will block auto-playing Flash elements [4], and Firefox started blocklisting Flash player plugins earlier this week [5].  With people like Facebook's chief security officer calling for Adobe to announce an end-of-life date for Flash [6], I've been wondering about the future of Flash player.

More specifically, I've been wondering what exploit kit (EK) authors will turn to, once Flash player is no longer relevant.

In recent months, most EK traffic I've generated used a Flash exploit to infect vulnerable Windows hosts.  The situation with Flash player today is much like the situation with the Java that I remember back in 2013 and most of 2014.  However, in the fall of 2014, most EKs dropped Java exploits from their arsenal and started relying on Flash player as a vehicle for their most up-to-date exploits.

A recent history Java exploits in EK traffic 

Java exploits were prevelant when I first started blogging about EK traffic in 2013 [7].  Back then, Blackhole EK was still a player, and I commonly saw Java exploits in EK traffic.

The threat landscape altered a bit when the EK's alleged creator "Paunch" was arrested.  Organizations that monitor EK traffic noticed a sharp reduction of Blackhole EK traffic in 2014 compared to the previous year [8].  During that same time, I started noticing more Flash exploits in EK traffic.  By September 2014 most of the remaining EKs stopped using Java.

My last documented dates for Java exploits in exploit kit traffic are below (read: exploit kit name - date Java exploit last seen).

• Angler EK - 2014-09-16 [9]
• FlashPack EK - 2014-08-30 [10]
• Nuclear EK - 2014-09-08 [11]
• Magnitude EK - 2014-08-15 [12]
• Sweet Orange EK - 2014-09-25 [13]
• Rig EK - 2014-09-06 [14]

Of note, FlashPack EK and Sweet Orange EK have disappeared, and they are not currently a concern.  Neutrino EK was dormant from April through October of 2014, and when it came back, I didn't see it using any Java exploits.

Fiesta EK still sends several different types of exploits depending on the vulnerable client, and it still has Java exploits in its arsenal.  Other lesser-seen EKs like KaiXin still use Java exploits.  However, the majority of EKs gave up on Java sometime last year.

What we're recently seeing with Flash exploits

Most exploit kits use the latest available Flash exploits.  Angler, Neutrino, Nuclear, Magnitude, and Rig EK are all using the latest Hacking Team Flash player exploit based on CVE-2015-5122 [15].  If you have Flash player on a Windows computer, you should be running the most recent Flash update (version 18.0.0.209 as I'm writing this).

Earlier I generated Angler EK traffic to infect a Windows host running Flash player 18.0.0.203 on IE 11.  Angler sent a Flash exploit based on CVE-2015-5122, and the EK sent CryptoWall 3.0 as the malware payload.

Shown above: An image of the Angler EK infection and post-infection CryptoWall 3.0 traffic in Wireshark.  Click on the image for a full-size view.

Shown above: Angler EK sending a Flash exploit, based on CVE-2015-5122, targeting Flash 18.0.0.203.

The infected host's bitcoin address for ransom payment was 1LY58fiaAYFKgev67TN1UJtRveJh81D2dU.  The address is the same one seen on 2015-07-01 and also documented in my previous diary on CryptoWall 3.0 [16].

Shown above: Decrypt instructions from the infected host.

Final words

Today, the majority of EKs utilize Flash player exploits based on the most recently known vulnerabilities.  But this situation can't last forever.  If Flash is no longer relevant, what will EK authors turn to for their latest exploits?  Will they go back to Java?  Will they focus on browser vulnerabilities?  It will be interesting to see where things stand in the next year or so.

A pcap of the 2015-07-15 Angler EK infection traffic is available at:

• http://malware-traffic-analysis.net/2015/07/15/2015-07-15-Angler-EK-traffic-for-ISC-diary.pcap

A zip file of the associated malware is available at:

• http://malware-traffic-analysis.net/2015/07/15/2015-07-15-Angler-EK-and-CryptoWall-3.0-malware-for-ISC-diary.zip

The zip file is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

---
Brad Duncan
ISC Handler and Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] https://krebsonsecurity.com/2015/07/adobe-to-patch-hacking-teams-flash-zero-day/
[2] http://www.pcworld.com/article/2947312/second-flash-player-zeroday-exploit-found-in-hacking-teams-data.html
[3] http://krebsonsecurity.com/2015/02/yet-another-flash-patch-fixes-zero-day-flaw/
[4] http://arstechnica.co.uk/information-technology/2015/06/google-chrome-will-soon-intelligently-block-auto-playing-flash-ads/
[5] http://arstechnica.com/security/2015/07/firefox-blocklists-flash-player-due-to-unpatched-0-day-vulnerabilities/
[6] https://twitter.com/alexstamos/status/620306643360706561
[7] http://malware-traffic-analysis.net/2013/06/18/index.html
[8] http://www.symantec.com/connect/blogs/six-months-after-blackhole-passing-exploit-kit-torch
[9] http://malware-traffic-analysis.net/2014/09/16/index2.html
[10] http://malware-traffic-analysis.net/2014/08/30/index.html
[11] http://malware-traffic-analysis.net/2014/09/08/index2.html
[12] http://malware-traffic-analysis.net/2014/08/15/index.html
[13] http://malware-traffic-analysis.net/2014/09/25/index.html 
[14] http://malware-traffic-analysis.net/2014/09/06/index.html
[15] http://malware.dontneedcoffee.com/2015/07/cve-2015-5122-hackingteam-0d-two-flash.html
[16] https://isc.sans.edu/forums/diary/Another+example+of+Angler+exploit+kit+pushing+CryptoWall+30/19863/

Most of us have a cheat sheet [CS] here and there. In my jump bag there is a 3 ring binder with cheat sheets in plastic sheet protectors. In this, it got me thinking about cheat sheets again and there are a few things to share. First, we have wrote about them many times over the years (located with site:isc.sans.edu Cheat Sheets) [1] [2] [3] [4] [5]. There are also a series of cheat sheets all over the ‘intertubes’ [6] [7] [8] and lets not forget the great list of CS at Packet Life [9]. There are even GIT repositories of CS [10].

Note: From here On, I am talking about an Apple OS X only App. If someone wants to contribute something similar for Linux and Windows email me ( rporter at isc dot sans dot edu ) or twitter @packetalien and I will post an update.

One common thing that has been bothering me as of late is ‘search-ability’ and ease of getting to quick answers in a cheat sheet. Then I thought about possible solutions and wanted to share.

For other coding references there is Dash [11] which I use heavily and they have tons of cheat sheets [12]. While sitting in a SANS 572 Advanced Network Forensics, it hit me, write a Packet Forensics CS, to the Dash Docs Batman.

As it turns out, the format is easy to understand and based in Ruby [12] and there is a Ruby gem called Cheatset [13] that has great samples.

Here is a screenshot of what I’ve got so far, and this cheat sheet will be for packet "forensicators":

There will be more to come as time permits and if anyone is interested in the source or docset for this and or would like to contribute email me ( rporter at isc dot sans dot edu ) or twitter @packetalien.

A final note, when doing forensics on a case, it is always good to have references handy!

[1] https://isc.sans.edu/diary/2+Cheat+Sheets+for+Incident+Handling/5354

[2] https://isc.sans.edu/diary/Cheat+Sheet%3A+Analyzing+Malicious+Documents/7705

[3] https://isc.sans.edu/diary/New+and+updated+cheat+sheets/6958

[4] https://isc.sans.edu/diary/New+Incident+Response+Methodology+Cheat+Sheet/10828

[5] https://isc.sans.edu/diary/OWASP+Session+Management+%22Cheat+Sheet%22/11263

[6] https://isc.sans.edu/presentations/

[7] https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

[8] https://cert.societegenerale.com/en/publications.html

[9] http://packetlife.net/library/cheat-sheets/

[10] https://github.com/detailyang/cheat-sheets

[11] https://kapeli.com/dash

[12] https://github.com/Kapeli/cheatsheets

[13] https://github.com/Kapeli/cheatset

Richard Porter

@packetalien, packetalien.com, rporter at isc dot sans dot edu

--- ISC Handler on Duty

Overview of the July 2015 Microsoft patches and their status.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

In a warm up to patch Tuesday, it looks like we have a new version for Adobe Flash Player, Shockwave Player and PDF Reader. Given that some of the exploits against the vulnerabilities patched are public, you may want to expedite patching and review your Flash Player and browser configuration.

the latest (patched) versions are (thanks Dave!):

- Flash Player 18.0.0.209
- Flash Player EST 13.0.0.305
- Reader 10.1.15
- Reader 11.0.12
- Shockwave Player 12.1.9.159

Bulletins:

https://helpx.adobe.com/security/products/shockwave/apsb15-17.html
https://helpx.adobe.com/security/products/flash-player/apsb15-18.html
https://helpx.adobe.com/security/products/reader/apsb15-15.html

You can get the latest version here: https://get.adobe.com/flashplayer/ 

Also note that many browsers now allow you to disable Flash by default. You can re-enable it for sites that require Flash. Here is a nice page that will explain how to have your browser ask for permission before running plugins:

http://www.howtogeek.com/188059/how-to-enable-click-to-play-plugins-in-every-web-browser/

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Jump List files are another type of files that are actually OLE files. They can contain useful data for forensic investigations. There are a couple of tools that can extract information from these files.

Here you can see oledump analyzing an automatic Jump List file:

The stream DestList contains the Jump List data:

There are several sites on the Internet explaining the format of this data, like this one. I used this information to code a plugin for Jump List files:

The plugin takes an option (-f) to condense the information to filenames:

Please post a comment if you have another Jump List tool to share.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

PHP 5.6.11, 5.5.27 and 5.4.43 were updated fixing numerous bugs in the various components of PHP including CVE-2015-3152. PHP recommend testing and upgrading to the current release. The binaries and packages are available here and the release notes here.

[1] http://www.php.net/ChangeLog-5.php
[2] http://windows.php.net/download/

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Look, up in the URL.  Its a BASE64, its a URI.  This looks like a job for freq.py

This diary is a follow up to yesterdays post on using freq.py to find DGA (Domain Generation Algorithm) host names in your logs using frequency tables.  If you didn't see that post you should review it first before continuing.   You can find that diary here:  https://isc.sans.edu/forums/diary/Detecting+Random+Finding+Algorithmically+chosen+DNS+names+DGA/19893/

Fellow SANS Instructor/GSE Kevin Fiscus suggested another use for the tool to me last week when I showed him what I had been working on.   Kevin pointed out that it is difficult to find BASE64 encoded strings programmatically.   Because BASE64 uses uppercase letters, lowercase letters, numbers, slashes and plus signs a program has a hard time telling the difference between a BASE64 encoded string and a URI (The part of the URL after the domain name).  Consider these two strings found that you might find embedded in a suspicious document:

String 1: Q09NRSBUTyBNWSBQWVRIT04gQ0xBU1MgSU4gVkVHQVMhISEh
String 2: forums/diary/Detecting+Random+Finding+Algorithmically+chosen+DNS+names+DGA/19893

Both of these are properly formatted BASE64 encoded strings.  But only one of them is intentionally a BASE64 encoded string and only one of them will decode to something other than garbage random data.   Our frequency table will work nicely to determine the difference between the BASE64 strings and the URI.   This time a high probability (above 5) indicates that it is NOT BASE64 encoded and a LOW probability (below 5) indicates that it is BASE64 encoded.  You can do this from either the command line with "python freq --measure 'suspect base 64 string' frequency_table.freq" or freq.exe on Windows using the tools available for download here.   But we used the command line yesterday and I want to show you another way to use the Python script.  This time lets import freq.py as a Python module.  First I start up my Python interactive mode session.  Then I import the freq module.  Note: What I type is in RED.  The computers output is in black.

student@python-vm:~/freq$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:38)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from freq import *

Next I will assign the variable fc to hold a frequency counter object, then load my prebuilt "english_lowercase.freq" frequency table from the current working directory.

>>> fc = FreqCounter()
>>> fc.load("english_lowercase.freq")

Next I use the .probability() method to measure the probability of the two strings.  First string2 then string1.
>>> fc.probability('forums/diary/Detecting+Random+Finding+Algorithmically+chosen+DNS+names+DGA/19893')
9.490788394012279
>>> fc.probability('Q09NRSBUTyBNWSBQWVRIT04gQ0xBU1MgSU4gVkVHQVMhISEh')
2.578357325221811

The URI scores well above 5 indicating that it is not random text and in this case not BASE64.  But the 2nd string scores a 2.5 indicating that it more likely to be a BASE64 encoded string.   Once again this isn't perfect.  You could still have URI with random ASCII strings in then that score low, but it does help to differentiate between common URI strings and BASE64 encoded strings.  This is confirmed when we try to BASE64 decode each of hte strings.  The URI decodes to junk and the other string decodes to pure gold!
>>>'forums/diary/Detecting+Random+Finding+Algorithmically+chosen+DNS+names+DGA/19893'.decode("BASE64")
'~\x8a\xee\x9a\xcf\xdd\x89\xaa\xf2\xfc7\xady\xcbb\x9e\x0f\x91jwh\x9b\xe1b\x9d\xd8\xa7\x83\xe0%\x82\x8a\xe2\xb6\x19\xa2q\xa9e\xcb\xe7!\xa2\xc7\xa7\xf83R\xfav\xa6z\xcf\x83\x18\x0f\xf5\xf7\xcfw'
>>>'Q09NRSBUTyBNWSBQWVRIT04gQ0xBU1MgSU4gVkVHQVMhISEh'.decode("BASE64")
'COME TO MY PYTHON CLASS IN VEGAS!!!!'

Follow me on twitter @MarkBaggett

Want to learn to use this code in your own script or build tools of your own?  Join me for Python SEC573 in Las Vegas this September 14th!  Click here for more information.

VMware has issued a security bulletin regarding a privilege escalation attack affecting VMware 10 and 11, Player 6,7 and VMware Horizon Client for Windows prior to version 5.4.2

http://www.vmware.com/security/advisories/VMSA-2015-0005.html

Summary
VMware Workstation, Player and Horizon View Client for Windows updates address a host privilege escalation vulnerability.
2. Relevant Releases
VMware Workstation for Windows 11.x prior to version 11.1.1
VMware Workstation for Windows 10.x prior to version 10.0.7
VMware Player for Windows 7.x prior to version 7.1.1
VMware Player for Windows 6.x prior to version 6.0.7
VMware Horizon Client for Windows (with Local Mode Option) prior to version 5.4.2
3. Problem Description
a. VMware Workstation, Player and Horizon View Client for Windows host privilege escalation vulnerability.

VMware Workstation, Player and Horizon View Client for Windows do not set a discretionary access control list (DACL) for one of their processes. This may allow a local attacker to elevate their privileges and execute code in the security context of the affected process.

VMware would like to thank Kyriakos Economou of Nettitude for reporting this issue to us.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the identifier CVE-2015-3650 to this issue.

Full details are available here:

http://www.vmware.com/security/advisories/VMSA-2015-0005.html

Twitter:@markbaggett

OpenSSL 1.0.2.d and 1.0.1p were release fixing an issue with the Certification verification process.   The security advisory for the issue can be found here: https://www.openssl.org/news/secadv_20150709.txt

OpenSSL Security Advisory [9 Jul 2015]
=======================================

Alternative chains certificate forgery (CVE-2015-1793)
======================================================

Severity: High

During certificate verification, OpenSSL (starting from version 1.0.1n and
1.0.2b) will attempt to find an alternative certificate chain if the first
attempt to build such a chain fails. An error in the implementation of this
logic can mean that an attacker could cause certain checks on untrusted
certificates to be bypassed, such as the CA flag, enabling them to use a valid
leaf certificate to act as a CA and "issue" an invalid certificate.

This issue will impact any application that verifies certificates including
SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David
Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project.

Note
====

As per our previous announcements and our Release Strategy
(https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions
1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these
releases will be provided after that date. Users of these releases are advised
to upgrade.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv_20150709.txt

Note: the online version of the advisory may be updated with additional
details over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/about/secpolicy.html

Patch your firewalls!

2015-July-08 UPDATE: Cisco PSIRT is aware of disruption to some Cisco customers with Cisco ASA devices affected by CVE-2014-3383, the Cisco ASA VPN Denial of Service Vulnerability that was disclosed in this Security Advisory. Traffic causing the disruption was isolated to a specific source IPv4 address. Cisco has engaged the provider and owner of that device and determined that the traffic was sent with no malicious intent. Cisco strongly recommends that customers upgrade to a fixed Cisco ASA software release to remediate this issue. 

Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available.

This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141008-asa

​

Follow me on twitter @MarkBaggett

Join me for Python SEC573 in Las Vegas this September 14th!  Click here for more information.

Most normal user traffic communicates via a hostname and not an IP address.   So looking at traffic communicating directly by IP with no associated DNS request is a good thing do to.   Some attackers use DNS names for their communications.   There is also malware such as Skybot and the Styx exploit kit that use algorithmically chosen host name rather than IP addresses for their command and control channels.  This malware uses what has been called DGA or Domain Generation Algorithms to create random looking host names for it's TLS command and control channel or to digitally sign it's SSL certificates.   These do not look like normal host names.   A human being can easily pick them out of our logs and traffic, but it turns out to be a somewhat challenging thing to do in an automated process.  "Natural Language Processing" or measuring the randomness don't seem to work very well.  Here is a video that illustrates the problem and one possible approach to solving it.

One way you might try to solve this is with a tool called ent.   "ent" a great Linux tool for detecting entropy in files.  Consider this:

[~]$ head -c 10000000 /dev/urandom | ent

Entropy = 7.999982 bits per byte.       <--  8 = random

[~]$ python -c "print 'A'*1000000" | ent
Entropy = 0.000021 bits per byte.             <--  0 = not random

So 8 is highly random and 0 is not random at all.  Now lets look at some host names.

[~]$ echo "google" | ent
Entropy = 2.235926 bits per byte.
[~]$ echo "clearing-house" | ent
Entropy = 3.773557 bits per byte.       <-  Valid hosts are in the 2 to 4 range

Google scores 2.23 and clearing-house scores 3.7.  So it appears as though legitimate host names will be in the 2 to 4 range.   Now lets try some host names that we know are associated with malware that uses random host names.

[~]$ echo "e6nbbzucq2zrhzqzf" | ent
Entropy = 3.503258 bits per byte.
[~]$ echo "sdfe3454hhdf" | ent
Entropy = 3.085055 bits per byte.      <- Malicious host from Skybot and Styx malware are in the same range as valid hosts

That's no good.  Known malicious host names are also in the 2 to 4 range.  They score just about the same as normal host names.  We need a different approach to this problem. 

Normal readable English has some pairs of characters that appear more frequently than others. "TH", "QU" and "ER" appear very frequently but other pairs like "WZ" appear very rarely.   Specifically, there is approximately a 40% chance that a T will be followed by an H.  There is approximately a 97% change that a Q will be followed by the letter U.  There is approximately a 19% chance that E is followed by R.   With regard to unlikely pairs, there is approximately a 0.004% chance that W will be followed by a Z.   So here is the idea, lets analyze a bunch of text and figure out what normal looks like.  Then measure the host names against the tables.   I'm making this script and a Windows executable version of this tool available to you to try it out.  Let me know how it works.    Here is a look at how to use the tool.

Step 1) You need a frequency table.  I shared two of them in my github if you want to use them you can download them and skip to step 2.

1a)  Create the table:  I'm creating a table called custom.freq.  Create a table with the --create option

C:\freq>freq.exe --create custom.freq

1b)  You can optionally turn ON case sensitivity if you want the frequency table to count uppercase letters and lowercase letters separately.  Without this option the tool will convert everything to lowercase before counting character pairs.  Toggle case sensitivity with -t or --toggle_case_sensitivity

C:\freq>freq.exe -t custom.freq

1c) Next fill the frequency table with normal text.  You might load it with known legitimate host names like the Alexa top 1 million most commonly accessed websites. (http://s3.amazonaws.com/alexa-static/top-1m.csv.zip)  I will just load it up with famous works of literature. The --normalfile argument is used to load the table with a text file containing normal text.

C:\freq>for %i in (txtdocs\*.*) do freq.exe --normalfile %i custom.freq
C:\freq>freq.exe --normalfile txtdocs\center_earth custom.freq
C:\freq>freq.exe --normalfile txtdocs\defoe-robinson-103.txt custom.freq
C:\freq>freq.exe --normalfile txtdocs\dracula.txt custom.freq
C:\freq>freq.exe --normalfile txtdocs\freck10.txt custom.freq
C:\freq>freq.exe --normalfile txtdocs\invisman.txt custom.freq

Step 2) Measure badness!

Once the frequency table is filled with data you can start to measure strings to see how probable they are according to our frequency tables.  The --measure option is used for this purpose.

C:\freq>freq.exe --measure "google" custom.freq
6.59612840648
C:\freq>freq.exe --measure "clearing-house" custom.freq
12.1836883765

So normal host names have a probability above 5 (at least these two and most others do).  We will consider anything above 5 to be good for our tests.  Now lets feed it the host name we know are associated with malware.

C:\freq>freq.exe --measure "asdfl213u1" custom.freq
3.15113061843
C:\freq>freq.exe --measure "po24sf92cxlk" custom.freq
2.44994506765

Our malicious hosts are less than 5.  5 seems to be a pretty good benchmark.  In my testing it seems to work pretty well for picking out these abnormal host names.  But it isn't perfect.  Nothing is.   One problem is that very small host names and acronyms that are not in the source files you use to build your frequency tables will be below 5.  For example, "fbi" and "cia" both come up below 5 when I just use classic literature to build my frequency tables.  But I am not limited to classic literature.  That leads us to step 3.

Step 3) Tune for your organization.

The real power of frequency tables is when you tune it to match normal traffic for your network.  The program has two options for this purpose; --normal and --odd.   --normal can be given a normal string and it will update the frequency table with that string.   Both --normal and --odd can be used with the --weight option to control how much influence the given string has on the probabilities in the frequency table.  It's effectiveness is demonstrated by the accompanying youtube video.  Note that marking "random" host names as --odd is not a good strategy.  It simply injects noise into the frequency table.   Like everything else in security identifying all the bad in the world is a losing proposition.   Instead focus on learning normal and identifying anomalies.  So passing --normal "cia" --weight 10000 adds 10000 counts of the pair "ci" and the pair "ia" to the frequency table and increases the probability of "cia" to some number above 5..

C:\freq>freq.exe --normal "cia" --weight 10000 custom.freq

The source code and a Windows Executable version of this program can be downloaded from here: https://github.com/MarkBaggett/MarkBaggett/tree/master/freq

Tomorrow I in my diary I will show you some other cool things you can do with this approach and how you can incorporate this into your own tools.

Follow me on twitter @MarkBaggett

Want to learn to use this code in your own script or build tools of your own?  Join me for Python SEC573 in Las Vegas this September 14th!  Click here for more information.

What do you think?  Leave a comment.

In the security community, the deprecation of SSL has been hailed as a good thing by almost everyone.  Not only has SSL been deprecated, it's been deprecated with extreme prejudice, and with extreme rapidity.  And not just in browsers (see Johannes's story here https://isc.sans.edu/diary/19323 )

However, it's become apparent in recent weeks that while most website administrators have caught up quickly to the new reality of TLS-Only encryption in browsers, many system administrators have been caught flat-footed.

Just in the last couple of weeks, I've worked with system administrators who have had problems administering critical system infrastructure, infrastructure that uses SSL for it's HTTPS connection, and does support TLS.  While the vendors of this infrastructure will quickly point out that a firmware update to their gear will quickly solve this problem, these firmware updates have almost universally come late to the party - in a lot of cases they haven't been available until fairly recently.

Admins are often caught off-guard, not realizing that they're browser update has broken their infrastructure admin until something important happens, something that requires adding a SAN LUN, adding Fiber Channel Zones for that new pod of servers, or doing a remote power off / power on of a critical server using its remote console board.

Stuff that I have seen personally has included (Vendor names left out, sorry):

• SAN Administration consoles from at least 3 vendors
• Firewall and IPS admin consoles (yes, really)
• "Big Iron" Unix remote admin board
• Popular Server remote admin boards from several vendors

The catch-22 in this situation is that, looking at this list, all of these things are very tough to book intrusive administration for.  Scheduling a firmware update for the admin console of your SAN for instance can be a very challenging task - IT Management is likely to use terms like "Outage", "Risk", often with the word "Unacceptable" in the same sentence.  For things like your large Solaris or AIX Servers, Storage systems and so on, management is often much more comfortable NOT approving patches or updates, electing instead to isolate them to a secured vlan.  .... Or worse yet, to not patch them and NOT isolate them.

(Mind you, the golden rules of pentesting include things like "secured vlans aren't" and "air gap networks are isolated, except for that one wire or one firewall rule ..".)

What have you found that you couldn't admin because of SSL deprecation?  Was an update available?  And if so, did you kick yourself for not applying it 2 years ago, or was the paint still wet on the update?  Have you applied an update to deal with this, and found that it broke something else?

Please, share on our comment form.  And feel free to include vendor names - just because I can't doesn't limit you that way!

===============
Rob VandenBrink
Metafore

Introduction

An actor using gates registered through BizCN recently switched from Fiesta to Nuclear exploit kit (EK).  This happened around last month, and we first noticed the change on 2015-06-15.

I started writing about this actor in 2014 [1, 2] and recently posted an ISC diary about it on 2015-04-28 [3].  I've been calling this group the "BizCN gate actor" because domains used for the gate have all been registered through the Chinese registrar BizCN.

We collected traffic and malware samples related to this actor from Friday 2015-07-03 through Sunday 2015-07-05.  This traffic has the following characteristics:

• Compromised servers are usually (but not limited to) forum-style websites.
• Gate domains have all been registered through the Chinese registrar BizCN using privacy protection.
• The domains for Nuclear EK change every few hours and were registered through freenom.com.
• Nuclear EK for this actor is on 107.191.63.163, which is an IP registered to Vultr, a hosting provider specializing in SSD cloud servers [4].
• The payload occasionally changes and includes malware identified as Yakes [5], Boaxxe [6], and Kovter.

NOTE:  For now, Kovter is relatively easy to spot, since it's the only malware I've noticed that updates the infected host's Flash player [7].

Chain of events

During a full infection chain, the traffic follows a specific chain of events.  The compromised website has malicious javascript injected into the page that points to a URL hosted on a BizCN-registered gate domain.  The gate domain redirects traffic to Nuclear EK on 107.191.63.163.  If a Windows host running the web browser is vulnerable, Nuclear EK will infect it.  Simply put, the chain of events is:

• Compromised website
• BizCN-registered gate domain
• Nuclear EK

Let's take a closer look at how this happens.

Compromised website

Compromised websites are the first step in an infection chain.  Shown below are examples of malicious javascript injected into pages from websites compromised by this actor.

In most cases, the malicious javascript will be injected on any page from the site, assuming you get to it from a search engine or other referrer.

BizCN-registered gate domain

The gate directs traffic from the compromised website to the EK.  The HTTP GET request to the gate domain returns javascript.  In my last diary discussing this actor [3], you could easily figure out the URL for the EK landing page.  Now, the javascript uses unicode-based obfuscation, so you have to translate it to ASCII to see the EK landing page as noted in the image below.

We've found at least four IP addresses hosting the BizCN-registered gate domain.  They are:

• 136.243.25.241
• 136.243.25.242
• 136.243.224.10
• 136.243.227.9

If you have proxy logs or other records of your HTTP traffic, search for these IP addresses.  If you find the referrers, you might discover other websites compromised by this actor.

Nuclear EK

Examples of infection traffic generated from 2015-07-03 through 2015-07-05 all show 107.191.63.163 as the IP address hosting Nuclear EK.  This IP address is registered to Vultr, a hosting provider specializing in SSD cloud servers [4].  

The image below shows one of the landing pages sent by Nuclear EK on 2015-07-05.

Next, Nuclear EK sends a flash exploit as shown below.

Finally, Nuclear EK sends the malware payload.  It's obfuscated, and we have the decoded version available in a zip archive (see a link for it near the end of this diary).

Malware sent by this actor

During the three-day period, we infected ten hosts, saw two different Flash exploits, and retrieved five different malware payloads.  Most of these payloads were Kovter (ad fraud malware).  We also found two other types of malware sent by the BizCN gate actor.

Below are links to reports from hybrid-analysis.com for the individual pieces of malware:

• https://www.hybrid-analysis.com/search?query=6c6e9df96b6fcea7214f05ae7ff37659
• https://www.hybrid-analysis.com/search?query=7de52f24bebcf6cea99909a484a26229
• https://www.hybrid-analysis.com/search?query=3367b09515255030e3d0b4474b385cdb
• https://www.hybrid-analysis.com/search?query=464d37e0c86d7dcd6e3d59ef696876fd
• https://www.hybrid-analysis.com/search?query=7647d8dc75aeb53b04c9dad0d3a7a5b2

Final words

It's usually difficult to generate a full chain of infection traffic from compromised websites associated with this BizCN gate actor.  We often see HTTP GET requests to the gate domain return a 404 Not Found.  In some cases, the gate domain might not appear in traffic at all.

We believe the BizCN gate actor will continue to make changes as a way to evade detection.  Fortunately, the ISC and other organizations try our best to track these actors, and we'll let you know if we discover any significant changes.

Examples of the traffic and malware can be found at:

• http://malware-traffic-analysis.net/2015/07/05/index2.html

As always, the zip file is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

---
Brad Duncan
Security Researcher at Rackspace and ISC Handler
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] http://malware-traffic-analysis.net/2014/01/01/index.html
[2] https://isc.sans.edu/diary/Gate+to+Fiesta+exploit+kit+on+9424221669/19117
[3] https://isc.sans.edu/diary/Actor+using+Fiesta+exploit+kit/19631
[4] https://www.vultr.com/about/
[5] https://www.virustotal.com/en/file/b215e4cf122e3b829ce199c3e914263a6d635f968b4dc7b932482d7901691326/analysis/
[6] https://www.virustotal.com/en/file/a0156a1641b42836e64d03d1a0d34cd93d3b041589b0422f8519cb68a4efb995/analysis/
[7] http://malware.dontneedcoffee.com/2015/07/kovter-adfraud-is-updating-flash-for-you.html

Last week I received another malicious document with embedded payload encoded with base64. A bit tired of repeating the same manual operations to extract and decode base64 content, I quickly wrote a small Python script to help me. base64dump.py searches through the given file for base64 strings (delimited by non-base64 characters), and produce a report like this one:

Here is a video of the tool in action.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Yesterday I mentioned that McAfee quarantine files on Windows (.BUP extension) are actually OLE files.

I'm going to write a couple of diary entries highlighting some file types that are OLE files, and I'm starting with .BUP files.

OLE files can be analyzed with my oledump tool. Here is an example with a .BUP file:

As you can see, this quarantine file contains two steams: Details and File_0. Details is the McAfee anti-virus report, and File_0 is the quarantined file. Remark that quarantine files can contain more than one quarantined file, they will be numbered File_0, File_1, ...

If we look at the Details stream, it doesn't tell us much:

That's because it is XOR encoded. The key is 0x6A (BTW, 0x6A is j and I always wondered if that was a reference to John). We can use an oledump decoder to decode this:

That's readable, so let's dump it:

Generic BackDoor.agb doesn't tell us much, but if we look at the beginning of the quarantined file, it becomes clear:

This is a JPEG file with an eval statement in the EXIF data.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Quarantine files are produced by anti-virus programs. When an anti-virus detects a file (a positive), it will take action. A possible action is to put the detected file in quarantine: remove it from its actual location and store it in quarantine: a location where it can do no harm.

Quarantine files are a means to handle false positives: if a detection turns out to be a false positive, the file can be recovered from quarantine.

But for an analyst, quarantine files are also interesting in case of true positives: it allows us to recover and analyze the file. The anti-virus will have a function to restore the quarantined file, but this is not always ideal. For example, on a production server, you don't want to restore malware. Each anti-virus vendor has his own method to contain quarantined files. Many of them use a proprietary file format.

I want to take the opportunity of this diary entry to highlight a tool to handle McAfee quarantine files. On Windows, McAfee quarantine file can be found in the quarantine folder. They have extension .bup. punbup is a tool written by @herrcore to handle .bup files. It allows you to view the anti-virus report produced for this detection (-d), it can give you the hashes of the quarantined files (-c) and it can also extract them to disk. I have also contributed to this free open-source tool by adding options to dump the quarantined files to screen (-x hexdump and -a ascii dump).

You will notice that this Python program requires a module: olefile. That's right, McAfee uses the Compound File Binary Format (aka ole files) to store quarantined files. So you can also use my oledump tool to work with .bup files, an upcoming diary entry will focus on this.

If you know tools to process quarantine files from other anti-virus vendors, please post a comment.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Introduction

Angler exploit kit (EK) has been evolving quite a bit lately.  Recently, this EK has been altering its URL patterns on a near-daily basis.  The changes accumulate, and you might not recognize current traffic generated by Angler.  After two weeks of vacation, I almost didn't recognize it.  This diary provides two traffic examples of Angler EK as we enter July 2015.

Angler EK still pushing a lot of CryptoWall 3.0

Angler pushes different payloads, but we're still seeing a lot of CryptoWall 3.0 from this EK.  We first noticed CryptoWall 3.0 from Angler near the end of May 2015 [1], and we've seen a great deal of it since then [2].  The CryptoWall 3.0 sample for today's diary used 1LY58fiaAYFKgev67TN1UJtRveJh81D2dU as a bitcoin address for the ransom payment.

Traffic examples

Traffic from Tuesday, 2015-07-01 shows Angler EK from 148.251.167.57 and 148.251.167.107 at different times during the day.  Click on the images below for a full-size view of the associated HTTP traffic from the infected Windows hosts.

The people at Emerging Threats do a good job of keeping their Snort-based signatures up-to-date through their ETOpen and Proofpoint ET Pro rulesets.  Below is an image of events from the infection traffic I saw using Suricata on Security Onion.

Preliminary malware analysis

Sample of a CryptoWall 3.0 malware payload delivered by Angler EK on 2015-07-01:

• File size:  240.0 KB ( 245760 bytes )
• MD5 hash:  f52679c115377e42943b0427d968f891
• Detection ratio:  4 / 55
• First submitted:  2015-07-01 23:01:15 UTC
• https://www.virustotal.com/en/file/2dfd43d6776b5712e5fd9d82d3a6b5d0097d2b9371915539ed0b88f4097224a8/analysis/
• https://malwr.com/analysis/ZGYzOTljNGZjY2M1NDliY2FkY2YzNzcxYTQ4OWI4NGQ/
• https://www.hybrid-analysis.com/sample/2dfd43d6776b5712e5fd9d82d3a6b5d0097d2b9371915539ed0b88f4097224a8?environmentId=1

Final words

Pcap files of the 2015-07-01 infection traffic are available at:

• http://www.malware-traffic-analysis.net/2015/07/01/2015-07-01-Angler-EK-sends-CryptoWall-3.0-traffic-example-1.pcap
• http://www.malware-traffic-analysis.net/2015/07/01/2015-07-01-Angler-EK-sends-CryptoWall-3.0-traffic-example-2.pcap

A zip file of the associated malware is available at:

• http://www.malware-traffic-analysis.net/2015/07/01/2015-07-01-Angler-EK-and-CryptoWall-3.0-artifacts.zip

The zip file is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

---
Brad Duncan
ISC Handler and Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] https://isc.sans.edu/diary/Angler+exploit+kit+pushing+CryptoWall+30/19737
[2] https://isc.sans.edu/diary/Increase+in+CryptoWall+30+from+malicious+spam+and+Angler+exploit+kit/19785

Yesterday, Apple released patches for OS X, iOS, Safari, Mac EFI, iTunes and Quicktime (Windows) [1]. Here some of the highlights:

EFI Update

"EFI" is the firmware running your Mac. This update will only apply on certain Apple computer models. Two bugs that are being fixed by this updata:

CVE-2015-3692: This issues could allow an attacker to modify the EFI firmware, gaining persistent access to the system.  The bug was made public about two months ago and the basic issue was that the firmware is not properly locked as a system returns from sleep [2]. 

CVE-2015-3693: Researchers at Intel and Carnegie Mellon University originally discovered this issue, and in March, Google's project zero released details about a working exploit for the "rowhammer" vulnerability [3][4]. This problem is not specific to Apple, but effects many systems using modern DRAM memory. In short, by repeatedly writing to some areas of memory, adjacent rows of memory can be effected allowing an attacker to manipulate code they would not have access to otherwise. 

OS X Update

This update affects versions of OS X back to Mountain Lion (10.8). A total of 46 issues are addresses (and even more individual vulnerabilities). So here just some highlights:

Open Source Software: OS X includes many standard open source software products like Apache and libraries like OpenSSL. These open source products are updates.

SSL: A number of changes were made to SSL. For example, some intermediate certificates issues by CNNIC are no longer trusted. Interestingly, the CNNIC CA itself still seems to be trusted (others, like Google, removed CNNIC entirely). Apple does not provide a list of new certificates added, but just refers to its complete list of trusted certificates [5]. You can still manually "distrust" the certificate by adjusting the trust in Keychain Access. To respond to the logjam vulnerability, Diffie-Hellman parameters are now restricted to 768 bits or larger (before this, 512 bit was possible). This is in line with what other operating systems have implemented in response. There is a small chance that this will cause problems with connections to legacy servers.

EFI Related: The issues address by the EFI update, are also addresses by the OS X update.

Mail: An e-mail message was able to load web pages, which then could be used to various phishing attacks, for example by displaying a popup password dialog that appears to come from Mail.app. This issue was already made public early June [6]

iOS

Due to the overall similar code base between iOS and OS X, many of the OS X issues apply to iOS as well. For example the TLS issues, as well as the Mail issue affect iOS and are patched with this update. On interesting issue that I hadn't heard of before (but not surprising). Malicious SIM cards could lead to arbitrary code execution. 

Safari

As usual, Safari is made available as it's own update. Only 4 different issues here ranging from cross origin issues to remote code execution.

iTunes / QuickTime 

These updates affect Windows (the OS X version is rolled into the OS X patch). There is no official QuickTime version for Windows beyond Windows 7. But if you are using the Windows 7 version on Windows 8/8.1, you will likely still need to update.

[1] https://support.apple.com/en-us/HT201222​
[2] https://reverse.put.as/2015/05/29/the-empire-strikes-back-apple-how-your-mac-firmware-security-is-completely-broken/
[3] http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
[4] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
[5] https://support.apple.com/en-us/HT202858
​[6] https://github.com/jansoucek/iOS-Mail.app-inject-kit/tree/master

​

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn