NoScript 1.9.9.35 - XSS Injection Checker Nested Complexity Bug still persists

Just a few days ago I talked about the complexity issue with the NoScript author and the false positives encountered. I released a document on the below mentioned link:

http://secniche.org/papers/noscript_xss_chk_comp_flaw.pdf

Read it for the issue in action. Soon after that there were some build versions and finally 1.9.9.35 is out. but seems like this complexity issue still persists. This time it worked with more stealthier JavaScript and Injection Checker raises the false positive.

The complex links are from ad.doubleclick.net and are presented below:

http://www.linkedin.com/html/addineyeV2.html?strBanner=gEbServerData%3D%271%3A%3A1225342%3A%3A2272675%3A%3ASite-20936/Type-11/2272675_e0b24616-1ae2-4643-baee-12ebdd7a1647.js%3A%3AExpBanner%3A%3A0%3A%3A%3A%3A%3A%3A0%3A%3A%3A%3A%3A%3A%3A%3A%3A%3A1%3A%3A94684%3A%3A0%3A%3A0%3A%3A%3A%3A%27%3BgEbBannerData%3D%2715264925553351627%3A%3A1%3A%3A300%3A%3A250%3A%3A%3A%3A%3A%3A1%3A%3A0%3A%3A30%3A%3A%3A%3A%3A%3A%3A%3A0%3A%3A0%3A%3Atrue%3A%3A%3A%3Afalse%27%3BgEbInteractions%3D%27%5B_eyeblaster%2Chttp%253A//ad.doubleclick.net/click%253Bh%253Dv8/391c/3/0/*/v%253B221038779%253B0-0%253B11%253B40521440%253B4307-300/250%253B34909454/34927284/1%253Bu%253D18348940%253B%257Eaopt%253D2/0/ff/0%253B%257Esscs%253D%253F%2C%5D%27%3BebSrc%3D%27http%253A//ds.serving-sys.com/BurstingCachedScripts/ebExpBanner_3_0_67.js%27%3BebResourcePath%3D%27http%253A//ds.serving-sys.com/BurstingRes//%27%3B%3BebO%3Dnew%20Object%28%29%3BebO.sms%3D%27ds.serving-sys.com/BurstingScript/%27%3BebO.bs%3D%27bs.serving-sys.com%27%3BebO.fvp%3D%27Res/%27%3BebO.rpv%3D%27_2_5_1%27%3BebO.pv%3D%27_3_0_3%27%3BebO.pi%3D0%3BebO.wv%3D%27_3_0_1%27%3BebPtcl%3D%27http%3 //%27%3BebO.bt%3D2%3BebO.bv%3D3%3BebO.plt%3D8%3BgEbDbgLvl%3D0%3BgnEbLowBWLimit
%3D120%3B]

Another sanitized one:

http://ad.doubleclick.net/adi/linkedin.dart/home_nn;optout=false;lang=en;v=1;u=18348940;ue=1utcdckqzgglwtt4uqu6ap;title=o;title=ic;func=null;co_id=233588;co_id=376101;co_id=3027;co_id=60837;ind=96;ind=82;ind=121;ind=118;csize=d;csize=a;csize=h;csize=c;csize_num=1;csize_num=50;csize_num=7000;zip=110005;gdr=u;cntry=sg;reg=0;grp=3120;grp=54384;grp=113049;grp=115855;grp=742197;grp=894157;grp=1485107;grp=1613377;grp=1777141;grp=1805569;grp=1848637;edu=13494-2008;jobs=1;sub=0;con=j;age=a;age_num=24;seg=190;seg=218;tile=2;sz=300x250;extra%3Dnull;ord=41888994?]. Sanitized URL: [http://www.linkedin.com/html/addineyeV2.html?strBanner=gEbServerData%20%201%3A%3A1225342%3A%3A2272675%3A%3ASite-20936%2FType-11%2F2272675_e0b24616-1ae2-4643-baee-12ebdd7a1647.js%3A%3AExpBanner%3A%3A0%3A%3A%3A%3A%3A%3A0%3A%3A%3A%3A%3A%3A%3A%3A%3A%3A1%3A%3A94684%3A%3A0%3A%3A0%3A%3A%3A%3A%20%3BgEbBannerData%20%2015264925553351627%3A%3A1%3A%3A300%3A%3A250%3A%3A%3A%3A%3A%3A1%3A%3A0%3A%3A30%3A%3A%3A%3A%3A%3A%3A%3A0%3A%3A0%3A%3Atrue%3A%3A%3A%3Afalse%20%3BgEbInteractions%20%20%20_eyeblaster%2Chttp%253A%2F%2Fad.doubleclick.net%2Fclick%253Bh%253Dv8%2F391c%2F3%2F0%2F*%2Fv%253B221038779
%253B0-0%253B11%253B40521440%253B4307-300%2F250%253B34909454%2F34927284%2F1%253Bu%25
3D18348940%253B%257Eaopt%253D2%2F0%2Fff%2F0%253B%257Esscs%253D%253F%2C%20%20%3BebSrc%20%20http%253A%2F%2Fds.serving-sys.com%2FBurstingCachedScripts%2FebExpBanner_3_0_67.js%20%3BebResourcePath%20%20http%253A%2F%2Fds.serving-sys.com%2FBurstingRes%2F%2F%20%3B%3BebO%20new%20Object%20%20%3BebO.sms%20%20ds.serving-sys.com%2FBurstingScript%2F%20%3BebO.bs%20%20bs.serving-sys.com%20%3BebO.fvp%20%20Res%2F%20%3BebO.rpv%20%20_2_5_1%20%3BebO.pv%20%20_3_0_3%20%3BebO.pi%200%3BebO.wv%20%20_3_0_1%20%3BebPtcl%20%20http%3A%2F%2F%20%3BebO.bt%202%3BebO.bv%203%3BebO.plt%208%3BgEbDbgLvl%200%3BgnEbLowBWLimit%20120%3B#
20340333708575276684].

On further discussion with NoScript author the complexity in this issue is more versatile due to the presence of JavaScript in a more stealthier manner. It looks like as

gEbServerData = "1::1225342::2272675::Site-20936/Type-11/2272675_e0b24616-1ae2-4643-baee-12ebdd7a1647.js::ExpBanner::0::::::0::::::::::1::94684::0::0::::";
gEbBannerData = "15264925553351627::1::300::250::::::1::0::30::::::::0::0::true::::false";
gEbInteractions = "[_eyeblaster,http%3A//ad.doubleclick.net/click%3Bh%3Dv8/391c/3/0/*/v%3B221038779%3B0-0%3B11%3B40521440%3B4307-300/250%3B34909454/34927284/1%3Bu%3D18348940%3B%7Eaopt%3D2/0/ff/0%3B%7Esscs%3D%3F,]";
ebSrc = "http%3A//ds.serving-sys.com/BurstingCachedScripts/ebExpBanner_3_0_67.js";
ebResourcePath = "http%3A//ds.serving-sys.com/BurstingRes//";
ebO = new Object;
ebO.sms = "ds.serving-sys.com/BurstingScript/";
ebO.bs = "bs.serving-sys.com";
ebO.fvp = "Res/";
ebO.rpv = "_2_5_1";
ebO.pv = "_3_0_3";
ebO.pi = 0;
ebO.wv = "_3_0_1";
ebPtcl = "http://";
ebO.bt = 2;
ebO.bv = 3;
ebO.plt = 8;
gEbDbgLvl = 0;
gnEbLowBWLimit = 120;

The author seems like not interested in this layout because the scripts can not be allowed in this complex part. This means False Positive persists in the NoScript XSS Injection Checker. You are going to accompany it as:



This can lead to ambiguity whether there is a XSS attempt in real or not and can impact the user experience to some extent. All on users acceptance.

Google Chrome 3.0.195.38 | Chrome Frame - Reloading Memory Allocation based Tab Crashing

Google Chrome, right from the start has shown some stringency in tab crashing. But crashing tabs or full browser crash is becoming more smoother than the previously reported cases. On playing around with Google Chrome and Chrome Frame direct tab crashing has been reloaded. The specific points are mentioned below:

1. Scripts are checked against memory allocation part and raises a warning.
2. In recent versions playing around with JavaScript based conversion of Unicode
values to characters and rendering it directly leads to tab crashing.
3. It has become more smoother and direct in the functionality.

The software tested against this rule set is mentioned below:

1. Google Chrome Browser
2. Google Chrome Frame. (IE8)

Both are installed on x64 systems running windows vista and IE8. The test is based on the script code designed to show the tab crashing in controlled manner.

Video :- Google Chrome 3.0.195.38 | Chrome Frame - Reloading Memory Allocation based Tab Crashing

IE8 directly raises a warning as:



IE8 functionality is hampered. The crash produces a register state as mentioned below:

EAX 00000000
ECX 3F800000
EDX 00000005
EBX 1FC00000
ESP 013DED00
EBP 013DED1C
ESI 0FDFFFF7
EDI 00CDEA00
EIP 6A28FCAA chrome_1.6A28FCAA
C 0 ES 002B 32bit 0(FFFFFFFF)
P 1 CS 0023 32bit 0(FFFFFFFF)
A 0 SS 002B 32bit 0(FFFFFFFF)
Z 1 DS 002B 32bit 0(FFFFFFFF)
S 0 FS 0053 32bit 7EFDA000(FFF)
T 0 GS 002B 32bit 0(FFFFFFFF)
D 0
O 0 LastErr ERROR_NOT_ENOUGH_MEMORY (00000008)
EFL 00000246 (NO,NB,E,BE,NS,PE,GE,LE)
ST0 empty 0.0
ST1 empty 0.0
ST2 empty 236.00000000000000000
ST3 empty 0.0
ST4 empty 0.0
ST5 empty 1000.000000000000000
ST6 empty 309683.00000000000000
ST7 empty 0.0747806972940452397
3 2 1 0 E S P U O Z D I
FST 0020 Cond 0 0 0 0 Err 0 0 1 0 0 0 0 0 (GT)
FCW 027F Prec NEAR,53 Mask 1 1 1 1 1 1

The issue presented in this post shows the advancement in execution of scripts and silently crashing the tabs. This issue has been designed as a controlled layout for showing the possibilities of crashing in Chrome.

Note: This is designed for educational purposes and improving the functionality of open source software.

Link Injection Redirection Attacks - Exploiting URL Pattern in Google Chrome - Browser Design Failure

Update: As pointed by Google in the below mentioned link that issues was not reported previously.

http://www.webappsec.org/lists/websecurity/archive/2010-01/msg00022.html

We strictly believe in responsible disclosures. It was reported on 28 November 2008 and the status was changed to "Wont Fix" by the team itself. You can have a look at:

http://code.google.com/p/chromium/issues/detail?id=4739



Recently with an outcome of Owasp RC1 top 10 exploited vulnerability list , redirection issues have already made a mark in that. Even the WASC has included the URL abusing as one of the stringent attacks.



Well to be ethical in this regard these are not the recent attacks but are persisting from long time. The only difference is the exploitation ratio has increased from bottom to top. So that's the prime reason it has been included in the web application security benchmarks. But the projection of redirection attacks is active now.

This post is not about explaining the basics of redirection issues. It is more about the design vulnerabilities in browsers that can lead to potential persistent redirection vulnerabilities. We will implement this attack as an example scenario against the long persisted vulnerability in Google Chrome released long back by Secniche Security. The details of this vulnerability can be found at below mentioned links:

1. Google Chrome URL Obfuscation Vulnerability.
2. Milw0rm Database
3. Securityfocus

The issue has been notified to Google Chrome Security team many times but it is still persisting and can be effectively exploited. Considering other browsers such as Mozilla , IE8 below mentioned restrictions have already been implemented as:

1. Mozilla has implemented an alert check when ever rogue link is clicked informing the user for the malicious operation in process.

2. IE8 has completely changed the link interpretation behavior.

The attack scenario - (Web Application Security Testing)

1. A vulnerable website prone to redirection.
2. Browser vulnerability in interpreting injected links: Google Chrome

The video can be seen here:

Link Injection Redirection Attack - Exploiting Google Chrome Design Flaw

Regards

Design Inaccuracy - Cross Link Authoring Flaw - Scribd Flaw - iPaper Platform

This paper sheds light on the technique of bypassing the iPaper platform for launching a number of web attacks. This iPaper platform is a new document format that is used for online document viewing and is comparatively easy to manage. It is used by a large number of websites. The best example is the Scribd network which hosts a large number of documents online. Extensive testing shows that this platform is vulnerable to a number of web attacks.

Read the paper at : Whitepaper

NoScript XSS Injection Checker Unescaping Nested URL Stringency - False Positive

The NoScript has shown some stringent false positive in dealing with complex URL pattern and escaping it appropriately. Please check the document:

Fetch the Doc

For effective development of community based software.

Yahoo Babelfish - SYSTRAN Base - Is that a Culprit? Well Let's See The WorkOut.

The frame injection flaw discussed previously has a lot of impacts and can be exploited in the wild in a diversified manner. Primarily, the two basic checks are missing in the applied online translation strategy opted by the Yahoo Babelfish and Systran. The Systran is the base software used by yahoo for translating contents online. The application is desktop based. On scrutinizing the Systran service, the design looks similar that is used by the Yahoo Babelfish.

For a good design implementation in translation server, one should consider following factors:

1. Privacy statement or content verification notification should be mentioned in the base message bar.

2. The translation source and destination should be mentioned.

3. Its a good solution to randomize the source URL and appends a differential URLID parameter that cannot be guessed.

The third solution is quite good because direct reference cannot be made and source check is maintained when a malicious translation request is issued.

Both these adequate steps are missing in Yahoo Babelfish and Systran. Microsoft, in this case has a upper hand by deploying these notifications. At least a user is always aware of fact that the content should not be considered as trusted. The prototype looks like as presented below:



While loading the Yahoomail URL for translation, the server gives the error as shown below:



 It is noticed that Systran online translation engine fetches the URL pattern as mentioned below:

http://sysurl.systranet.com/?systrangui=www.systran.co.uk%3B/snetcom/web&systranbanner=1&systranuid=aHR0cC13d3cueWFob28uY29tL2VuX2Zy

The first two notifications as discussed above are not followed. But yes, to some extent he URL randomization point is applied. I am not saying that it is an appropriate solution but, if every time a new ID is being provided, it can be considered as a good solution. Of course it is.