Comments on: The Shadow http://www.gnucitizen.org/blog/the-shadow/ Information Security Think Tank Sat, 02 Feb 2013 17:50:40 +0000 hourly 1 http://wordpress.org/?v=3.4.1 By: pdp http://www.gnucitizen.org/blog/the-shadow/comment-page-1/#comment-3403 pdp Tue, 06 Feb 2007 09:30:33 +0000 http://www.gnucitizen.org/blog/the-shadow#comment-3403 Anurag, it is the same. However, I have all XSS vectors in advance for all external links, so the user doesn't have to wait. I have tested this technique on several Kiosk platforms and they kind of work. :) Anurag, it is the same. However, I have all XSS vectors in advance for all external links, so the user doesn’t have to wait.

I have tested this technique on several Kiosk platforms and they kind of work. :)

]]> By: Anurag Agarwal http://www.gnucitizen.org/blog/the-shadow/comment-page-1/#comment-3377 Anurag Agarwal Tue, 06 Feb 2007 00:05:32 +0000 http://www.gnucitizen.org/blog/the-shadow#comment-3377 I had been thinking about the same thing. Here is my approach 1. victimA is hijacked by exploiting its XSS vulnerability. 2. I have control over all its links (internal and external) 3. Internal links i am not worried about as i can pass them through my ajax worm (you can see the PoC on my blog) 4. When it comes to external links, ajax wont work but i can still send all those links to attacker.com server and using any server side program i can check those sites for different types of XSS vuln and when found, i replace the link on victimA.com with the XSS attack vector so when a user clicks, the worm can be passed to the new site. All this can be done without iframe. If your approach is different, then i would be interested to know whenever you decide to post it. I had been thinking about the same thing. Here is my approach

1. victimA is hijacked by exploiting its XSS vulnerability.
2. I have control over all its links (internal and external)
3. Internal links i am not worried about as i can pass them through my ajax worm (you can see the PoC on my blog)
4. When it comes to external links, ajax wont work but i can still send all those links to attacker.com server and using any server side program i can check those sites for different types of XSS vuln and when found, i replace the link on victimA.com with the XSS attack vector so when a user clicks, the worm can be passed to the new site.

All this can be done without iframe.

If your approach is different, then i would be interested to know whenever you decide to post it.

]]> By: pdp http://www.gnucitizen.org/blog/the-shadow/comment-page-1/#comment-3295 pdp Sun, 04 Feb 2007 09:01:16 +0000 http://www.gnucitizen.org/blog/the-shadow#comment-3295 kuza55, probably you misunderstand the article. Thanks for the info. Anurag, not exactly! What I am saying is that an AJAX worm can move with the user as long as the next page of destination is also vulnerable to XSS. It is that simple. When the user serfs further, the worm just follows like a shadow. In order to achieve that you have to find all possible XSS vectors, in advance, for all external links given a starting point. So, you need a spider that will be able to detect XSS while visiting pages. Once the shadow is in motion, it will perform queries on some sort of remote database to retrieve information about the next XSS vector. When the user clicks on a link, the shadow will take that user to the specified place but also, it will be able to move itself as well. Hope that now the concept is clear enough? Unfortunately, I cannot present my POC because I have to share my research XSS database. This is very unethical, I believe. However, with a little bit of Python and a few simple XSS checks you can definitely write a XSS spider on your own. I might publish mine actually. Let me think about it first. kuza55, probably you misunderstand the article. Thanks for the info.

Anurag, not exactly! What I am saying is that an AJAX worm can move with the user as long as the next page of destination is also vulnerable to XSS. It is that simple. When the user serfs further, the worm just follows like a shadow.

In order to achieve that you have to find all possible XSS vectors, in advance, for all external links given a starting point. So, you need a spider that will be able to detect XSS while visiting pages. Once the shadow is in motion, it will perform queries on some sort of remote database to retrieve information about the next XSS vector. When the user clicks on a link, the shadow will take that user to the specified place but also, it will be able to move itself as well. Hope that now the concept is clear enough?

Unfortunately, I cannot present my POC because I have to share my research XSS database. This is very unethical, I believe. However, with a little bit of Python and a few simple XSS checks you can definitely write a XSS spider on your own. I might publish mine actually. Let me think about it first.

]]> By: Anurag Agarwal http://www.gnucitizen.org/blog/the-shadow/comment-page-1/#comment-3229 Anurag Agarwal Sat, 03 Feb 2007 01:28:23 +0000 http://www.gnucitizen.org/blog/the-shadow#comment-3229 If i am reading you correctly then you want to try out an XSS attack on all the external links on a web page to see if they are vulnerable to XSS. if they are then you spawn an iframe but won't it be easier to replace the url with the XSS attack vector rather then spawning a frame? the other point i would like to mention is the limitation with this approach is that you can only try out for XSS in the url or header variables. If i am reading you correctly then you want to try out an XSS attack on all the external links on a web page to see if they are vulnerable to XSS. if they are then you spawn an iframe but won’t it be easier to replace the url with the XSS attack vector rather then spawning a frame? the other point i would like to mention is the limitation with this approach is that you can only try out for XSS in the url or header variables.

]]> By: kuza55 http://www.gnucitizen.org/blog/the-shadow/comment-page-1/#comment-3225 kuza55 Fri, 02 Feb 2007 22:14:25 +0000 http://www.gnucitizen.org/blog/the-shadow#comment-3225 Ok, excuse me if I'm wrong - but this seems like just another scare article, it tells us nothing about what you've come up with only that you've come up with some attacks. But anyway; for maintaining control of a user there is one type of XSS vulnerability which can greatly help an attacker. XSS vulns which print data stored in cookies, but which you can set through request parameters, e.g. when you are allowed to choose a stylesheet for a site, or if a reflected XSS vector is printing a $_REQUEST value rather than a $_GET value. Using the example of being able to choose a stylesheet; if you create a reflected XSS vector where you set the cookie to a value that is valid, but append some data so that you execute your script as well, and have the cookie set to last for years, you will effectively have control of the user's browser for the whole time they are on the site - which on sites like forums is an exceptionally long time. Furthermore you could even go so far as have your code rewrite the DOM so that when the user selects a new skin, the cookie is adultered so that the XSS payload stays intact. Ok, excuse me if I’m wrong – but this seems like just another scare article, it tells us nothing about what you’ve come up with only that you’ve come up with some attacks.

But anyway; for maintaining control of a user there is one type of XSS vulnerability which can greatly help an attacker. XSS vulns which print data stored in cookies, but which you can set through request parameters, e.g. when you are allowed to choose a stylesheet for a site, or if a reflected XSS vector is printing a $_REQUEST value rather than a $_GET value.

Using the example of being able to choose a stylesheet; if you create a reflected XSS vector where you set the cookie to a value that is valid, but append some data so that you execute your script as well, and have the cookie set to last for years, you will effectively have control of the user’s browser for the whole time they are on the site – which on sites like forums is an exceptionally long time. Furthermore you could even go so far as have your code rewrite the DOM so that when the user selects a new skin, the cookie is adultered so that the XSS payload stays intact.

]]>