Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

["James Landis" <jcl24@xxxxxxxxxxx>]

------=_Part_24857_19474263.1168026309191
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Comments inline.

On 1/5/07, Amit Klein <aksecurity@gmail.com> wrote:
>
> James Landis wrote:
> > I never said your solution was WEAK, just that is is WEAKER.
> I think you're missing my point. An algorithm with one-use token (with
> no IP binding) is the weaker algorithm. Here's an attack against it:
>
> Attacker sends the user a link to http://www.attacker.site/script.cgi
>
>
> When the user requests http://www.attacker.site/script.cgi, the
> script.cgi requests file.pdf from vuln.site. It gets back a redirection
> URL and a session cookie/one-use-cookie. Then, it creates a Flash object
> that requests the URL with an injected Cookie header (with the session
> cookie/one-use-cookie) and serves this to the victim client. Voila.


I agree that your algorithm with IP address binding is stronger than the
single-use token algorithm with no IP address binding. That wasn't the point
I was trying to make. I'm simply saying that single-use tokens are stronger
than tokens that are generated from a specific algorithm (along the same
lines of one-time pads vs. encryption algorithms), they just have more
overhead on the server side. It's a trade-off.

> Yes, it is still theoretically very difficult to construct valid
> > tokens by breaking the encryption algorithm,
> You mean, it's as difficult as, say, breaking the streaming encryption
> of SSL... (if we implement with say AES based algo) the de-facto
> standard, considered pretty secure.


Sure, we could make it even harder than that if we wanted. Remember I didn't
say it was weak, just weaker.

> but it is certainly weaker to expose reconstructable values to the
> > client than to expose only a random value from the same keyspace. Also
> > note the class of insider attacks which involve gaining the key and
> > algorithm without reversing it.
> An insider can probably manipulate the server in this case, which is
> end-game. He can also probably steal the SSL private key, etc.


Possibly. But if the developer who writes the code doesn't control the
server (separation of privilege), this may be the best avenue of attack.
It's much easier to protect a 'random' algorithm against inside knowledge
than a deterministic one.

> In addition, if the server is using a published algorithm, the
> > attacker can also mount chosen-key attacks as well.
> >
> Huh? cipher algorithms are usually public. And I don't get the "chosen
> key attack"? the whole idea is that the key is secret, maintained on the
> server. If the attacker chooses this key, then the game is over...


The cipher is only part of the algorithm. As you mentioned before, the
algorithm could include random padding, the values can be concatenated
together in various orders, etc. Good ciphers are only as strong as the key,
so if the key is easily guessable, then you're right, the game is over. All
of these "what ifs" (and I agree beforehand that if we do everything right
then they are pretty damn unlikely), still point to the same thing I have
been trying to say: tokens generated by a deterministic algorithm are weaker
than random ones, all else being equal.

Before we go down this road, I know that any random number generator we can
use in practice is going to be deterministic as well. However, from a
provability perspective all we need to show is that this generator is
sufficiently random. Using the encryption scheme, we not only have to show
randomness but we have to do it for a much more complex system, which itself
will probably include it's OWN random number generator. Complexity is the
enemy of security.


> > In practice, for both methods it is probably easier to attack the
> > client by forcing them to use a valid generated token via one of the
> > attack schemes already discussed.
> >
> What attack methods do you refer to, which are applicable to my algorithm?


What? Let me rephrase. There are two ways to attack the defenses that have
been proposed on this thread (regardless of the token generator): attack the
token itself or attack the token handling in transit or on the client side.
What I'm saying is that if the encrypted token is generated securely
(non-trivial), then no matter which method is chosen then it is probably
easier to attack the token handling than to try to pre-generate a valid
token.

In essence, in current practical terms it doesn't really matter if you use a
computed token or a random nonce if the token generation process is secure
enough; that's not the weak link. However, the devil is in the details.
State management isn't without its pitfalls, either (resource starvation,
overhead, etc.), but the theory of state management is a lot easier for the
typical developer to grasp than strong encryption.

-j

------=_Part_24857_19474263.1168026309191
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Comments inline.<br><br><div><span class="gmail_quote">On 1/5/07, <b class="gmail_sendername">Amit Klein</b> &lt;<a href="mailto:aksecurity@gmail.com";>aksecurity@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
James Landis wrote:<br>&gt; I never said your solution was WEAK, just that is is WEAKER.<br>I think you&#39;re missing my point. An algorithm with one-use token (with<br>no IP binding) is the weaker algorithm. Here&#39;s an attack against it:
<br><br>Attacker sends the user a link to <a href="http://www.attacker.site/script.cgi";>http://www.attacker.site/script.cgi</a><br><br><br>When the user requests <a href="http://www.attacker.site/script.cgi";>http://www.attacker.site/script.cgi
</a>, the<br>script.cgi requests file.pdf from vuln.site. It gets back a redirection<br>URL and a session cookie/one-use-cookie. Then, it creates a Flash object<br>that requests the URL with an injected Cookie header (with the session
<br>cookie/one-use-cookie) and serves this to the victim client. Voila.</blockquote><div><br>I agree that your algorithm with IP address binding is stronger than the
single-use token algorithm with no IP address binding. That wasn&#39;t the point I
was trying to make. I&#39;m simply saying that single-use tokens are
stronger than tokens that are generated from a specific algorithm
(along the same lines of one-time pads vs. encryption algorithms), they
just have more overhead on the server side. It&#39;s a trade-off.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; Yes, it is still theoretically very difficult to construct valid
<br>&gt; tokens by breaking the encryption algorithm,<br>You mean, it&#39;s as difficult as, say, breaking the streaming encryption<br>of SSL... (if we implement with say AES based algo) the de-facto<br>standard, considered pretty secure.
</blockquote><div><br>Sure, we could make it even harder than that if we wanted. Remember I didn&#39;t say it was weak, just weaker.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt; but it is certainly weaker to expose reconstructable values to the<br>&gt; client than to expose only a random value from the same keyspace. Also<br>&gt; note the class of insider attacks which involve gaining the key and
<br>&gt; algorithm without reversing it.<br>An insider can probably manipulate the server in this case, which is<br>end-game. He can also probably steal the SSL private key, etc.</blockquote><div><br>Possibly. But if the developer who writes the code doesn&#39;t control the server (separation of privilege), this may be the best avenue of attack. It&#39;s much easier to protect a &#39;random&#39; algorithm against inside knowledge than a deterministic one.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; In addition, if the server is using a published algorithm, the<br>&gt; attacker can also mount chosen-key attacks as well.
<br>&gt;<br>Huh? cipher algorithms are usually public. And I don&#39;t get the &quot;chosen<br>key attack&quot;? the whole idea is that the key is secret, maintained on the<br>server. If the attacker chooses this key, then the game is over...
</blockquote><div><br>The cipher is only part of the algorithm. As you mentioned before, the algorithm could include random padding, the values can be concatenated together in various orders, etc. Good ciphers are only as strong as the key, so if the key is easily guessable, then you&#39;re right, the game is over. All of these &quot;what ifs&quot; (and I agree beforehand that if we do everything right then they are pretty damn unlikely), still point to the same thing I have been trying to say: tokens generated by a deterministic algorithm are weaker than random ones, all else being equal.
<br><br>Before we go down this road, I know that any random number generator we can use in practice is going to be deterministic as well. However, from a provability perspective all we need to show is that this generator is sufficiently random. Using the encryption scheme, we not only have to show randomness but we have to do it for a much more complex system, which itself will probably include it&#39;s OWN random number generator. Complexity is the enemy of security.
<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; In practice, for both methods it is probably easier to attack the<br>&gt; client by forcing them to use a valid generated token via one of the
<br>&gt; attack schemes already discussed.<br>&gt;<br>What attack methods do you refer to, which are applicable to my algorithm?</blockquote><div><br>What? Let me rephrase. There are two ways to attack the defenses that have been proposed on this thread (regardless of the token generator): attack the token itself or attack the token handling in transit or on the client side. What I&#39;m saying is that if the encrypted token is generated securely (non-trivial), then no matter which method is chosen then it is probably easier to attack the token handling than to try to pre-generate a valid token.
<br><br>In essence, in current practical terms it doesn&#39;t really matter if you use a computed token or a random nonce if the token generation process is secure enough; that&#39;s not the weak link. However, the devil is in the details. State management isn&#39;t without its pitfalls, either (resource starvation, overhead, etc.), but the theory of state management is a lot easier for the typical developer to grasp than strong encryption.
<br><br>-j<br></div><br></div><br>

------=_Part_24857_19474263.1168026309191--