Attacking with HTML5.pdf

(757 KB) Pobierz
 
 
 
Attacking with HTML5
 
By, 
Lavakumar Kuppan 
www.andlabs.org  
October 18, 2010 
 
 
 
 
 
Attacking with HTML5
Introduction: 
HTML5 is redefining the ground rules for future Web Applications by providing a rich set of 
new  features  and  by  extending  existing  features  and  APIs.  HTML5  Security  is  still  an 
unexplored region because HTML5 features are not yet adopted by web applications (apart 
from  experimental  support)  and  it  is  assumed  that  until  that  happens  the  end  users  have 
nothing to worry about. 
This paper would prove this assumption wrong by discussing a range of attacks that can be 
carried  out  on  web  users  ‘right  now’  even  on  websites  that  do  not  support  or  intend  to 
support HTML5 in the near future. Browser vendors have been trying to outdo each other in 
supporting  the  latest  features  defined  in  the  HTML5  spec.  This  has  exposed  the  users  of 
these browsers to the attacks that would be discussed in this paper. 
The initial sections of this paper cover attacks and research that have been published by me 
and other researchers earlier this year. The latter sections covers attacks that are completely 
new and exclusive. 
The list of attacks covered: 
1) Cross‐site Scripting via HTML5 
2) Reverse Web Shells with COR 
3) Clickjacking via HTML5 
a. Text‐field Injection 
b. IFRAME Sandboxing 
4) HTML5 Cache Poisoning 
5) Client‐side RFI 
6) Cross‐site Posting 
7) Network Reconnaissance 
a. Port Scanning 
b. Network Scanning 
c. Guessing user’s Private IP 
8) HTML5 Botnets 
a. Botnet creation 
i. Reaching out to victims 
ii. Extending execution life‐time 
b. Botnets based attacks 
i. DDoS attacks 
ii. Email spam 
iii. Distributed Password Cracking 
 
 
© Attack & Defense Labs, http://www.andlabs.org  
 
 
Attacking with HTML5
Cross‐site Scripting via HTML5: 
HTML5 introduces new elements that contain event attributes and new event attributes for 
existing  tags.  These  event  attributes  can  be  used  for  executing  JavaScript  by  bypassing 
blacklist based filters designed blocking Cross‐site Scripting attacks.  
A  filter  that  only  looks  for  known  malicious  tags  can  be  bypassed  using  the  new  HTML5 
Audio and Video tags. 
Example: 
<video onerror=ʺjavascript:alert(1)ʺ><source> 
<audio onerror=ʺjavascript:alert(1)ʺ><source> 
 
Filters  that  block  ‘<’  and  ‘>’  can  prevent  tag  injection  in  most  cases.  XSS  could  still  be 
possible in such cases if the attacker is able to inject script inside an existing event attribute 
or add a new event attribute. A filter that blocks existing event attributes can be bypassed by 
the new event attributes added in HTML5 like ‘onforminput’ and ‘onformchange’.  
 
Example: 
<form 
id=test 
onforminput=alert(1)> 
<input> 
</form> 
<button 
form=test 
onformchange=alert(2)>X 
Apart  from  aiding  in  bypassing  filters  some  new  features  can  be  used  to  automate  script 
execution  like  the  HTML5  ‘autofocus’  attribute.  When  this  attribute  is  set  an  element 
automatically gets focus. 
Cases where data injection is possible inside the attribute section of an Input tag is common. 
In such cases traditionally the injected JavaScript would be placed inside the ‘onmouseover’ 
or ‘onclick’  tag and user interaction would be  required to execute the script. With HTML5 
the ‘onfocus’ tag can be used for injecting script and then by setting the autofocus attribute 
we can trigger the script execution automatically. 
Example: 
Before HTML5: 
 <input type=ʺtextʺ value=ʺ‐‐>Injecting hereʺ onmouseover=ʺalert(ʹInjected valueʹ)ʺ> 
With HTML5: 
<input type=ʺtextʺ value=ʺ‐‐>Injecting hereʺ onfocus=ʺalert(ʹInjected valueʹ)ʺ autofocus> 
Mario  Heiderich  maintains  a  list  of  all  such  new  HTML5  vectors  in  the  HTML5  Security 
CheatSheet 
[1]
© Attack & Defense Labs, http://www.andlabs.org  
 
 
Attacking with HTML5
Reverse Web Shells with COR: 
HTML5’s Cross Origin Request allows browsers to make cross domain Ajax calls from a.com 
to b.com and read the response as long as b.com allows it. This feature can be used to tunnel 
HTTP traffic over cross domain Ajax calls and set‐up a browser equivalent of a reverse shell.  
By  doing  this  an  attacker  can  hijack  a  victim’s  session  using  XSS  even  if  anti‐session 
hijacking measure like Http‐Only cookie and Session ID‐IP address binding are used. 
Once  the  JavaScript  payload  is  injected  to  the  victim’s  browser  either  through  Cross‐site 
Scripting or by convincing the victim to paste the scripting in the browser’s address bar, the 
script  starts  talking  to  the  attacker’s  server  through  Cross  Origin  Requests.  Using  this 
connection  the  attacker  can  browse  the  victim’s  affected  session  by  tunneling  his  requests 
through the victim’s browser. 
Earlier this year I had released an open source tool named ‘Shell of the Future’
[2]
 which is an 
implementation of this idea. It is extremely easy to use as it automates the entire attack and 
comes with two default JavaScript payloads. 
Architecture of Shell of the Future 
 
 
 
© Attack & Defense Labs, http://www.andlabs.org  
 
 
Attacking with HTML5
Clickjacking via HTML5: 
 
Text‐field Injection: 
 
ClickJacking can be used to submit forms across domains by bypassing the CSRF protection. 
Though it is very easy to click links or buttons through ClickJacking, populating the Input 
fields of the target form is relatively harder to do. 
HTML5’s Drag and Drop API can be used to fill the target forms simply by convincing the 
victim to perform a Drag and Drop action. The attacker’s site can camouflage the attack as a 
game that requires the player to drag and drop items while invisibly attacker controlled data 
is populated in to the input fields of the target form.  
Example: 
<div draggable=ʺtrueʺ ondragstart=ʺevent.dataTransfer.setData(ʹtext/plainʹ, ʹEvil dataʹ)ʺ> 
<h3>DRAG ME!!</h3> 
</div> 
 
This method was introduced by Paul Stone at BlackHat Europe 2010
[3]
 . 
 
IFRAME Sandboxing: 
 
There is a general misconception that including Framebusting code in each page of the site is 
the  best  way  to  defend  against  Clickjacking  attacks.  This  approach  appears  to  be  the  most 
popular  solution  as  well  even  though  the  OWASP  guidelines
[4]
 
clearly  mention  its 
disadvantages. 
If a websites’ only defense against ClickJacking attacks is FrameBusting then this protection 
can  be  bypassed  in  a  few  different  ways.  One  of  them  is  to  use  the  IFRAME  ‘sandbox’ 
attribute which is part of HTML5. 
 
Example: 
<iframe src=ʺhttp://www.victim.siteʺ sandbox></iframe> 
 
Setting this attribute disables JavaScript within the iframe. Since ‘framebusting’ relies on 
JavaScript, this attributes effectively neutralizes the defense. Popular sites like eBay, 
WordPress, PayPal rely only on ‘framebusting’ for protection and are hence open to this 
attack. 
 
 
© Attack & Defense Labs, http://www.andlabs.org  
Zgłoś jeśli naruszono regulamin