Thursday, May 25, 2017

bad request 'limit request headers fields size' opendx microsoft

Some Microsoft sites returns the following HTTP error in Google Chrome only 


Bad Request 

Error parsing headers: 'limit request headers fields size'


Microsoft's OpenDx  learning site returns a Bad Request (May 4th-6th, 2017, May 25, 2017) in Chrome.

https://openedx.microsoft.com/


This is new Microsoft Learning site hosted on Azure (Microsoft's cloud service) using Open edX an open source training platform from Harvard and MIT. 


Explanation



This is caused by a browser initial accessing the page on the server. The server is asking for information in an HTTP request from the browser, usually this is an cookie that in part contains your authorization information. Each time you access the site the cookie is updated and depending on its design, it can grow. If it grows two large then you can get a Bad Request error from the server. If you get this error, then the new cookie information is never set for this domain.


This can also be caused by changes to code in the page setting a new cookie definition, or a change to web server configuration. If web server is being rebuilt nightly, this this could cause this affect the cookie definition, invalidating previous cookies.


Solution


Clear your Chrome cookies with a free tool (see my post on this) for opendx.microsoft.com to verify and delete them. You do not have to clear all your cookies for all sites. 

It seems for the openedx.microsoft.com Chrome is not expiring its cookies properly. 


But the error may persist, depend where you are on the build cycle of this site. 



I will demonstrate that this is not a cookie issue for me. On May 4th, 2017 and May 25, 2017 https://openedx.microsoft.com/ had this error in Chrome. 


I cleared my cookies for opendx.microsoft.com and still I could not get into the site. 

I revisited the page and check the cookies for opendx.microsoft.com and Chrome doesn't even have a chance to set a cookie. 

However in Mozilla Firefox, for the site https://openedx.microsoft.com/ sets a csrftoken cookie, but not in Chrome. 

In this instance, it probably is a server configuration error. Following that lead, I found 
openedx.microsoft.com is running on Nginx server.  Read my post on how to get the server manufacturer using curl for windows, to check this issue for other servers.

Nginx servers have a small default header size, see below. 



In the end, this error will be resolved quickly, usually in the same day, because the site cannot negate Chrome representing 60% of market share for long.


But in the meantime, use Microsoft IE or Mozilla Firefox browser instead, until this is server configuration is fixed.


NGIX Server Hosted Websites cookie issue 


Lately the Bad Request error is occurring many times on Microsoft and Microsoft Affiliated Websites when using Chrome.

One began to suspect that this was a ploy by Microsoft to generate traffic for IE. However, most likely its just poor developer testing.

For sites hosted on NGIX servers, this header buffer size is only 8k. 

Syntax:large_client_header_buffers number size;
Default:
large_client_header_buffers 4 8k;
Context:httpserver
What generally happens is that all the cookies used by your site get combined into one header and that may cause you to go over the default limit which is 8192 bytes.

The solution is to just bump the request limit. You can do this globally or just for your site with the LimitRequestFieldSize directive.

This is a tricky error to catch as it only affects people who have cookies over the allotted capacity. Some of your users might experience issues when their cookie size exceeds 8k or like in my case, some pages that set additional cookie value might push you over the limit.

In the first scenario once the user has cookies that are over the limit they wont be able to use the site any more while other users might access the same pages with no problem while their cookies are under the limit. 

Microsoft Websites hosted on IIS issues

In some instances, when authentication is required by a site using Microsoft Live credentials, Bad Request error was showing up because the site is hosted on Microsoft IIS.

Microsoft Sites and affiliated sites use common infrastructure for their credential store using Microsoft Passport, which lets users authenticate to a Microsoft account, an Active Directory account, a Microsoft Azure Active Directory (AD) account, or non-Microsoft service that supports Fast ID Online (FIDO) authentication.
According to the official the Microsoft definition for Bad Request for IIS Web Server for following reason;  


Kerberos authentication token for the user increases in size. The HTTP request that the user sends to the IIS server contains the Kerberos token in the WWW-Authenticate header, and the header size increases as the number of groups goes up.  If the HTTP header or packet size increases past the limits configured in IIS, IIS may reject the request and send this error as the response.

So if the authentication token is too big, it would cause the Bad Request error. However, this problem peaked about 2 years ago and now has subsided, but mentioned for completeness.

So we are left with the remaining reason; generally no funds or time to do the right testing.


The default Microsoft IIS Web Server Header Limits is 64K, which is quite sufficient, but can break, if integrated systems testing is not part of the project plan



For Microsoft IIS HTTP Server, this limit is set by Header Limits <headerLimits> directive (default 64K). The Header Limits <headerLimits>  directive allows the Web server administrator to reduce or increase the limit on the allowed size of an HTTP request header field. The  element of the  collection contains a collection of elements that specify the maximum size in bytes for HTTP headers. 


Chrome Acceptance Header Size  (not the problem)


Chrome can accept a header size of max 256Kb. 


Actual limit seems to be 256KB for the whole HTTP header. Error message appears: "Error 325 (net::ERR_RESPONSE_HEADERS_TOO_BIG): Unknown error."

Wednesday, May 24, 2017

VLC Player Subtitle Hack Attack

Check Point researchers revealed a new attack vector which threatens millions of users worldwide – attack by subtitles. By crafting malicious subtitle files, which are then downloaded by a victim’s media player, attackers can take complete control over any type of device via vulnerabilities found in many popular streaming platforms, including VLC, Kodi (XBMC), Popcorn-Time and strem.io. This includes Macs, Linux,  Windows and Android set-top TV boxes.

Check Points estimates there are approximately 200 million video players and streamers that currently run the vulnerable software, making this one of the most widespread, easily accessed and zero-resistance vulnerability reported in recent years.

VLC has over 186 million downloads of its version 2.2.4 alone, which was released June 5, 2016. Kodi (XBMC) has reached over 10 million unique users per day, and nearly 40 million unique users each month.





























VLC Hack Description

For VLC players, it uses a ParseJSS Null Skip Subtitle Remote Code Execution hijack.
A remote code execution vulnerability exists in VLC Subtitles mechanism. The vulnerability is due to the way VLC parses subtitle files. Successful exploitation could result in arbitrary code execution on the client machine. In the demo video below we see the subtitles essentially activating a TinyVNC connection with the attackers machine, allowing full access for the desktop. 



Action 



Update VLC media player to latest version Version 2.2.5.1 immediately

Download now.





Platforms affected


Check all platforms affected at and update
http://blog.checkpoint.com/2017/05/23/hacked-in-translation/


Proof-of-Concept video of a remote hacker taking over your desktop


Tuesday, May 23, 2017

What you should do after a Google Docs Phishing attack?


If you got hit by the massive phishing attack on Google Docs that hit the internet on May 3, it takes phishing to a new level because it was coming from known contacts from you email list. It affected millions of users, since it seemed looked like a legitimate view shared document request.

But there were some dead give-aways, such as message going to hhhhhhhhhhhh?

For those who may have been tricked by the attack and clicked on the phishing link, the attacker potentially had access to the victims' Google accounts and contacts.

Google recommends that users visit https://myaccount.google.com/secureaccount and remove any apps they don't recognize.

Remove granted permissions to others, under Check your account permissions



































Also when you are there if you scroll down to the bottom you see that google stores all your passwords to every site you save you passwords with. 


This is unusual since, these passwords generally should stay on your computer, but Google has decided them to put them in the cloud, for your convenience or an easy back door for Google? 


This is an invasion really of your privacy. It's unexpected browser behavior.

Your Save passwords for sites are stored in the Google Cloud!