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.
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...Mario Heiderich
ECMAScript 6, in short ES6, has been boiling in a copper pot for many years by now and step-by-step, browser vendors come forward to taste the first sips of this mystery soup. So, ES6 is no longer a theoretic language but already crawled across the doorstep and now lurks under your bed, ready for the nasty, waiting for the right moment to bite.
Now, what is this whole ES6 thing? How did it develop and who made it? And why is it now implemented in your favorite browser? And what does it mean for web-security and beyond?
This talk will answer these questions and showcase the new language from an attacker's perspective. You will see the new code constructs possible to be executed with ES6, new attack vectors and learn what you can do to tame that beast. Kafkaesque terminology such as expression interpolation, proper tail calls, computed properties, spread parameters, modules and tagged template strings will no longer be surprising you after attending this talk.
XSS Attacks Exploiting XSS Filter by Masato Kinugawa - CODE BLUE 2015CODE BLUE
Microsoft's web browsers, Internet Explorer and Edge, have a feature called 'XSS filter' built in which protects users from XSS attacks. In order to deny XSS attacks, XSS filter looks into the request for a string resembling an XSS attack, compares it with the page and finds the appearance of it, and rewrites parts of the string if it appears in the page. This rewriting process of the string - is this done safely? The answer is no. This time, I have found a way to exploit XSS filter not to protect a web page, but to create an XSS vulnerability on a web page that is completely sane and free of XSS vulnerability. In this talk, I will describe technical details about possibilities of XSS attacks exploiting XSS filter and propose what website administrators should do to face this XSS filter nightmare.
XSS is much more than just <script>alert(1)</script>. Thousands of unique vectors can be built and more complex payloads to evade filters and WAFs. In these slides, cool techniques to bypass them are described, from HTML to javascript. See also http://brutelogic.com.br/blog
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...Mario Heiderich
ECMAScript 6, in short ES6, has been boiling in a copper pot for many years by now and step-by-step, browser vendors come forward to taste the first sips of this mystery soup. So, ES6 is no longer a theoretic language but already crawled across the doorstep and now lurks under your bed, ready for the nasty, waiting for the right moment to bite.
Now, what is this whole ES6 thing? How did it develop and who made it? And why is it now implemented in your favorite browser? And what does it mean for web-security and beyond?
This talk will answer these questions and showcase the new language from an attacker's perspective. You will see the new code constructs possible to be executed with ES6, new attack vectors and learn what you can do to tame that beast. Kafkaesque terminology such as expression interpolation, proper tail calls, computed properties, spread parameters, modules and tagged template strings will no longer be surprising you after attending this talk.
XSS Attacks Exploiting XSS Filter by Masato Kinugawa - CODE BLUE 2015CODE BLUE
Microsoft's web browsers, Internet Explorer and Edge, have a feature called 'XSS filter' built in which protects users from XSS attacks. In order to deny XSS attacks, XSS filter looks into the request for a string resembling an XSS attack, compares it with the page and finds the appearance of it, and rewrites parts of the string if it appears in the page. This rewriting process of the string - is this done safely? The answer is no. This time, I have found a way to exploit XSS filter not to protect a web page, but to create an XSS vulnerability on a web page that is completely sane and free of XSS vulnerability. In this talk, I will describe technical details about possibilities of XSS attacks exploiting XSS filter and propose what website administrators should do to face this XSS filter nightmare.
XSS is much more than just <script>alert(1)</script>. Thousands of unique vectors can be built and more complex payloads to evade filters and WAFs. In these slides, cool techniques to bypass them are described, from HTML to javascript. See also http://brutelogic.com.br/blog
This talk shares the various techniques I found whilst building the XSS cheat sheet. It contains auto executing vectors, AngularJS CSP bypasses and dangling markup attacks.
Slides for a college course at City College San Francisco. Based on "Hands-On Ethical Hacking and Network Defense, Third Edition" by Michael T. Simpson, Kent Backman, and James Corley -- ISBN: 9781285454610.
Instructor: Sam Bowne
Class website: https://samsclass.info/123/123_S17.shtml
Ekoparty 2017 - The Bug Hunter's Methodologybugcrowd
Goals of this Presentation:
- Outline and provide an actionable methodology for effectively and efficiently testing for, and finding security vulnerabilities in web applications
- Cover common vulnerability classes/types/categories from a high level
- Provide useful tools and processes that you can take right out into the world to immediately improve your own bug hunting abilities
SAST vs. DAST: What’s the Best Method For Application Security Testing?Cigital
High profile security breaches are leading to heightened organizational security concerns. Firms around the world are now observing the consequences of security breaches that are becoming more widespread and more advanced. Due to this, firms are ready to identify vulnerabilities in their applications and mitigate the risks.
Two ways to go about this are static application security testing (SAST) and dynamic application security testing (DAST). These application security testing methodologies are used to find the security vulnerabilities that make your organization’s applications susceptible to attack.
The two methodologies approach applications very differently. They are most effective at different phases of the software development life cycle (SDLC) and find different types of vulnerabilities. For example, SAST detects critical vulnerabilities such as cross-site scripting (XSS), SQL injection, and buffer overflow earlier in the SDLC. DAST, on the other hand, uses an outside-in penetration testing approach to identify security vulnerabilities while web applications are running.
Let us guide you through your application security testing journey with more key differences between SAST and DAST:
Polyglot payloads in practice by avlidienbrunn at HackPraMathias Karlsson
A lecture/talk describing how to build and use polyglot payloads for finding vulnerabilities in web applications that traditional payloads can't.
Here's the last slide: http://www.slideshare.net/MathiasKarlsson2/final-slide-36636479
This talk shares the various techniques I found whilst building the XSS cheat sheet. It contains auto executing vectors, AngularJS CSP bypasses and dangling markup attacks.
Slides for a college course at City College San Francisco. Based on "Hands-On Ethical Hacking and Network Defense, Third Edition" by Michael T. Simpson, Kent Backman, and James Corley -- ISBN: 9781285454610.
Instructor: Sam Bowne
Class website: https://samsclass.info/123/123_S17.shtml
Ekoparty 2017 - The Bug Hunter's Methodologybugcrowd
Goals of this Presentation:
- Outline and provide an actionable methodology for effectively and efficiently testing for, and finding security vulnerabilities in web applications
- Cover common vulnerability classes/types/categories from a high level
- Provide useful tools and processes that you can take right out into the world to immediately improve your own bug hunting abilities
SAST vs. DAST: What’s the Best Method For Application Security Testing?Cigital
High profile security breaches are leading to heightened organizational security concerns. Firms around the world are now observing the consequences of security breaches that are becoming more widespread and more advanced. Due to this, firms are ready to identify vulnerabilities in their applications and mitigate the risks.
Two ways to go about this are static application security testing (SAST) and dynamic application security testing (DAST). These application security testing methodologies are used to find the security vulnerabilities that make your organization’s applications susceptible to attack.
The two methodologies approach applications very differently. They are most effective at different phases of the software development life cycle (SDLC) and find different types of vulnerabilities. For example, SAST detects critical vulnerabilities such as cross-site scripting (XSS), SQL injection, and buffer overflow earlier in the SDLC. DAST, on the other hand, uses an outside-in penetration testing approach to identify security vulnerabilities while web applications are running.
Let us guide you through your application security testing journey with more key differences between SAST and DAST:
Polyglot payloads in practice by avlidienbrunn at HackPraMathias Karlsson
A lecture/talk describing how to build and use polyglot payloads for finding vulnerabilities in web applications that traditional payloads can't.
Here's the last slide: http://www.slideshare.net/MathiasKarlsson2/final-slide-36636479
HTML5 is hot right now and a lot is being said about it. It is time to take a look at what it means to apply it on the web and see how things work out. Turns out we still have a lot to fix and we need your help.
A hands-on workshop for DC Web Women on August 14, 2012.
Read more about the workshop and a summary of what we talked about on my blog: http://www.clarissapeterson.com/2012/08/responsive-web-design/
You know it's important for your web project to be accessible to people who use all kinds of assistive technology to access the internet. But all the guidelines for web accessibility you can find don't go much beyond "make sure all your images have alt text", and all the resources you can find treat "accessibility" as a synonym for "making your site work in a screen reader". You know there are other things you should be doing and other forms of assistive technology you should be accomodating, but all the best practices documents are a complicated morass of contradicting information (if you can find best practices documents at all.)
Have no fear! This tutorial gives you a number of concrete steps to take to make things more accessible.
This presentation has downloadable notes and exercises available at http://denise.dreamwidth.org/tag/a11y . Video of the talk should be available later.
Presentation on using CSS Frameworks (particularly BlueprintCSS) at the Scottish Web Folk meeting, Friday 17 April 2009 at the University of Strathclyde, Glasgow.
This presentation was delivered at the SANS CTI Summit in Washington, DC on February 3, 2015. Created and delivered by Matt Jonkman, the CTO and founder of Emerging Threats.
Similar to Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-application XSS (20)
This talk introduces and discusses a novel, mostly unpublished technique to successfully attack websites that are applied with state-of-the-art XSS protection. This attack labeled Mutation-XSS (mXSS) is capable of bypassing high-end filter systems by utilizing the browser and its unknown capabilities - every single f***** one of them. We analyzed the type and number of high-profile websites and applications that are affected by this kind of attack. Several live demos during the presentation will share these impressions and help understanding, what mXSS is, why mXSS is possible and why it is of importance for defenders as well as professional attackers to understand and examine mXSS even further. The talk wraps up several years of research on this field, shows the abhorrent findings, discusses the consequences and delivers a step-by-step guide on how to protect against this kind of mayhem - with a strong focus on feasibility and scalability.
Dev and Blind - Attacking the weakest Link in IT SecurityMario Heiderich
The developer is an easy and valuable target for malicious minds. The reasons for that are numerous and hard to come by. This talk delivers examples, proof, discussion and awkward moments in a pretty special way.
Everybody hates developers – especially web developers. And why not? The cracks and crevices of their APIs and implementations are the reason that vulnerabilities in web applications are still a widespread issue – and will continue to be in the foreseeable future.
Bashing and blaming them for their wrongdoings is fun – boy, they are stupid in their mistakes! But has anyone ever dared to have an open on stage battle with an actual developer?
And who of the developers dares to face their collective nemesis – the attacker? Can there be life where matter and anti-matter collide? We will know about this soon – because this is what this talk is going to be about. Developer versus attacker – vulnerability versus defense. Be prepared for swearing, violence and people leaving the stage prematurely in tears.
This 7-second Brain Wave Ritual Attracts Money To You.!nirahealhty
Discover the power of a simple 7-second brain wave ritual that can attract wealth and abundance into your life. By tapping into specific brain frequencies, this technique helps you manifest financial success effortlessly. Ready to transform your financial future? Try this powerful ritual and start attracting money today!
ER(Entity Relationship) Diagram for online shopping - TAEHimani415946
https://bit.ly/3KACoyV
The ER diagram for the project is the foundation for the building of the database of the project. The properties, datatypes, and attributes are defined by the ER diagram.
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
Multi-cluster Kubernetes Networking- Patterns, Projects and GuidelinesSanjeev Rampal
Talk presented at Kubernetes Community Day, New York, May 2024.
Technical summary of Multi-Cluster Kubernetes Networking architectures with focus on 4 key topics.
1) Key patterns for Multi-cluster architectures
2) Architectural comparison of several OSS/ CNCF projects to address these patterns
3) Evolution trends for the APIs of these projects
4) Some design recommendations & guidelines for adopting/ deploying these solutions.
Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-application XSS
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. 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
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
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. 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. 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. 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. The Origins of the Clipboard
Data transfer with expanded clipboard formats
EP 0717354 A1, 1995, MSFT
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. 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
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. 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.
22. 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?
23. 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.
24. 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.
26. 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
30. 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!
31. 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!
35. 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
39. 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
44. 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
48. 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
49. 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
50. 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
51. 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 :)
52. 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);
53. 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?
54. 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 :)