Microsoft Releases Out of Band Security Update

Earlier today Microsoft released an out of band (i.e. un-scheduled) security update to resolve 1 CVE (defined) in the Microsoft OpenType Font Driver. At this time, no Known Issues are listed for this update within the revised Security Bulletin Summary page. I have installed this update on multiple Windows 8.1 64 bit and Windows 7 64 bit systems with no issues. The update does require a system restart.

Please install this update as soon as possible since it is a critical update and as mentioned in the security bulletin consistent exploitation of this vulnerability is possible. This security bulletin also lists workarounds should you not be able to apply the update at this time.

Thank you.

Skype Recommends Users Change Passwords

For the last 3 weeks a large number of users have been reporting spoofed messages being sent from their Skype accounts or receiving such messages. The messages are generally very short and contain shortened links to websites based in Russia possibly hosting malicious code.

In order to prevent this issue from becoming any worse, Skype have recommended that all users change their passwords by following the steps in this link.

My Skype account has not been affected by this issue but as a precaution I have changed my password. I will continue to monitor this issue and will update this post should any further recommendations be provided by Skype.

Update: 6th August 2015:
Sorry for not updating this post sooner. Skype has concluded their investigation of this issue. They have determined that user login credentials were obtained possibly using phishing attacks or when the credentials used to login into other online accounts match the credentials used for Skype.

Please find a full explanation and appropriate recommendations from Skype within the first post of this Skype forum thread. As before my account was not affected by this issue but I did change my password (as mentioned above) when this issue was first highlighted.

Update: 9th Sept 2015: Malwarebytes provides further information on this issue within their blog post.

Thank you.

New Attack Method Published For RC4

Update: 7th September 2015: As mentioned in a more recent blog post Mozilla, Google and Microsoft have announced plans to complete the phase out of RC4 in early 2016. Their actions will mean that the advice provided below will be redundant.
====================
Original Post:

Two researchers from the University of Leuven have published a research paper that describes a refined attack technique on the cryptographic algorithm RC4 (Rivest Cipher 4, originally developed by cryptographer Ron Rivest).

While previous attacks on RC4 have been detailed in the past the amount of time needed, approximately 2000 hours meant that such attacks while possible were not practical enough to make them likely. The new attack should take about 75 hours to locate the correct authentication cookie used in an encrypted session.

The attack has been reduced in time due to new biases that have been found in the initial keystream bytes of RC4 which means that fewer encrypted samples of the desired authentication cookie are required (reduced from 13 . 2 ^ 30 to 9 . 2 ^ 27). In addition, the algorithm used to gather these samples can now make 4450 requests per second, an increase from 1700 requests per second of a previous attack method. These requests collect all possible values of the authentication cookie and then an algorithm is used to brute force these collected values until the desired value is found. This has resulted in the dramatic decrease in the time needed for this attack to be successful. The researchers tested this attack on real-world devices and achieved a time of 52 hours (see the “Demonstration” heading) needed to obtain the actual authentication cookie.

One means of performing this attack is by initiating a man in the middle attack (MITM, MITM defined) by inserting malicious JavaScript code onto the webpage being viewed by the victim’s web browser, an alternative is to load this code from a different web page by hijacking an existing TCP connection to a website. This code (delivered by either of these means) will generate the requests mentioned above needed to create a dataset of possible cookie values to brute force.

While 75 and 52 hours are very quick times in which an encrypted session can be compromised (in addition this attack does not require that a web browser remain open during the entire attack, since it can be resumed at a later stage), such an attack can still be avoided if the session time out value of a cookie is less than the time needed to complete the attack. Since this attack is against RC4, implementing Forward Secrecy (while an excellent additional security measure) will not fully protect from this underlying flaw within RC4.

Why should this attack be considered important?
If this RC4 attack were used by an attacker they could then hijack the website account that you are logged into and carry out any action that your account could. A summary of such actions is provided in the “Introduction” paragraph of the researcher’s website. In addition, since WPA-TKIP also uses RC4, this attack would allow an attacker to view your traffic (which travels between your device and a wireless router/wireless access point) after 1 hour or less.

How can I protect myself from this issue?
If you maintain/are the administrator of a website that uses RC4 to provide HTTPS, it would be recommended to migrate to a newer cipher e.g. AES-GCM since it provides added security while maintaining acceptable performance. Unfortunately approximately 30% of websites still use RC4.

You should also consider disabling RC4 within your web browser. I have provided a summary of how to do this for some web browsers:

Google Chrome: Note of caution, the list of parameters appears to need additions mentioned in the accompanying code.google.com post. This SuperUser thread may also be of assistance.

Mozilla Firefox: Visit about:config Perform a search for RC4, set all results to false by double clicking them.

Internet Explorer: See this Microsoft SRD blog post for details.

You can verify that RC4 is disabled by testing your web browser after disabling RC4. RC4 should not appear in the Cipher Suites heading of this test.

Since this attack uses JavaScript, extensions such as NoScript for Mozilla Firefox and ScriptSafe for Google Chrome should mitigate this attack. If the large number of JavaScript requests took place on a corporate network, it’s likely that an IDS/IPS would detect it and terminate the connection.

If your wireless router/wireless access point is using WEP or WPA-TKIP, please consult the manual of your router/access point to determine if it supports the more modern WPA2 encryption and switch to WPA2 if you can. A disadvantage of using WPA2 is that some older wireless devices don’t support it. One device that I previously used on my network occasionally was from 2008 (WPA2 was introduced in 2006) and it did support WPA2 (it still worked online after enabling WPA2 along with a new pre-shared key). However I realize not all devices from this timeframe would have this flexibility.

If you use Java, consider installing the most recent Java SE/JDK update since it removed RC4 from the cipher suite of both client and servers installations of Java.

Conclusion
While this new RC4 attack remains a potential option for attackers it is less likely to be used given that it would take approximately 72 hours to complete (assuming the cookie session timeout is also long enough to allow this).

However it would be prudent to switch to newer ciphers and encryption methods (for wireless routers/wireless access points) since time will likely allow this attack to be refined further (in the case of the HTTPS exploit method detailed above) or newer attacks to be derived from it meaning that the use of RC4 will become riskier over time. Moreover, newer ciphers already offer superior security to RC4. In addition, WPA-TKIP has previous known weaknesses, providing another reason to use WPA2 for your wireless routers/wireless access points.

Thank you.

Adobe and Google Strengthen Flash against Exploits

====================
Update: 30th November 2015:
The additional Flash Player security mitigations discussed in this blog post have since been bypassed by attackers. Further details are available from this Trend Micro blog post. Possible further mitigations are in development by security firm Endgame. These additional mitigations are discussed in a more recent blog post.
Thank you.

====================
Original Post:
====================
With the recent public disclosure of 3 Adobe Flash Player zero day vulnerabilities as part of the data breach of the “Hacking Team”; Adobe and Google have worked together to introduce additional exploit mitigations/defences to Adobe Flash Player.

These mitigations incorporate 3 improvements as detailed below:

Heap Partitioning
To protect against general buffer overflows that overflow into another object e.g. Vector. the memory in use by Flash Player for such Vector. objects is no longer stored in one area which means that an overflow cannot occur since one area of memory is no longer located beside another. In reality the Flash heap no longer contains Vector. objects, instead they are placed on the memory heap belonging to the operating system and no longer present on the Flash heap (where they could be corrupted). This mitigation defends against heap overflow and the common use-after-free (defined) exploits (since free chunks of memory are no longer freed within the Flash heap thus the attacker does not know the value to set the pointer to; in order to be able to use a new block of memory placed at the location that was just freed). This mitigation is especially effective with 64 bit versions of web browsers installed on a 64 bit operating systems due to 32 bit address space limitations no longer being present.

Memory Randomization of the Flash Heap
For allocations of memory that are greater than 1 MB are now randomized more thoroughly than before (in other words more entropy has been added). When a 64 bit system is in use, the Flash heaps position in memory will very likely be located far from other memory in use. Since the heap is so far away from other memory sections in use, a buffer overflow would unlikely be able to corrupt enough memory sections in order to use them for malicious purposes (since a 32 bit buffer overflow has a limit e.g. 2^32 * sizeof (in bytes) of variable type in use e.g. char, int, double etc.). The limit would be reached before the overflow could reach far enough into memory to have the intended effect.

At this time, this mitigation is only available within the Flash plugin built into Google Chrome, Adobe plans to make this mitigation available for all other versions of Flash in August.

Vector Length Validation
The final notable mitigation prevents the successful exploitation of buffer overflows for Vector objects. For each Vector object that is created a corresponding length of that object is stored along with a validation secret namely a value generated when the object was allocated by the operating system memory manager. When an exploit corrupts the known length of the Vector object, if they don’t know the value of the validation secret, this will cause a runtime error to be generated and all running code will halt, protecting you from the exploit. This secret value acts very much like the security cookie of Microsoft’s buffer overflow protection built into Windows with the introduction of the /GS (guard stack) compiler flag of Visual Studio 2005. This technology was incorporated into Windows XP Service Pack 2 in August 2004.

Conclusion
While these mitigations will make it harder for exploits to carry out their intended purpose, they won’t stop all exploits (I don’t mean this is in an offensive manner, no mitigation is perfect and these new mitigations were designed to make it harder not impossible for exploits occur).

In addition, it’s very likely that the exploit authors will begin to create exploits that avoid these mitigations either by working around them or using object types that don’t yet have these mitigations in place. However Google have pledged to continue improving the mitigations available as time goes on. It will be interesting to see the kinds of exploits/vulnerabilities emerging in the coming months.

Thank you.

July 2015 Security Updates Summary

On Tuesday the 14th of July, Microsoft made available its monthly security updates resolving 59 CVEs (definition of the term CVE). Details of the affected products are provided in their Security Bulletin Summary. This page also details any Known Issues for these security updates. At the time of writing, only issues for the SQL Server bulletin were present. In addition, an excellent source for information on issues that arise from installing these updates is the IT Pro Patch Tuesday blog.

Adobe made updates available for Flash Player v18.0.0.203 to resolve 2 critical zero day CVEs, Adobe Shockwave Player resolving 2 CVEs and Adobe Acrobat/Adobe Reader resolving 46 CVEs.

In addition, Oracle made available security updates for Java resolving 25 CVEs, among them the zero day CVE-2015-2590.

You can monitor the availability of security updates for the majority of your software from the following website (among others) or use Secunia PSI:

—————-
US Computer Emergency Readiness Team (CERT) (please see the “Information on Security Updates” heading of the Protecting Your PC page):
https://www.us-cert.gov/
—————-

If you use any of the above software, please install the appropriate updates as soon as possible.

If you wish to prioritize some of the updates I would recommend installing Adobe’s Flash Player update first due to the nature of the 2 critical flaws that it resolves. The next priorities should be Microsoft’s updates for Internet Explorer (it also includes a fix for the zero day flaw CVE-2015-2425), Remote Desktop Protocol, VBScript, Microsoft Office, ATM Font Driver and Windows Hyper-V due to their severity. In addition the ATM Font Driver vulnerability CVE-2015-2387 and Microsoft Office vulnerability CVE-2015-2424 have already seen exploitation. With high profile issues being resolved by Adobe’s updates it is recommended to install them before they begin to be incorporated into exploit kits for much wider exploitation.

I would also recommend using the Attack Surface Reduction (ASR) feature of Microsoft EMET 5.2 in order to mitigate Adobe Flash being used to exploit vulnerabilities when you open a Microsoft Office document or Adobe PDF file. Details of the ASR feature are available on page 9 and 19 within the EMET user guide (follow this link and opt to download EMET, you can then choose to download only the PDF user guide). How to add Adobe Flash (flash*.ocx) is detailed in this news article. I suggest adding this file name (the full name including the wildcard * and the ocx file extension) to any application that you use that can open Microsoft Office documents or Adobe PDF files as a defence in depth measure. I have done this for all of my Microsoft Office applications and my PDF reader with no issues encountered.

As a routine precaution I would recommend backing up the data on any device for which you are installing updates in order to prevent data loss in the rare event that any update causes unexpected issues.

Thank you.