[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [WEB SECURITY] Detecting, Analyzing, and Exploiting Intranet Applications using JavaScript

--------------070302040500060009030003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Billy Hoffman wrote:
>
> Folks,
>
>  
>
> SPI Labs has discovered a technique to scan a network, fingerprint all 
> the web-enabled devices it finds, and send attacks or commands to 
> those devices. This technique can scan networks protected behind 
> firewalls such as corporate networks. All the code to do this is 
> written in JavaScript and uses parts of the standard that are almost 
> 10 years old. Accordingly, the code can execute in nearly any web 
> browser on nearly any platform when a user simply opens at a webpage 
> that contains the JavaScript. Since this is not exploiting any browser 
> bug or vulnerability, there is no patch or defense for the end user 
> other than turning off JavaScript support in the browser. The code can 
> be part of a Cross Site Scripting (XSS) attack payload, increasing the 
> damage XSS can do.
>
>  
>
> SPI has published a whitepaper about this technique and has also 
> release proof  of concept code that will portscan a given range of 
> IP's and fingerprint Microsoft IIS and Apache boxes.
>
>  
>
> Whitepaper: 
> http://www.spidynamics.com/spilabs/education/articles/JS-portscan.html
>
> Proof of Concept: http://www.spidynamics.com/spilabs/js-port-scan/
>
>  
>
> Have fun,
>
> Billy Hoffman
>
> --
>
> Lead R&D Engineer
>
> SPI Dynamics -- http://www.spidynamics.com <http://www.spidynamics.com/>
>
> Phone: 678-781-4800
>
> Direct: 678-781-4845
>

Billy's presentation at Blackhat this morning was very good.  Ideas like 
the client uniquely identifying XMHttpRequests need more discussion.  I 
also wanted to point people at the Discussion Brendan Eich started this 
morning on the dev-platform@lists.mozilla.org (also News: 
mozilla.dev.platform <news://news.mozilla.org/mozilla.dev.platform>) to 
discuss things that can be done in the browser to improve the javascript 
security model moving forward into the future...

Here is his post to kick off some discussion:

Subject: Semi-formally specifying the JavaScript security model

It would be a good thing, wouldn't it?

For over a decade, the browser security model has been evolving in
spurts between periods of deathly stillness.  The rules have stabilized
for same-origin sandboxing, at least for common DOM APIs.  But a great
deal of the DOM was never standardized, including the whole of "Level
0" including window objects.  XHR's infamous same-origin restriction
gives people fits and drives them to take chances with script src='s
hazards.

In general, security mechanism and policy were never defined or agreed
upon using an open standardization process, so browser implementors
have had to reverse-engineer, read open source, and chase after XSS
bugs to achieve both interoperation and safety -- which may be at odds.

Moreover, for Mozilla with chrome and content windows, and XUL apps and
extensions built using chrome, we have a non-standard model.  It's more
powerful and (of course) more vulnerable.  It was unsound without
XPCNativeWrappers, from the get-go.  Even with wrappers it seems
unsound to me.

Then there is GreaseMonkey, which also mixes trust labels within the
same sandbox, a risky proposition.  We clearly need more degrees of
sandboxing than "runs as you" and "runs as a crippled mid-90s web app's
window-bound JS".

A lot of great research work has been done over the years, especially
in the last ten years, yielding results such as information flow type
systems and data-tainting compiler/virtual-machine combos that can
uphold important security properties such as confidentiality (no send
on socket after secret read from filesystem, e.g.), while allowing
useful browser-based computation and user interaction including
sanitization.

We are poised to benefit from this work.  But if we keep wasting time
patching an unsound system, we will die the death of a thousand cuts.
We need to specify the system and then move our code to match the spec.

So I thought to write down some kind of semi-formal set of definitions
and rules, from which inductive or other proofs could be done.

This is hard, and it wants to turn into some kind of operational
semantics.  The first rough cut is at
http://wiki.mozilla.org/Security:Strawman_Model.  Comments and
questions welcome.  I have had fruitful exchanges with bz over IRC, cut
short by our other work.  It would be great to recap them here and
build on them.

/be





--------------070302040500060009030003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Billy Hoffman wrote:
<blockquote
 cite="midF71BB5B89FB0384290F8085CFB84061E01642B78@mcbain.spidynamics.com"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="Microsoft Word 11 (filtered medium)">
  <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin:0in;
	margin-bottom:.0001pt;
	line-height:20.0pt;
	font-size:11.0pt;
	font-family:Verdana;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
span.BodyTextChar
	{font-family:Verdana;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
  </style>
  <div class="Section1">
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Folks,<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">SPI Labs has discovered a
technique to scan a network,
fingerprint all the web-enabled devices it finds, and send attacks or
commands
to those devices. This technique can scan networks protected behind
firewalls such
as corporate networks. All the code to do this is written in JavaScript
and
uses parts of the standard that are almost 10 years old. Accordingly,
the code
can execute in nearly any web browser on nearly any platform when a
user simply
opens at a webpage that contains the JavaScript. Since this is not
exploiting
any browser bug or vulnerability, there is no patch or defense for the
end user
other than turning off JavaScript support in the browser. The code can
be part
of a Cross Site Scripting (XSS) attack payload, increasing the damage
XSS can
do.<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">SPI has published a
whitepaper about this technique and has
also release proof &nbsp;of concept code that will portscan a given range of
IP&#8217;s
and fingerprint Microsoft IIS and Apache boxes.<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Whitepaper: <a
 href="http://www.spidynamics.com/spilabs/education/articles/JS-portscan.html";>http://www.spidynamics.com/spilabs/education/articles/JS-portscan.html</a><o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Proof of Concept: <a
 href="http://www.spidynamics.com/spilabs/js-port-scan/";>http://www.spidynamics.com/spilabs/js-port-scan/</a><o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;"><o:p>&nbsp;</o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Have fun,<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Billy Hoffman<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">--<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Lead R&amp;D Engineer<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">SPI Dynamics &#8211; <a
 href="http://www.spidynamics.com/";>http://www.spidynamics.com</a><o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Phone: 678-781-4800<o:p></o:p></span></font></p>
  <p class="MsoNormal"><font face="Arial" size="2"><span
 style="font-size: 10pt; font-family: Arial;">Direct: 678-781-4845<o:p></o:p></span></font></p>
  </div>
</blockquote>
<br>
Billy's presentation at Blackhat this morning was very good.&nbsp; Ideas
like the client uniquely identifying XMHttpRequests need more
discussion.&nbsp; I also wanted to point people at the Discussion Brendan
Eich started this morning on the <a class="moz-txt-link-abbreviated" href="mailto:dev-platform@lists.mozilla.org";>dev-platform@lists.mozilla.org</a> (also
News: <a href="news://news.mozilla.org/mozilla.dev.platform";>mozilla.dev.platform</a>)
to discuss things that can be done in the browser to improve the
javascript security model moving forward into the future...<br>
<br>
Here is his post to kick off some discussion:<br>
<br>
Subject: Semi-formally specifying the JavaScript security model<br>
<pre wrap="">It would be a good thing, wouldn't it?

For over a decade, the browser security model has been evolving in
spurts between periods of deathly stillness.  The rules have stabilized
for same-origin sandboxing, at least for common DOM APIs.  But a great
deal of the DOM was never standardized, including the whole of "Level
0" including window objects.  XHR's infamous same-origin restriction
gives people fits and drives them to take chances with script src='s
hazards.

In general, security mechanism and policy were never defined or agreed
upon using an open standardization process, so browser implementors
have had to reverse-engineer, read open source, and chase after XSS
bugs to achieve both interoperation and safety -- which may be at odds.

Moreover, for Mozilla with chrome and content windows, and XUL apps and
extensions built using chrome, we have a non-standard model.  It's more
powerful and (of course) more vulnerable.  It was unsound without
XPCNativeWrappers, from the get-go.  Even with wrappers it seems
unsound to me.

Then there is GreaseMonkey, which also mixes trust labels within the
same sandbox, a risky proposition.  We clearly need more degrees of
sandboxing than "runs as you" and "runs as a crippled mid-90s web app's
window-bound JS".

A lot of great research work has been done over the years, especially
in the last ten years, yielding results such as information flow type
systems and data-tainting compiler/virtual-machine combos that can
uphold important security properties such as confidentiality (no send
on socket after secret read from filesystem, e.g.), while allowing
useful browser-based computation and user interaction including
sanitization.

We are poised to benefit from this work.  But if we keep wasting time
patching an unsound system, we will die the death of a thousand cuts.
We need to specify the system and then move our code to match the spec.

So I thought to write down some kind of semi-formal set of definitions
and rules, from which inductive or other proofs could be done.

This is hard, and it wants to turn into some kind of operational
semantics.  The first rough cut is at
<a class="moz-txt-link-freetext"
 href="http://wiki.mozilla.org/Security:Strawman_Model";>http://wiki.mozilla.org/Security:Strawman_Model</a>.  Comments and
questions welcome.  I have had fruitful exchanges with bz over IRC, cut
short by our other work.  It would be great to recap them here and
build on them.

/be
</pre>
<br>
<br>
<br>
</body>
</html>

--------------070302040500060009030003--
Brought to you by http://www.webappsec.org
Search this site