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, 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 normally caused by having a very large Cookie being used that exceeds the limit set for the Web Server, serving the page.

In other words the developer of site created a very large Cookie, without testing this properly on the Web Server that website is running on. This is known as edge testing and can be part of IST (Integration System Testing). 


This could be the downside of DevOps, where a developer container really has not been vetted for production.


Solution


This is not a cookie issue. As of May 4th, 2017 and May 25, 2017 https://openedx.microsoft.com/ had this error in Chrome. Chrome doesn't even have a chance to set a cookie. 

You can check this using this my post on "
This site can't be reached", to examine and clear multiple cookies by domain. For  most sites clear you cookies for that domain will do the trick. 

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


https://openedx.microsoft.com/ is running on Nginx server.  Read my post on how to get the server manufacturer using curl for windows.

This error will be resolved quickly, because the site cannot negate Chrome representing 60% of market share for long.


User Microsoft IE or Mozilla Firefox browser instead.



Why NGIX Server Hosted Websites? 


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.


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. 

Why Microsoft Websites?

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

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!