 I guess, what can I say about this next presenter that we have, but all I know is, you know, having been in the community, I've heard of BootLogic, I've heard the name for a long time, and I have to say, we are very delighted, and it's about time that we finally have BootLogic come and present here at the pack attacking village, here at DEF CON. So, BootLogic's name is synonymous, I mean, if you look up cross-site scripting, BootLogic is synonymous, the name is synonymous. And before I begin, I do want to make a personal rag, we still have no idea why in the world you use Cristiano Ronaldo in your title slide. Without much ado, BootLogic! Thank you. Thank you. So, hi everyone. Sounds good? Okay. Hi everyone. I am Rodolfo Assis from Brazil, better known as BootLogic, and we are going to see what can be done with it for the win. So, I'm working at Sucuri Security, guys there, please, which is a go-dead company for the win also. I do some cross-site scripting, filter bypass, and some batch stuff. I help it to fix some vulnerabilities out there, but you won't see me in any of our famous, except the Microsoft one, because who is not there, right? And I have online access tool and discovery service. Okay. This is going to be a fast-paced talk about the dangers of XSS with a little intro to it for those who don't know it. XSS is a way to execute JavaScript code in victimized browser. The browser uses a programmatic model of the document in order to display it. So we can use JavaScript to do almost everything in browser. Here's a classical example of PHP code. We have a variable user, which is printed back to the screen. Then we have the input gel, but if we change the input for an XSS vector, we got the this pop-up, which is a proof of concept of the cross-site script. Okay. We have two main types, server-based, which can be reflected or stored, and kind-based after the code gets processed by the JavaScript engine in the browser. Okay. So after it, we can simply keep popping out. We have to do something with it. We have virtual defacement. What is that? It's a way to change the look of the page, and this might impact some business decision, for example, like buying, selling, off-stocks, or Bitcoin. Here is a simple code which doesn't really use JavaScript. It's just an HTML code to change the page with a picture, and here is a more complex one. It was a kind of a joke, which I altered the headline of this website with this code. You have an iframe, and then because the cross-site scripting is on a search feature of the site, we have to call the page first, use the source, and then we make some stylish over it. And finally, with the unload event handler, we are able to use the JavaScript to change the headline. Here's another one. We can access everything inside the page with JavaScript, so we can grab personal information like red card, social security number, or phone number address. We are able also to log what the victim is typing, and we can also build a fake login form to grab credentials. Here is the code of the key logger. We have two files. The PHP one is for log. It opens a file and writes on it, and the GS1 is the one that takes what the victim pressed, the keys, and sent to the PHP file. Here is a gif showing this in action. I'm typing this side, and the other side, the file is being updated. Okay, account stealing. We can still cook, but now, usually, we will face HTTP one flagged ones, but we can still compromise the account using password change or email change functionality which are unprotected. Here is a code, JavaScript code to still cook the simple one, and here is an example of the unprotected password change in WordPress.com. Okay, memory corruption. Thanks to the guys at Metasploit, it's easy to load some exploits against the browser victim. Here is the Metasploit beast, it's called a browser autopound. There is the first and the second version, which will load memory exploits, memory base exploits against the browser. To do that, we all need to call an image with a source of the attack domain, attack domain, access warm. Like any warm, we can simply spread it across the database and try to compromise all the accounts of the social network, and probably that means all. Here is an experiment of an access warm in action. You guys can watch it later, CMS. We have a guy here, expert in CMS, Mark. We can use XSS to achieve code execution at the CMS install. We just need to get the anti-serve token and submit it. WordPress is by far the most-used CMS nowadays. In my blog, I have code for all three, WordPress, Joomla, and Drupal. We are going to see now the WordPress one, the code to make an XSS becomes code execution in the website. We are using HelloDolly plugin, and then we start defining some variables, the path, the file, and the payload, which will be a reverse shell. We are using Netcat to get a reverse shell. We take the XSServe token with the first request. The dollar variable is the post-body that will be used here, and finally, we find the request to make the PHP code execute and open the Netcat listing. Here is the GIF showing. Admin is open the post to preview, and then the shell is open the other side. We have less dangerous outcome, like forced download of files, denial of service, and we can also get some geolocation or audio-video capture, but with permission of the victim. It's very easy to deliver XSS, because we can share in social networks, we can disguise it with URL shortening services, and we also have spam, spam fishing, and what a whole techniques to help the attacker or the test. Here are some references of my blog and my YouTube channel, so you guys can check later. Here is a reminder, if you are not convinced yet of how much dangerous can be an XSS attack. Any questions? The slides will be online, probably today. The worst thing, we can execute code in the website, if you know how to make the request, and if the admin is XSS with the link of the page with the XSS. I usually use separate browsers for each thing, so my blog, for example, I use another browser just for it, just to make the updates, just to access the dashboard, and I use another one to navigate, so XSS has to be fine in the same browser, it can't be XSS in my blog if I don't use that browser to navigate, to open links, malicious links. A user has to rely on the browser filter, for example, Chrome, or it has to rely on simply not clicking on links that come to your inbox, and that kind of security measures everyone has to take, yeah, plugging, browser plugging. You mean the XSS vector to use, user side, no, no, not yet, I don't have one, anyone? Anyone else, anyone else, going once, going twice, ladies and gentlemen, one more time, good logic. Thank you, thank you, thank you.