HITB Magazine: MS Office Infection Paper

A new paper has been released in the HITB magazine about infection styles in MS Office files. It projects a pattern of infection used by chinese malware.

Fetch:http://magazine.hackinthebox.org/issues/HITB-Ezine-Issue-003.pdf

Credentials Verification- Security Emails Phishing and Trust Manipulation

Phishing attacks based on trust exploitation are on rise. Banks are facing tremendous complexities and security issues due to these type of attacks. The primary focus of this sort of attack is to trick user’s sense of understanding and
segregating the trust to perform operations of attacker's choice. The case studies discussed in this article sheds light on phishing attacks that exploit users' trust with the third-party. Credit card forgeries are quite common considering the bank phishing frauds. The primary artifact of the attackers is to play with the user trust and to manipulate user thinking process by raising a complexity through spams. The user inability to distinguish between the trusted website and attacker controlled website, which is a replica of the original website, results in forged transactions.

Recently HSBC, Paypal security phishing emails are used to steal the credentials of users. The phished email carry online form as an attachment which looks similar to the original HSBC bank forms for updating the credentials of the user.

Case 1 - Paypal Verification Credentials Theft

The email is sent by phisher on the behalf of Paypal verification group for re-verifying your credentials. The email looks like as



During analysis the attachment is downloaded in a restrictive environment to scrutinize against malware, infection handlers etc.



Luckily the form page does not contain malware but the form is posted to a attacker controlled domain (http://probe.201w.com/verification.php) for verification as:



On further analyzing the domain, we came across the fact that some of the users have fallen into this trap as:



The users inability to distinguish between the trust boundaries lead to compromises and information stealing.

Case 2: HSBC Verification Credentials Stealing



We performed simple analysis in controlled environment. The form looked like as



The form itself does not contain any sort of malware but the form is posted to the malicious domain (http://www.thebluzmen.com/verify.php) for verification as




A normal user should be aware of the artifacts used by the phishers to betray the trust.

Papers Published - HITB EZine and Hakin9

We have just published new papers in Hack in the Box EZine and Hakin9. The magazines are free and can be fetched from below mentioned links:

1. Open Redirect Wreck Off - HITB EZine
The paper talks about the real time scenarios analyzed while conducting security assessments of different websites. It has been detected that these websites are prone to invalidated redirects and forward issues. Recently, with the release of OWASP 2010 RC1 release, A8 has been marked against the redirection based flaws in websites. The
attacker can control the user’s trust behavior to visit the website which is malicious and controlled by the untrusted party

http://www.hackinthebox.org/misc/HITB-Ezine-Issue-002.pdf


2. Pwning Embedded ADSL Routers - Inside LAN | Hakin9
The paper is restricted to not only testing but also discusses the kinds of software
and firmware used and incessant vulnerabilities that should be scrutinized while
setting up a local network. A detailed discussion will be undertaken about the HTTP servers used for handling authentication procedure and access to firmware image providing functionalities to design and configure your own home local area network.

http://download.hakin9.org/en/hakin9_04_2010_EN.pdf

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.

Google Chrome/ WebKit - MSWord Scripting Object XSS Payload Execution Bug and Random CLSID Stringency

Google Chrome (including customized webkit)has shown unethical behavior in implementing an embedded object with CLSID parameter. The design bug is presented in the execution of the object element directly in the context of browser. The bug proliferates when a CLSID of certain object is passed and specific URL is allowed to execute as parameter value in it. Before jumping into all aspect of this unexpected and chaotic behavior , let's have a brief look at the W3 specification

!ELEMENT OBJECT - - (PARAM | %flow;)*
-- generic embedded object -->
!ATTLIST OBJECT
%attrs; -- %coreattrs, %i18n, %events --
declare (declare) #IMPLIED -- declare but don't instantiate flag --
classid %URI; #IMPLIED -- identifies an implementation --
codebase %URI; #IMPLIED -- base URI for classid, data, archive--
data %URI; #IMPLIED -- reference to object's data --
type %ContentType; #IMPLIED -- content type for data --
codetype %ContentType; #IMPLIED -- content type for code --
archive CDATA #IMPLIED -- space-separated list of URIs --
standby %Text; #IMPLIED -- message to show while loading --
height %Length; #IMPLIED -- override height --
width %Length; #IMPLIED -- override width --
usemap %URI; #IMPLIED -- use client-side image map --
name CDATA #IMPLIED -- submit as part of form --
tabindex NUMBER #IMPLIED -- position in tabbing order --


classid = uri [CT]
This attribute may be used to specify the location of an object's implementation via a URI. It may be used together with, or as an alternative to the data attribute, depending on the type of object involved.

data = uri [CT]
This attribute may be used to specify the location of the object's data, for instance image data for objects defining images, or more generally, a serialized form of an object which can be used to recreate it. If given as a relative URI, it should be interpreted relative to the codebase attribute.

So as per the recommendations codebase matters a lot. The value should work according to the included object which is known by the CLSID. That's true in the implementation of CLSID parameter through embedded object.

The code that executes positively is mentioned below:
[OBJECT classid=clsid:ae24fdae-03c6-11d1-8b76-0080c744f389>
[param name=url
value=javascript:alert('XSSXSSXSXSXSXSXSXSXSXSXSXSSXSXSXSSXSXXSSS')]
[/OBJECT]

Certain facts are mentioned below

1. The CLSID parameter presented in this part is of MSWORD Scripting Object. The good part is that this code does not get executed in the Internet Explorer 8 and there is no XSS payload execution.

2. All the other browsers such as Mozilla Firefox , Opera and Safari does not execute
this set of payload too. The Safari, which also implements webkit at prime scale does not show any contradictory behavior in this regard.

3. If we talk about HTML5 specification , this is completely unethical in saying that the Google Chrome implements HTML5 then this kind of behavior is accepted. In concern to that latest version of Safari 4 also implements HTML5 specification to a great extent but this execution behavior is not supported.

The contradiction arises as:

1. Google Chrome, itself based on the Webkit and to best of the knowledge , Active X is not supported by the Webkit and Linux platforms. Its a pure windows object class identifiers.

"ActiveX is only supported by Internet Explorer (and browsers built on top of Internet Explorer) on Windows. Google Chrome, Mozilla Firefox, Apple Safari, and others do not support ActiveX. Instead, these browsers make use of the Netscape Plugin Application Programming Interface (NPAPI)."

More:http://www.google.com/chrome/intl/en/webmasters-faq.html#activex

But the general functionality of DOM object execution is based on top to bottom approach i.e tree notation. Primarily the element at the top executes first and then so on.

2. Google Chrome executes the payload in a same manner( which can be used for XSS extensively) with or without the CLSID parameter. This is contradictory in its own sense. One cannot say in any specific nature of browsers that XSS payload execution with or without the CLSID is the same. Its not the appropriate functional part. As the code base point is mentioned in the W3 specification. The URI points to the object location. Ofcourse!

Note: If the browser base is not supporting any type of specific tag attributes the inline code present in it should not be executed. One cannot say that the browser does not recognize the CLSID and it passes the control to the inline object parameter and executed the URI which is completely against the part as the URI is itself defined for that object.

On the second part code execution without the CLSID is generic , in no way it is similar the payload execution with CLSID.

The overall picture of this kind of issue with respect to other browsers is presented below



This represents the overall scenario. The payload can be used to execute XSS attacks stringently. the best probable solution is not to allow code when executed with CLSID as presented in this talk.

On a simpler talk with Google Chrome team about this against the turf behavior there are certain responses which are unacceptable in any case: Have a look

"There is a special case for the "data", "movie" and "src" attributes: http://svn.webkit.org/repository/webkit/trunk/WebCore/html/HTMLParamElement.cpp in "isURLAttribute" and "addSubresourceAttributeURLs".

I expect this has to do with our DNS prefetching; we attempt to start downloading
stuff as soon as we know about it. It may be that Chrome special cases this type of
PARAM, expecting it to be a URL. When it finds out there is nothing to grab off the
internet, it is handled like any other URL and the javascript is executed. The code
may need a bit of tweaking to prevent it from executing javascript; it should only
start download the resource if it contains a valid URL."

"The DNS preresolution would, at the most, do a resolution of a domain, but would never trigger any content fetch or JS execution.

There is also some scanning of content, and pre-fetching expected content. I'd be VERY surprised to hear that it leads to execution prior to such necessity."

"I am actually really curious as to why Chrome is behaving this way, even for unknown clsids. I am guessing it is some sort of a heuristic prefetching mechanism that triggers on parameters named "url"?

If my guess is correct, it would be good to have a peek at this mechanism, and limit
it to http / https, just so that it does not introduce problems elsewhere. That said, I do not see any obvious way how the current behavior would have a negative impact on common web sites - i.e., why we should treat it as a security problem."


"I agree with previous assessment that this is not a particular security issue.I also agree that it would be good to understand the behaviour. Hence: It looks to be WebKit simply passing plugin payload URLs to the frame loader, verbatim.This simply means that in Chrome, the following two URLs constructs behave similarly:

1)[object][param name="url" value="javascript:alert(document.domain)">
[/object]

2)[iframe src="javascript:alert(document.domain)"][/iframe]And obviously, it is any given website's responsibility to NOT pass arbitrary attacker-supplied URLs in either of those attributes."

This statement "it is any given website's responsibility to NOT pass arbitrary attacker-supplied URLs in either of those attributes." is completely obscure with
respect to this bug.

Security Concern: The differential set of payloads always favor the XSS execution and browser inabilities to follow the standard benchmarks.

The result is nothing and no output is on the way. The more stress is not to consider it as a security bug rather finding the real obscurity in it but one can enjoy with this part.

It is seriously out of the way.

Cheers.

Google Sites Privacy Chaos - Is it unthical or Is this the way it has to be? A Talk!

Google sites provide services to the users for hosting their websites on Google's domain. I was going through the privacy column of this website and a stringent issue regrading content policy came in front of me. The policy is presented below:



There is an excerpt in this privacy policy of Google Sites

You may permanently delete any content you create in Google Sites. Because of the way we maintain this service, residual copies of your files and other information associated with your account may remain on our servers for three weeks.


http://www.google.com/sites/privacy.html

This is completely not true. The policy point is quite okay but considering the real time functionality this policy is not applicable. The time period for residual copies is set for three weeks , I suppose not more than a month. I personally tested the stuff six months back. I have noticed even after six months , the deleted file (a PDF file which I do not want anybody to look into) is still recoverable from the Google site , a quite unacceptable fact. According to the policy, the deleted content should not reside on Google's server for more than three weeks.
Let's see:



So there is an ambiguity in the applied policy of Google sites. Is the policy being implemented in right way?

Ofcourse , Google owns web!

Google Translate - Google User Content - File Uploading Cross - XSS and Design Stringency - A Talk

Google translate services provide an efficient way of translating content. The web is a playground for attackers and everyday new bug or flaw is detected in the web services provided by major giants. An interesting concept is to dissect the web based design of websites handling user generated content. On discussion with Google about this problem , the issues is treated as design by default.

The problem (or web bug) persists in the file uploading feature on Google translate website Malicious content such as XSS payload , Iframe, etc. gets executed and rendered into the context of the running website. On discussion with Google it was stated that:

"With JavaScript is executed on the translate.googleusercontent.com domain,rather than translate.google.com. This is by design as files uploaded to the translate service are regarded as untrusted content."

There are two features provided by Google translate service which are mentioned below
1. Translation through file uploading.
2. Direct translation of content online.



Question: Why users consider translation services as secure? What If somebody is doing some monetary transaction or some other issues like that?

The question and answer in itself is hard to answer. But one thing is sure for any critical work, the translate services should not be used.

Let's have a look at the attack point:

Step 1: Uploading a malicious content file through Google Translate service



Step 2: Executing Content



Another layout



Looking at the different domains

1. translate.google.com

Name: www3.l.google.com
Addresses: 209.85.231.102
209.85.231.100
209.85.231.101
Aliases: translate.google.com

2. translate.googleusercontent.com

Name: googlehosted.l.google.com
Address: 209.85.231.132
Aliases: translate.googleusercontent.com

Both the google.com and googleusercontent.com serves the same google search functionality. The specific user content server can be used for differential purposes because content on it is not trusted.

Looking for the different perspective.It would be great if a small message is being displayed on the Google translate service bar as mentioned below

"Google does not assure the integrity of the source of the content"

After considering this as a notification, I checked the Bing translation which already have applied this notification message. Great.




May be its not a solution but a good step in visualizing your concern about content is a better design practice.

Note: a previously reported phishing vulnerability in Google translation was patched and a check was introduced by Google on the source and destination translation languages.