Monthly Archives: July 2015

Zero Day Initiative (ZDI) Publically Discloses 4 New Internet Explorer Vulnerabilities

Update: 6th August 2015:
Sorry for not updating this post sooner. According to two separate new articles here and here, only one of these zero day flaws affected the desktop version of IE (installed on workstations, laptops and servers). This flaw ZDI-15-359 has been previously patched by Microsoft. In addition, the remaining three flaws affect the version of IE bundled with Windows Phones. A smaller number of Windows Phone users are affected than the number of devices that run the desktop version of IE; however Windows Phone users should monitor for an update to their phone’s software that should resolve these remaining security issues.

In addition, while these issues were publically disclosed in July, exact details of the issues were not provided in the above linked to advisories by ZDI. Public disclosure usually means all details are disclosed but in this case the right decision of not to publish exact details should help reduce the risk to users until these remaining issues are patched.

Thank you.
Original Post:
Between late 2014 and early 2015 HP’s Zero Day Initiative (ZDI) responsibly disclosed (defined) 4 security vulnerabilities within Internet Explorer (IE) to Microsoft. In all 4 of the disclosures, Microsoft investigated and provided information regarding an expected build/version of IE that would resolve these issues but in all cases, no expected date for this updated build was provided. ZDI notified Microsoft of their intention to disclose details of these flaws publically following the end of a 120 day deadline.

For each of these 4 security vulnerabilities disclosed by ZDI, each must be exploited by a user visiting a compromised legitimate website (as seen in watering hole attacks) or a website specifically designed to exploit these flaws.

What Can I Do To Defend Myself From These Unpatched Issues?

  1. A suggestion that does not cost any funds and is easy to implement would be to use another web browser until these issues are patched e.g. Mozilla Firefox, Apple Safari, Opera and Google Chrome being the most popular choices.
  2. Use caution when clicking on any links in emails, instant messages or social networking posts when the links were received unexpectedly or the wording of such messages is suspicious. For shortened links, consider using a preview service to check the destination of the full link before visiting it. Links to preview services are available within the “Protecting Your PC” page of this blog.
  3. Install and enable the default settings of Microsoft EMET. On my personal PCs which use Windows 8.1 64 bit and Windows 7 64 bit I have all mitigations for IE 11 64 bit enabled. A list of known EMET application incompatibilities is available here. You can also ask questions within the EMET forum. The following are very useful tutorials on EMET 5 and EMET 4 (still relevant).
  4. When Windows 10 is released next week, consider using Microsoft Edge since it incorporates additional defences against Use-After-Free flaws (3 of these flaws are use-after-flaws (defined)) and would not be vulnerable to these issues since Edge is based on a separate codebase to IE (Edge is a development fork of IE). For more background information regarding Microsoft Edge, please see a previous blog post of mine.
  5. Each of the ZDI advisories (linked to below) include disabling Active Scripting within IE. While this is an effective mitigation, it may affect the reliable display of the websites that you visit.

The recommendation of using EMET will not only protect against these unpatched flaws but also make exploitation of known flaws much harder. Alternatives to EMET are Malwarebytes Anti-Exploit (free or paid for versions) and HitmanPro.Alert (paid for product).

I will update this post should more information on mitigations for these issues become available or any further information is shared regarding when these issues may be patched.

Links to the 4 advisories published by ZDI are shown below:

ZDI-15-359: Microsoft Internet Explorer CTableLayout::AddRow Out-Of-Bounds Memory Access Vulnerability

ZDI-15-360: Microsoft Internet Explorer CAttrArray Use-After-Free Remote Code Execution Vulnerability

ZDI-15-361: Microsoft Internet Explorer CCurrentStyle Use-After-Free Remote Code Execution Vulnerability

ZDI-15-362: Microsoft Internet Explorer CTreePos Use-After-Free Remote Code Execution Vulnerability

Thank you.

Google Releases Security Update for Chrome

Yesterday Google made available Chrome version 44.0.2403.89 for Linux, Mac OS X and Windows. This update contains fixes for 43 issues addressing 20 CVEs (definition of CVE) (12x High severity, 6x Medium severity, 1x Low severity, 1x Uncategorized).

As a convenience to users Google Chrome updates automatically and will apply the update the next time Chrome is closed and then re-opened. Chrome can also be updated immediately by clicking the Options button (it looks like 3 stacked small horizontal lines) in the upper right corner of the window and choosing “About Google Chrome” from the menu. Follow the prompt to Re-launch Chrome for the update to take effect.

Full details of the update are available in this Google blog post.

While Google Chrome updates generally install without issues, 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.

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 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.

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.

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):

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.