New Zero-Day Vulnerability Affects all Versions of Internet Explorer Browser

In a Security Advisory (2963983) released yesterday, Microsoft acknowledges a zero-day Internet Explorer vulnerability (CVE-2014-1776) is being used in targeted attacks by APT groups, but the currently active attacks are targeting IE9, IE10 and IE11.

Reported flaw in Internet Explorer is a Remote Code Execution vulnerability, which resides in ‘in the way that Internet Explorer accesses an object in memory that has been deleted or has not been properly allocated.‘ advisory said.

Microsoft Investigation team is currently working with FireEye Security experts, and dubbed the ongoing targeted campaign as “Operation Clandestine Fox“.

FireEye explained that an attacker could trigger the zero-day exploit through a malicious webpage that the targeted user has to access with one of the affected Internet Explorer browser.  Successful exploitation of this vulnerability allows an attacker to execute arbitrary code within the Internet Explorer in order to gain the same user rights as the current user.

Internet Explorer zero-day exploit depends upon the loading of a Flash SWF file that call for a Javascript in vulnerable version Internet Explorer to trigger the flaw, which allows the exploit to bypass Windows’ ASLR and DEP protections on the target system by exploiting the Adobe Flash plugin.

According to the advisory, currently no security patch available for this vulnerability. “Collectively, in 2013, the vulnerable versions of IE accounted for 26.25% of the browser market.” FireEye said.

Microsoft is working on a security patch for Internet Explorer vulnerability. However, you can still migrate the threat by following below given methods:

• Install Enhanced Mitigation Experience Toolkit (EMET 4.1), a free utility that helps prevent vulnerabilities in software from being successfully exploited.
• You can protect against exploitation by changing your settings for the Internet security zone to block ActiveX controls and Active Scripting.
• Tools > Internet Options > Security > Internet > Custom Level > Under Scripting Settings > Disable Active Scripting
• Under Local intranet’s Custom Level Settings > Disable Active Scripting
• If you are using Internet Explorer 10 or the higher version, enable Enhanced Protected Mode to prevent your browser from Zero-Day Attack.
• IE Exploit will not work without Adobe Flash. So Users are advised to disable the Adobe Flash plugin within IE.
• De-Register VGX.dll (VML parser) file, which is responsible for rendering of VML (Vector Markup Language) code in web pages, in order to prevent exploitation. Run following command:
  • regsvr32 -u “%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll”

Hackito Ergo Sum- open conference for hacking and security research

Hackito Ergo Sum welcome you on April 24th until April 26th 2014 in a great and amazing location: La Villette, Paris. HES is an open conference for hacking and security research.

Speakers 2014

• Edmond “bigezy” Rogers – An amazing keynote
• Renaud Lifchitz – A common weakness in RSA signatures: extracting public keys from communications and embedded devices
• Hendrik Schmidt & Brian Butterly – LTE vs. Darwin: The Evolution Strikes Back?
• Milan Gabor & Danijel Grah – Vaccinating APK’s
• Christian Sielaff & Daniel Hauenstein – OSMOSIS – Open Source Monitoring Security Issues
• Andrei Dumitrescu – WMI Shell: A new way to get shells on remote Windows machines using only the WMI service
• Eric Leblond – Suricata 2.0, Netfilter and the PRC
• José Garduño – The government as your hacking partner: using public data to block passports, national ID cards, steal tax data, and other mischievous deeds.
• joernchen of Phenoelit – Ruby on Rails exploitation and effective backdooring
• Andreas Bogk – Applying science to eliminate 100% of buffer overflows
• Graham Steel – Hardware Security Modules: attacks and secure configuration
• Alexandre De Oliveira & Pierre-Olivier Vauboin – TBA
• Laurent Ghigonis – Hacking Telco equipment: The HLR/HSS

More Information:

• Speakers
• Schedule
• HSF – HackerSpace Fest 2014

Using Facebook Notes to DDoS any website by chr13

Facebook Notes allows users to include <img> tags. Whenever a <img> tag is used, Facebook crawls the image from the external server and caches it. Facebook will only cache the image once however using random get parameters the cache can be by-passed and the feature can be abused to cause a huge HTTP GET flood.
Steps to re-create the bug as reported to Facebook Bug Bounty on March 03, 2014.
Step 1. Create a list of unique img tags as one tag is crawled only once

        <img src=http://targetname/file?r=1></img>
        <img src=http://targetname/file?r=1></img>
        ..
        <img src=http://targetname/file?r=1000></img>

Step 2. Use m.facebook.com to create the notes. It silently truncates the notes to a fixed length.
Step 3. Create several notes from the same user or different user. Each note is now responsible for 1000+ http request.
Step 4. View all the notes at the same time. The target server is observed to have massive http get flood. Thousands of get request are sent to a single server in a couple of seconds. Total number of facebook servers accessing in parallel is 100+.
Initial Response: Bug was denied as they misinterpreted the bug would only cause a 404 request and is not capable of causing high impact.
After exchanging few emails I was asked to prove if the impact would be high. I fired up a target VM on the cloud and using only browsers from three laptops I was able to achieve 400+ Mbps outbound traffic for 2-3 hours.

Number of Facebook Servers: 127
Of course, the impact could be more than 400 Mbps as I was only using browser for this test and was limited by the number of browser thread per domain that would fetch the images. I created a proof-of-concept script that could cause even greater impact and sent the script along with the graph to Facebook.
On April 11, I got a reply that said

Thank you for being patient and I apologize for the long delay here. This issue was discussed, bumped to another team, discussed some more, etc.
In the end, the conclusion is that there’s no real way to us fix this that would stop “attacks” against small consumer grade sites without also significantly degrading the overall functionality.
Unfortunately, so-called “won’t fix” items aren’t eligible under the bug bounty program, so there won’t be a reward for this issue. I want to acknowledge, however, both that I think your proposed attack is interesting/creative and that you clearly put a lot of work into researching and reporting the issue last month. That IS appreciated and we do hope that you’ll continue to submit any future security issues you find to the Facebook bug bounty program.

I’m not sure why they are not fixing this. Supporting dynamic links in image tags could be a problem and I’m not a big fan of it. I think a manual upload would satisfy the need of users if they want to have dynamically generated image on the notes.
I also see a couple of other problems with this type of abuse:

• A scenario of traffic amplification: when the image is replaced by a pdf or video of larger size, Facebook would crawl a huge file but the user gets nothing.
• Each Note supports 1000+ links and Facebook blocks a user after creating around 100 Notes in a short span. Since there is no captcha for note creation, all of this can be automated and an attacker could easily prepare hundreds of notes using multiple users until the time of attack when all of them is viewed at once.

Although a sustained 400 Mbps could be dangerous, I wanted to test this one last time to see if it can indeed have a larger impact.
Getting rid of the browser and using the poc script I was able to get ~900 Mbps outbound traffic.

I was using an ordinary 13 MB PDF file which was fetched by Facebook 180,000+ times, number of Facebook servers involved was 112.
We can see the traffic graph is almost constant at 895 Mbps. This might be because of the maximum traffic imposed on my VM on the cloud which is using a shared Gbps ethernet port. It seems there is no restriction put on Facebook servers and with so many servers crawling at once we can only imagine how high this traffic can get.
After finding and reporting this issue, I found similar issues with Google which I blogged here. Combining Google and Facebook, it seems we can easily get multiple Gbps of GET Flood.
Facebook crawler shows itself as facebookexternalhit. Right now it seems there is no other choice than to block it in order to avoid this nuisance.
[Update]
https://developers.facebook.com/docs/ApplicationSecurity/ mentions a way to get the list of IP addresses that belongs to Facebook crawler.

whois -h whois.radb.net — ‘-i origin AS32934′ | grep ^route

Blocking the IP addresses could be more effective than blocking the useragent.