<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_06_11_2147240</id>
	<title>New Exploit Uses JavaScript To Compromise Intranets, VPNs</title>
	<author>timothy</author>
	<datestamp>1244716800000</datestamp>
	<htmltext>redsoxh8r writes <i>"Security researcher Robert Hansen, known as Rsnake, has developed a new class of attack that abuses a weakness in many corporate intranets and most browsers to <a href="http://threatpost.com/blogs/new-attack-class-exploits-intranet-weaknesses">compromise remote machines with persistent JavaScript backdoors</a>. Threatpost reports: 'The attacks rely on the long-term caching policies of some browsers and take advantage of the collisions that can occur when two different networks use the same non-routable IP address space, which happens fairly often because the amount of address space is quite small. The bottom line is that even a moderately skilled attacker has the ability to compromise remote machines without the use of any vulnerability or weakness in the client software.'"</i></htmltext>
<tokenext>redsoxh8r writes " Security researcher Robert Hansen , known as Rsnake , has developed a new class of attack that abuses a weakness in many corporate intranets and most browsers to compromise remote machines with persistent JavaScript backdoors .
Threatpost reports : 'The attacks rely on the long-term caching policies of some browsers and take advantage of the collisions that can occur when two different networks use the same non-routable IP address space , which happens fairly often because the amount of address space is quite small .
The bottom line is that even a moderately skilled attacker has the ability to compromise remote machines without the use of any vulnerability or weakness in the client software .
' "</tokentext>
<sentencetext>redsoxh8r writes "Security researcher Robert Hansen, known as Rsnake, has developed a new class of attack that abuses a weakness in many corporate intranets and most browsers to compromise remote machines with persistent JavaScript backdoors.
Threatpost reports: 'The attacks rely on the long-term caching policies of some browsers and take advantage of the collisions that can occur when two different networks use the same non-routable IP address space, which happens fairly often because the amount of address space is quite small.
The bottom line is that even a moderately skilled attacker has the ability to compromise remote machines without the use of any vulnerability or weakness in the client software.
'"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28304007</id>
	<title>Re:Author of article is a fucking cunt</title>
	<author>Anonymous</author>
	<datestamp>1244737260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>teach me to be as cool as you, faggot</htmltext>
<tokenext>teach me to be as cool as you , faggot</tokentext>
<sentencetext>teach me to be as cool as you, faggot</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302511</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28306207</id>
	<title>nothing new</title>
	<author>Anonymous</author>
	<datestamp>1244809860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>95\%(!!!!)of internet exploits - uses Java Script to inject/execute maliciouse content.
last ten years.
and btw, NOT EVER ONE antivirus - has monitor and clarify JS activity on owner PC's, browsers.

p.s.
weak corporation - tend to use JS, against SQL logic(UDF code in SQL servers), which is BAD in both terms security, performance, cost.
and both infect pages with 3rd-party content(well know that almost ALL internet adverisement network(such as banner networks), have malicious content or at least - used by govt inteligency agencies), or [censored]Adobe Flash, which is "insecure by design" and used for intel, long ears ago, too.</htmltext>
<tokenext>95 \ % ( ! ! ! !
) of internet exploits - uses Java Script to inject/execute maliciouse content .
last ten years .
and btw , NOT EVER ONE antivirus - has monitor and clarify JS activity on owner PC 's , browsers .
p.s . weak corporation - tend to use JS , against SQL logic ( UDF code in SQL servers ) , which is BAD in both terms security , performance , cost .
and both infect pages with 3rd-party content ( well know that almost ALL internet adverisement network ( such as banner networks ) , have malicious content or at least - used by govt inteligency agencies ) , or [ censored ] Adobe Flash , which is " insecure by design " and used for intel , long ears ago , too .</tokentext>
<sentencetext>95\%(!!!!
)of internet exploits - uses Java Script to inject/execute maliciouse content.
last ten years.
and btw, NOT EVER ONE antivirus - has monitor and clarify JS activity on owner PC's, browsers.
p.s.
weak corporation - tend to use JS, against SQL logic(UDF code in SQL servers), which is BAD in both terms security, performance, cost.
and both infect pages with 3rd-party content(well know that almost ALL internet adverisement network(such as banner networks), have malicious content or at least - used by govt inteligency agencies), or [censored]Adobe Flash, which is "insecure by design" and used for intel, long ears ago, too.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28305099</id>
	<title>Re:IPv6?</title>
	<author>Anonymous</author>
	<datestamp>1244839260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Actually not. The world has decided they still want NAT with IPv6.</p><p>Slashdot loses again because they are losers who live in their basements and never have touched a boob and are wrong about every single technology.</p></htmltext>
<tokenext>Actually not .
The world has decided they still want NAT with IPv6.Slashdot loses again because they are losers who live in their basements and never have touched a boob and are wrong about every single technology .</tokentext>
<sentencetext>Actually not.
The world has decided they still want NAT with IPv6.Slashdot loses again because they are losers who live in their basements and never have touched a boob and are wrong about every single technology.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301979</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301877</id>
	<title>Rsnake?</title>
	<author>Anonymous</author>
	<datestamp>1244721180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Does he hack with Zero Cool and Acid Burn against The Plague?
<br> <br>
HACK THE PLANET!</htmltext>
<tokenext>Does he hack with Zero Cool and Acid Burn against The Plague ?
HACK THE PLANET !</tokentext>
<sentencetext>Does he hack with Zero Cool and Acid Burn against The Plague?
HACK THE PLANET!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302063</id>
	<title>FailZors?</title>
	<author>Anonymous</author>
	<datestamp>1244722140000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><A HREF="http://goat.cx/" title="goat.cx" rel="nofollow">You don't need to UJse8et posts.</a> [goat.cx]</htmltext>
<tokenext>You do n't need to UJse8et posts .
[ goat.cx ]</tokentext>
<sentencetext>You don't need to UJse8et posts.
[goat.cx]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302135</id>
	<title>I don't see any actual erxploit here</title>
	<author>Anonymous</author>
	<datestamp>1244722680000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>All it is is a pretty wild theory that an exploit could occur... and there are a vast number of increasingly unlikely events that have to transpire for it to happen.</p><p>a) Your browser has to have unpatched remote script injection exploits.</p><p>b) You have to be using VPN to connect to *an untrusted network*. This is the opposite of what you normally use VPN for</p><p>c) Once connected to  this insecure network via VPN, you have to  for some reason visit a page on it that shares the IP address as another web server in your network. As well, the person who is hosting the exploit script on this page (that they are trying to cache) has to also know the name of the exact same script file *on your network*, so that the cache will pick it up the next time you connect to your own resources.</p><p>To me, all seems very unlikely. Sure, you could do this in a lab environment, but in the real world, if a would-be-intruder already knew that much about your  network, and you are for some reason VPN'ing into a network that they control, then you likely have bigger issues with physical security and meat-space trust relationships in our business, and are already screwed over.</p></htmltext>
<tokenext>All it is is a pretty wild theory that an exploit could occur... and there are a vast number of increasingly unlikely events that have to transpire for it to happen.a ) Your browser has to have unpatched remote script injection exploits.b ) You have to be using VPN to connect to * an untrusted network * .
This is the opposite of what you normally use VPN forc ) Once connected to this insecure network via VPN , you have to for some reason visit a page on it that shares the IP address as another web server in your network .
As well , the person who is hosting the exploit script on this page ( that they are trying to cache ) has to also know the name of the exact same script file * on your network * , so that the cache will pick it up the next time you connect to your own resources.To me , all seems very unlikely .
Sure , you could do this in a lab environment , but in the real world , if a would-be-intruder already knew that much about your network , and you are for some reason VPN'ing into a network that they control , then you likely have bigger issues with physical security and meat-space trust relationships in our business , and are already screwed over .</tokentext>
<sentencetext>All it is is a pretty wild theory that an exploit could occur... and there are a vast number of increasingly unlikely events that have to transpire for it to happen.a) Your browser has to have unpatched remote script injection exploits.b) You have to be using VPN to connect to *an untrusted network*.
This is the opposite of what you normally use VPN forc) Once connected to  this insecure network via VPN, you have to  for some reason visit a page on it that shares the IP address as another web server in your network.
As well, the person who is hosting the exploit script on this page (that they are trying to cache) has to also know the name of the exact same script file *on your network*, so that the cache will pick it up the next time you connect to your own resources.To me, all seems very unlikely.
Sure, you could do this in a lab environment, but in the real world, if a would-be-intruder already knew that much about your  network, and you are for some reason VPN'ing into a network that they control, then you likely have bigger issues with physical security and meat-space trust relationships in our business, and are already screwed over.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302607</id>
	<title>Another possible mitigation</title>
	<author>Burz</author>
	<datestamp>1244725800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It might be interesting to have the VPN software tell client programs (browsers) to flush cache whenever the former makes or breaks connection.</p></htmltext>
<tokenext>It might be interesting to have the VPN software tell client programs ( browsers ) to flush cache whenever the former makes or breaks connection .</tokentext>
<sentencetext>It might be interesting to have the VPN software tell client programs (browsers) to flush cache whenever the former makes or breaks connection.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301809</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301979</id>
	<title>Re:IPv6?</title>
	<author>Anonymous</author>
	<datestamp>1244721660000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>I would think so. It seems like everyone is using either 192.168.0.0/24 or 192.168.1.0/24 subnets and once in a while somebody has set up 10.0.0.0/24 subnet so your internal addresses wouldn't be that hard to guess. With IPv6 we could forget all this NAT crap and use "real" IP addresses.</htmltext>
<tokenext>I would think so .
It seems like everyone is using either 192.168.0.0/24 or 192.168.1.0/24 subnets and once in a while somebody has set up 10.0.0.0/24 subnet so your internal addresses would n't be that hard to guess .
With IPv6 we could forget all this NAT crap and use " real " IP addresses .</tokentext>
<sentencetext>I would think so.
It seems like everyone is using either 192.168.0.0/24 or 192.168.1.0/24 subnets and once in a while somebody has set up 10.0.0.0/24 subnet so your internal addresses wouldn't be that hard to guess.
With IPv6 we could forget all this NAT crap and use "real" IP addresses.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301745</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301769</id>
	<title>oh no</title>
	<author>Anonymous</author>
	<datestamp>1244720700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>they are taking over our intranets</p></htmltext>
<tokenext>they are taking over our intranets</tokentext>
<sentencetext>they are taking over our intranets</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301745</id>
	<title>IPv6?</title>
	<author>Anonymous</author>
	<datestamp>1244720580000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Knowing basically nothing about anything involved, i see address space limitations are a partial issue here - does that mean some use of IPv6 would help somewhere somehow?<br>-Taylor</p></htmltext>
<tokenext>Knowing basically nothing about anything involved , i see address space limitations are a partial issue here - does that mean some use of IPv6 would help somewhere somehow ? -Taylor</tokentext>
<sentencetext>Knowing basically nothing about anything involved, i see address space limitations are a partial issue here - does that mean some use of IPv6 would help somewhere somehow?-Taylor</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302511</id>
	<title>Author of article is a fucking cunt</title>
	<author>Anonymous</author>
	<datestamp>1244725200000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>"But because the amount of non-routable IP address space most commonly used for intranets is so small--about 1280 addresses, Hansen estimates--collisions between networks often occur."</p><p>Wait, wat?</p><p>RFC1918 has only 1280 addresses?</p><p>I stopped reading at this point. If authors cannot get \_BASIC\_ facts right, how the fuck can I believe \_ANYTHING\_ else this cunt says?</p><p>In short, this whole thing is a load of shit. Sure, its not difficult to do if you have full control of a network. But whats hard when you have full control?</p><p>tl;dr author is a fucking clueless poseur.</p></htmltext>
<tokenext>" But because the amount of non-routable IP address space most commonly used for intranets is so small--about 1280 addresses , Hansen estimates--collisions between networks often occur .
" Wait , wat ? RFC1918 has only 1280 addresses ? I stopped reading at this point .
If authors can not get \ _BASIC \ _ facts right , how the fuck can I believe \ _ANYTHING \ _ else this cunt says ? In short , this whole thing is a load of shit .
Sure , its not difficult to do if you have full control of a network .
But whats hard when you have full control ? tl ; dr author is a fucking clueless poseur .</tokentext>
<sentencetext>"But because the amount of non-routable IP address space most commonly used for intranets is so small--about 1280 addresses, Hansen estimates--collisions between networks often occur.
"Wait, wat?RFC1918 has only 1280 addresses?I stopped reading at this point.
If authors cannot get \_BASIC\_ facts right, how the fuck can I believe \_ANYTHING\_ else this cunt says?In short, this whole thing is a load of shit.
Sure, its not difficult to do if you have full control of a network.
But whats hard when you have full control?tl;dr author is a fucking clueless poseur.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302147</id>
	<title>Don't assume...</title>
	<author>Anonymous</author>
	<datestamp>1244722740000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>That your internal network is "safe"</p><p>Keep up those firewalls and security on all machines on a network with Internet access.</p><p>Belt-and-suspenders security is the only way if your resources are finite.</p></htmltext>
<tokenext>That your internal network is " safe " Keep up those firewalls and security on all machines on a network with Internet access.Belt-and-suspenders security is the only way if your resources are finite .</tokentext>
<sentencetext>That your internal network is "safe"Keep up those firewalls and security on all machines on a network with Internet access.Belt-and-suspenders security is the only way if your resources are finite.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28306887</id>
	<title>Re:Maybe I'm missing something...</title>
	<author>IceCreamGuy</author>
	<datestamp>1244815560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Once the VPN is connected, for all intents and purposes the equipment on both ends of the line are on the same LAN</p></div><p>You're missing the point, which is that whether or not you're connected to the VPN, chances are good that your browser stores some credential information. If you're on a LAN that's the same subnet as your VPN endpoint, then once you disconnect, a malicious local user would be able to coax your browser to give up cookies about the VPN-accessed pages. Your browser uses IP addresses to associate a cookie with a host, which is what makes this possible, and explains why the certificate model of HTTPS on the corporate Intranet foils this attack.</p></div>
	</htmltext>
<tokenext>Once the VPN is connected , for all intents and purposes the equipment on both ends of the line are on the same LANYou 're missing the point , which is that whether or not you 're connected to the VPN , chances are good that your browser stores some credential information .
If you 're on a LAN that 's the same subnet as your VPN endpoint , then once you disconnect , a malicious local user would be able to coax your browser to give up cookies about the VPN-accessed pages .
Your browser uses IP addresses to associate a cookie with a host , which is what makes this possible , and explains why the certificate model of HTTPS on the corporate Intranet foils this attack .</tokentext>
<sentencetext>Once the VPN is connected, for all intents and purposes the equipment on both ends of the line are on the same LANYou're missing the point, which is that whether or not you're connected to the VPN, chances are good that your browser stores some credential information.
If you're on a LAN that's the same subnet as your VPN endpoint, then once you disconnect, a malicious local user would be able to coax your browser to give up cookies about the VPN-accessed pages.
Your browser uses IP addresses to associate a cookie with a host, which is what makes this possible, and explains why the certificate model of HTTPS on the corporate Intranet foils this attack.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302309</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28304541</id>
	<title>Use 10.$((RANDOM\%256)).$((RANDOM\%256)).0/24</title>
	<author>rdebath</author>
	<datestamp>1244743920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
This all relies on being able to arrange a collision of RFC1597 addresses if you use</p><p><div class="quote"><p>echo 10.$((RANDOM\%256)).$((RANDOM\%256)).0/24</p></div><p>,</p><p><div class="quote"><p>echo 172.$((RANDOM\%16+16)).$((RANDOM\%256)).0/24</p></div><p>or</p><p><div class="quote"><p>echo 192.168.$((RANDOM\%250+4)).0/24</p></div><p>to choose your trusted network it becomes a lot harder. The 172 range seems especially overlooked.
</p><p>
A targeted attack, where the attacker isn't guessing addresses, is still possible of course.
</p><p>
BTW: This has always been suggested because of the possibility of later merges of multiple private networks.</p></div>
	</htmltext>
<tokenext>This all relies on being able to arrange a collision of RFC1597 addresses if you useecho 10. $ ( ( RANDOM \ % 256 ) ) . $ ( ( RANDOM \ % 256 ) ) .0/24,echo 172. $ ( ( RANDOM \ % 16 + 16 ) ) . $ ( ( RANDOM \ % 256 ) ) .0/24orecho 192.168. $ ( ( RANDOM \ % 250 + 4 ) ) .0/24to choose your trusted network it becomes a lot harder .
The 172 range seems especially overlooked .
A targeted attack , where the attacker is n't guessing addresses , is still possible of course .
BTW : This has always been suggested because of the possibility of later merges of multiple private networks .</tokentext>
<sentencetext>
This all relies on being able to arrange a collision of RFC1597 addresses if you useecho 10.$((RANDOM\%256)).$((RANDOM\%256)).0/24,echo 172.$((RANDOM\%16+16)).$((RANDOM\%256)).0/24orecho 192.168.$((RANDOM\%250+4)).0/24to choose your trusted network it becomes a lot harder.
The 172 range seems especially overlooked.
A targeted attack, where the attacker isn't guessing addresses, is still possible of course.
BTW: This has always been suggested because of the possibility of later merges of multiple private networks.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301985</id>
	<title>The moral of the story</title>
	<author>Anonymous</author>
	<datestamp>1244721660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>

VPN connections need special routing. If you don't trust your VPN partner totally, you should be sure that only the traffic you want goes over the connection.</htmltext>
<tokenext>VPN connections need special routing .
If you do n't trust your VPN partner totally , you should be sure that only the traffic you want goes over the connection .</tokentext>
<sentencetext>

VPN connections need special routing.
If you don't trust your VPN partner totally, you should be sure that only the traffic you want goes over the connection.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301863</id>
	<title>o..k</title>
	<author>QuantumG</author>
	<datestamp>1244721120000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Yes, if you control the server end of a VPN connection you can tell the other end what to route you.. assuming the client has been configured that way.  Why are VPN connections configured that way?  Because the admin is considered the trusted party.  The user (typically an employee) trusts the admin to be more secure than he is.</p><p>If the server was setup to route whatever the client said to route, that would be bad, but it's mostly not the case.</p></htmltext>
<tokenext>Yes , if you control the server end of a VPN connection you can tell the other end what to route you.. assuming the client has been configured that way .
Why are VPN connections configured that way ?
Because the admin is considered the trusted party .
The user ( typically an employee ) trusts the admin to be more secure than he is.If the server was setup to route whatever the client said to route , that would be bad , but it 's mostly not the case .</tokentext>
<sentencetext>Yes, if you control the server end of a VPN connection you can tell the other end what to route you.. assuming the client has been configured that way.
Why are VPN connections configured that way?
Because the admin is considered the trusted party.
The user (typically an employee) trusts the admin to be more secure than he is.If the server was setup to route whatever the client said to route, that would be bad, but it's mostly not the case.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302319</id>
	<title>javascript backdoor?</title>
	<author>Anonymous</author>
	<datestamp>1244723940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>could someone explain how that part works? why isn't javascript sandboxed properly?</p></htmltext>
<tokenext>could someone explain how that part works ?
why is n't javascript sandboxed properly ?</tokentext>
<sentencetext>could someone explain how that part works?
why isn't javascript sandboxed properly?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28311047</id>
	<title>Re:Network 10 has more than 1280 addresses.</title>
	<author>SCHecklerX</author>
	<datestamp>1244832720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I just got done re-numbering my home LAN for similar reasons.  I want to make sure that wherever I am, I can likely use my VPN without collision.  I re-did everything for a random spot within 172.16.0.0/12.</p></htmltext>
<tokenext>I just got done re-numbering my home LAN for similar reasons .
I want to make sure that wherever I am , I can likely use my VPN without collision .
I re-did everything for a random spot within 172.16.0.0/12 .</tokentext>
<sentencetext>I just got done re-numbering my home LAN for similar reasons.
I want to make sure that wherever I am, I can likely use my VPN without collision.
I re-did everything for a random spot within 172.16.0.0/12.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301809</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28304101</id>
	<title>Re:Maybe I'm missing something...</title>
	<author>Anonymous</author>
	<datestamp>1244738280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>The article specifically mentions VPN's (Virtual Private Networks). By definition, these are encrypted. </i></p><p>Nope. IPsec allows for a VPN using authentication only, without encryption. But you would have to be pretty weird to do that.</p><p><nobr> <wbr></nobr>/pedantic</p></htmltext>
<tokenext>The article specifically mentions VPN 's ( Virtual Private Networks ) .
By definition , these are encrypted .
Nope. IPsec allows for a VPN using authentication only , without encryption .
But you would have to be pretty weird to do that .
/pedantic</tokentext>
<sentencetext>The article specifically mentions VPN's (Virtual Private Networks).
By definition, these are encrypted.
Nope. IPsec allows for a VPN using authentication only, without encryption.
But you would have to be pretty weird to do that.
/pedantic</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302309</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301787</id>
	<title>Straight from the horse mouth</title>
	<author>Anonymous</author>
	<datestamp>1244720760000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><a href="http://www.sectheory.com/rfc1918-security-issues.htm" title="sectheory.com">here</a> [sectheory.com]</htmltext>
<tokenext>here [ sectheory.com ]</tokentext>
<sentencetext>here [sectheory.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302309</id>
	<title>Maybe I'm missing something...</title>
	<author>Anonymous</author>
	<datestamp>1244723880000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>The article specifically mentions VPN's (Virtual Private Networks).  By definition, these are encrypted.  Unless the attack happens <i>prior</i> to the VPN connection, how does the attacker inject <i>anything</i> into an encrypted datastream?  If it <i>is</i> done prior to the connection, what is new about the attack vector<br>
Once the VPN is connected, for all intents and purposes the equipment on both ends of the line are on the same LAN (different segment maybe, but not necessarily).  This is <i>much smoke</i> and <b>no flame</b>.</htmltext>
<tokenext>The article specifically mentions VPN 's ( Virtual Private Networks ) .
By definition , these are encrypted .
Unless the attack happens prior to the VPN connection , how does the attacker inject anything into an encrypted datastream ?
If it is done prior to the connection , what is new about the attack vector Once the VPN is connected , for all intents and purposes the equipment on both ends of the line are on the same LAN ( different segment maybe , but not necessarily ) .
This is much smoke and no flame .</tokentext>
<sentencetext>The article specifically mentions VPN's (Virtual Private Networks).
By definition, these are encrypted.
Unless the attack happens prior to the VPN connection, how does the attacker inject anything into an encrypted datastream?
If it is done prior to the connection, what is new about the attack vector
Once the VPN is connected, for all intents and purposes the equipment on both ends of the line are on the same LAN (different segment maybe, but not necessarily).
This is much smoke and no flame.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301755</id>
	<title>Definition of vulnerability or weakness?</title>
	<author>280Z28</author>
	<datestamp>1244720640000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>Isn't this the definition of a vulnerability or weakness in the client software? Just because you don't see xxxx as a threat in advance doesn't mean someone won't eventually use it as one.</htmltext>
<tokenext>Is n't this the definition of a vulnerability or weakness in the client software ?
Just because you do n't see xxxx as a threat in advance does n't mean someone wo n't eventually use it as one .</tokentext>
<sentencetext>Isn't this the definition of a vulnerability or weakness in the client software?
Just because you don't see xxxx as a threat in advance doesn't mean someone won't eventually use it as one.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28311037</id>
	<title>Re:Address space limitation?</title>
	<author>bwcbwc</author>
	<datestamp>1244832660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think it's the other way around. First, you get malicious javascript loaded on <a href="http://10.0.0.1/myscript.js" title="10.0.0.1">http://10.0.0.1/myscript.js</a> [10.0.0.1] when you visit the exploit site.<br>Then when you connect to <a href="http://10.0.0.1/myscript.js" title="10.0.0.1">http://10.0.0.1/myscript.js</a> [10.0.0.1] on a different non-routable subnet you end up running the malicious script instead of the local version, which could include doing fun stuff against the HTTP server  you are connecting to.</p></htmltext>
<tokenext>I think it 's the other way around .
First , you get malicious javascript loaded on http : //10.0.0.1/myscript.js [ 10.0.0.1 ] when you visit the exploit site.Then when you connect to http : //10.0.0.1/myscript.js [ 10.0.0.1 ] on a different non-routable subnet you end up running the malicious script instead of the local version , which could include doing fun stuff against the HTTP server you are connecting to .</tokentext>
<sentencetext>I think it's the other way around.
First, you get malicious javascript loaded on http://10.0.0.1/myscript.js [10.0.0.1] when you visit the exploit site.Then when you connect to http://10.0.0.1/myscript.js [10.0.0.1] on a different non-routable subnet you end up running the malicious script instead of the local version, which could include doing fun stuff against the HTTP server  you are connecting to.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302127</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28303339</id>
	<title>It's a switcheroo</title>
	<author>Anonymous</author>
	<datestamp>1244731680000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>The attack scenario involves two separate networks with RFC1918 addresses. The victim is on one network, the attacker is (to some extent) in control of the other network. The victim connects to the other network with a VPN client and requests pages from a webserver on that network.</p><p>The VPN connection is the key here, because it allows the attacker to create routes for servers which are normally on the victim's network. If the addresses used were public addresses, the client could be configured to reject overriding routes, but since collisions of RFC1918 addresses are to be expected, it accepts the routes.</p><p>The attacker can use these routes to poison the victim's browser cache: The browser can't tell the difference between the attacker's server and the server which the victim normally connects to, because they're named the same and have the same IP address. Only the routing has changed.</p><p>When the victim disconnects the VPN, the attacker's files remain in the browser cache and when the victim connects to the local server, they're used instead of the correct files.</p><p>The attacker could steal cookies directly, without poisoning the cache, but capturing a live login (or other locked-down resources) requires control over the login page while the victim logs in to the local server, i.e. when the victim is not connected to the rogue network via VPN. That's where the cache poisoning comes in.</p></htmltext>
<tokenext>The attack scenario involves two separate networks with RFC1918 addresses .
The victim is on one network , the attacker is ( to some extent ) in control of the other network .
The victim connects to the other network with a VPN client and requests pages from a webserver on that network.The VPN connection is the key here , because it allows the attacker to create routes for servers which are normally on the victim 's network .
If the addresses used were public addresses , the client could be configured to reject overriding routes , but since collisions of RFC1918 addresses are to be expected , it accepts the routes.The attacker can use these routes to poison the victim 's browser cache : The browser ca n't tell the difference between the attacker 's server and the server which the victim normally connects to , because they 're named the same and have the same IP address .
Only the routing has changed.When the victim disconnects the VPN , the attacker 's files remain in the browser cache and when the victim connects to the local server , they 're used instead of the correct files.The attacker could steal cookies directly , without poisoning the cache , but capturing a live login ( or other locked-down resources ) requires control over the login page while the victim logs in to the local server , i.e .
when the victim is not connected to the rogue network via VPN .
That 's where the cache poisoning comes in .</tokentext>
<sentencetext>The attack scenario involves two separate networks with RFC1918 addresses.
The victim is on one network, the attacker is (to some extent) in control of the other network.
The victim connects to the other network with a VPN client and requests pages from a webserver on that network.The VPN connection is the key here, because it allows the attacker to create routes for servers which are normally on the victim's network.
If the addresses used were public addresses, the client could be configured to reject overriding routes, but since collisions of RFC1918 addresses are to be expected, it accepts the routes.The attacker can use these routes to poison the victim's browser cache: The browser can't tell the difference between the attacker's server and the server which the victim normally connects to, because they're named the same and have the same IP address.
Only the routing has changed.When the victim disconnects the VPN, the attacker's files remain in the browser cache and when the victim connects to the local server, they're used instead of the correct files.The attacker could steal cookies directly, without poisoning the cache, but capturing a live login (or other locked-down resources) requires control over the login page while the victim logs in to the local server, i.e.
when the victim is not connected to the rogue network via VPN.
That's where the cache poisoning comes in.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302237</id>
	<title>Re:Network 10 has more than 1280 addresses.</title>
	<author>prockcore</author>
	<datestamp>1244723400000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>While we're clearing up misconceptions, the 127.x.x.x network is an entire class A loopback.</p><p>That means 127.44.55.66 is identical to 127.0.0.1</p></htmltext>
<tokenext>While we 're clearing up misconceptions , the 127.x.x.x network is an entire class A loopback.That means 127.44.55.66 is identical to 127.0.0.1</tokentext>
<sentencetext>While we're clearing up misconceptions, the 127.x.x.x network is an entire class A loopback.That means 127.44.55.66 is identical to 127.0.0.1</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301809</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302809</id>
	<title>Re:I don't see any actual erxploit here</title>
	<author>Anonymous</author>
	<datestamp>1244727180000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I doesn't have to be an intranet addresses either. Consider that the DNS at Starbucks could have been compromised to redirect slashdot.org to the attacker's servers, thus gaining your login cookies for slashdot.  And they could update your cached copy of slashdot's javascript while they're at it.  What this boils down to is that connecting over http on an insecure network is a security risk, and not just for the period that you are connected.
</p></htmltext>
<tokenext>I does n't have to be an intranet addresses either .
Consider that the DNS at Starbucks could have been compromised to redirect slashdot.org to the attacker 's servers , thus gaining your login cookies for slashdot .
And they could update your cached copy of slashdot 's javascript while they 're at it .
What this boils down to is that connecting over http on an insecure network is a security risk , and not just for the period that you are connected .</tokentext>
<sentencetext>I doesn't have to be an intranet addresses either.
Consider that the DNS at Starbucks could have been compromised to redirect slashdot.org to the attacker's servers, thus gaining your login cookies for slashdot.
And they could update your cached copy of slashdot's javascript while they're at it.
What this boils down to is that connecting over http on an insecure network is a security risk, and not just for the period that you are connected.
</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302135</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302555</id>
	<title>Re:Say What???</title>
	<author>Tony Hoyle</author>
	<datestamp>1244725500000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>Yes.. the writer of the article doesn't know squat about IP and/or is pushing an agenda (like suggesting ipv6 as an alternative).</p><p>As another poster mentioned, the number of things that have to happen for this to be a practical exploit makes it laughable.  If your VPN is compromised to that extent a few cookies is the *last* of your problems.</p><p>btw. there are non-routable IP addresses.. the whole 127/8 block, broadcast addresses, etc. but the original article just got it completely wrong.</p></htmltext>
<tokenext>Yes.. the writer of the article does n't know squat about IP and/or is pushing an agenda ( like suggesting ipv6 as an alternative ) .As another poster mentioned , the number of things that have to happen for this to be a practical exploit makes it laughable .
If your VPN is compromised to that extent a few cookies is the * last * of your problems.btw .
there are non-routable IP addresses.. the whole 127/8 block , broadcast addresses , etc .
but the original article just got it completely wrong .</tokentext>
<sentencetext>Yes.. the writer of the article doesn't know squat about IP and/or is pushing an agenda (like suggesting ipv6 as an alternative).As another poster mentioned, the number of things that have to happen for this to be a practical exploit makes it laughable.
If your VPN is compromised to that extent a few cookies is the *last* of your problems.btw.
there are non-routable IP addresses.. the whole 127/8 block, broadcast addresses, etc.
but the original article just got it completely wrong.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302409</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301775</id>
	<title>Phew!</title>
	<author>Anonymous</author>
	<datestamp>1244720760000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext>Good thing I don't use the Internet.</htmltext>
<tokenext>Good thing I do n't use the Internet .</tokentext>
<sentencetext>Good thing I don't use the Internet.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28304279</id>
	<title>Re:Maybe I'm missing something...</title>
	<author>Anonymous</author>
	<datestamp>1244739960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>So VPN's are a poor example.  What about motel networks?</p><p>Of course, there are so many other attacks available on untrusted networks.   They can create their own DNS zones and realistic websites so I am tricked into entering my password there.   The can redirect my http traffic through a squid server and collect my cookies.  And since they control the DNS, they can use that SSL root signing hack that was on<nobr> <wbr></nobr>/. a while back.  So they can spoof SSL sites too.</p><p>Just like in the real world, you can never be perfectly secure.</p></htmltext>
<tokenext>So VPN 's are a poor example .
What about motel networks ? Of course , there are so many other attacks available on untrusted networks .
They can create their own DNS zones and realistic websites so I am tricked into entering my password there .
The can redirect my http traffic through a squid server and collect my cookies .
And since they control the DNS , they can use that SSL root signing hack that was on / .
a while back .
So they can spoof SSL sites too.Just like in the real world , you can never be perfectly secure .</tokentext>
<sentencetext>So VPN's are a poor example.
What about motel networks?Of course, there are so many other attacks available on untrusted networks.
They can create their own DNS zones and realistic websites so I am tricked into entering my password there.
The can redirect my http traffic through a squid server and collect my cookies.
And since they control the DNS, they can use that SSL root signing hack that was on /.
a while back.
So they can spoof SSL sites too.Just like in the real world, you can never be perfectly secure.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302309</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302381</id>
	<title>Re:IPv6?</title>
	<author>Anonymous</author>
	<datestamp>1244724300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Actually, not really. Exploits could go after the default addresses interfaces take.</htmltext>
<tokenext>Actually , not really .
Exploits could go after the default addresses interfaces take .</tokentext>
<sentencetext>Actually, not really.
Exploits could go after the default addresses interfaces take.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301745</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301809</id>
	<title>Network 10 has more than 1280 addresses.</title>
	<author>Anonymous</author>
	<datestamp>1244720880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Use it, and use random IP numbers</p></htmltext>
<tokenext>Use it , and use random IP numbers</tokentext>
<sentencetext>Use it, and use random IP numbers</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301783</id>
	<title>Only an issue if you use IP based URLs</title>
	<author>Anonymous</author>
	<datestamp>1244720760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It's only an issue if you use the IP address in your URL.  If you don't, you're pretty much OK (unless the attackers can hijack DNS, in which case you've got other problems anyway).</p></htmltext>
<tokenext>It 's only an issue if you use the IP address in your URL .
If you do n't , you 're pretty much OK ( unless the attackers can hijack DNS , in which case you 've got other problems anyway ) .</tokentext>
<sentencetext>It's only an issue if you use the IP address in your URL.
If you don't, you're pretty much OK (unless the attackers can hijack DNS, in which case you've got other problems anyway).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28303695</id>
	<title>upnp, arp, javascript, iframes, pork me more!</title>
	<author>Anonymous</author>
	<datestamp>1244735040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>Let's not forget upnp, which a ton of fools leave enabled:</p><p><a href="http://www.gnucitizen.org/blog/flash-upnp-attack-faq" title="gnucitizen.org" rel="nofollow">http://www.gnucitizen.org/blog/flash-upnp-attack-faq</a> [gnucitizen.org]<br><a href="http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play" title="gnucitizen.org" rel="nofollow">http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play</a> [gnucitizen.org]</p><p>Ask 20 random people outside of a computing environment how they disable javascript in their browser and gauge their responses, now ask about Iframes. A growing number of javascript attacts are targeting arp in interesting ways, upnp or no. If you're not in a static arp environment, do the research *now*.</p><p>I simply won't use NoScript since the recent negative news about it. I won't use Firefox, either. Opera offers a much wider and simpler blocking ability of content across the board. It's proprietary, but so is the flash plugin which most of you swallow while using Firefox. So are the graphics drivers in a lot of your *nix setups.</p></htmltext>
<tokenext>Let 's not forget upnp , which a ton of fools leave enabled : http : //www.gnucitizen.org/blog/flash-upnp-attack-faq [ gnucitizen.org ] http : //www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play [ gnucitizen.org ] Ask 20 random people outside of a computing environment how they disable javascript in their browser and gauge their responses , now ask about Iframes .
A growing number of javascript attacts are targeting arp in interesting ways , upnp or no .
If you 're not in a static arp environment , do the research * now * .I simply wo n't use NoScript since the recent negative news about it .
I wo n't use Firefox , either .
Opera offers a much wider and simpler blocking ability of content across the board .
It 's proprietary , but so is the flash plugin which most of you swallow while using Firefox .
So are the graphics drivers in a lot of your * nix setups .</tokentext>
<sentencetext>Let's not forget upnp, which a ton of fools leave enabled:http://www.gnucitizen.org/blog/flash-upnp-attack-faq [gnucitizen.org]http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play [gnucitizen.org]Ask 20 random people outside of a computing environment how they disable javascript in their browser and gauge their responses, now ask about Iframes.
A growing number of javascript attacts are targeting arp in interesting ways, upnp or no.
If you're not in a static arp environment, do the research *now*.I simply won't use NoScript since the recent negative news about it.
I won't use Firefox, either.
Opera offers a much wider and simpler blocking ability of content across the board.
It's proprietary, but so is the flash plugin which most of you swallow while using Firefox.
So are the graphics drivers in a lot of your *nix setups.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302409</id>
	<title>Say What???</title>
	<author>Anonymous</author>
	<datestamp>1244724420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>&gt;&gt; But because the amount of non-routable IP address space most commonly used for intranets is so small--about 1280 addresses, Hansen estimates--collisions between networks often occur.
<br>
<br>
First of all there is no such thing as non-routable IP addresses.  While private IP space may not be routed on the Internet, it is all routable on the private network.
<br>
<br>
Secondly, 10. private IP space is a Class A assignment which translates to 16,777,216 IP addresses.  Where did they get 1280?
<br>
<br>
Or am I missing something here?</htmltext>
<tokenext>&gt; &gt; But because the amount of non-routable IP address space most commonly used for intranets is so small--about 1280 addresses , Hansen estimates--collisions between networks often occur .
First of all there is no such thing as non-routable IP addresses .
While private IP space may not be routed on the Internet , it is all routable on the private network .
Secondly , 10. private IP space is a Class A assignment which translates to 16,777,216 IP addresses .
Where did they get 1280 ?
Or am I missing something here ?</tokentext>
<sentencetext>&gt;&gt; But because the amount of non-routable IP address space most commonly used for intranets is so small--about 1280 addresses, Hansen estimates--collisions between networks often occur.
First of all there is no such thing as non-routable IP addresses.
While private IP space may not be routed on the Internet, it is all routable on the private network.
Secondly, 10. private IP space is a Class A assignment which translates to 16,777,216 IP addresses.
Where did they get 1280?
Or am I missing something here?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28305685</id>
	<title>Re:I don't see any actual erxploit here</title>
	<author>Anonymous</author>
	<datestamp>1244804220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>a) No, the browser can not do anything against this attack. As far as the browser is concerned, it is talking to the victim's own server, so everything it sees can and will be cached. The user will not visit his own server's web page when on an untrusted network, but the admin of an untrusted network can (trivially) inject iframes into other HTTP-delivered pages and make the victim's browser load URLs from the address of the victim's own server.</p><p>b) The point of the paper is that people too easily trust other networks and think that using non-routable addresses somehow protects their own network. A VPN is just one way to connect the victim's computer to an untrusted network (vendor, client, internet cafe, open WLAN,<nobr> <wbr></nobr>...) The paper lists some common scenarios where the sole purpose of the VPN is to protect the network that the client connects to. The victim does not necessarily trust the VPN network. Like you, the victim thinks: "My system is patched, my browser is not vulnerable, I'm safe."</p><p>c) You have to visit just one arbitrary non-SSL page. That's it. The attacker injects iframes into it, the iframes load URLs which collide with your local servers. Guessing names of servers and script file URLs is not that hard because many networks use the same names/IPs and appliances. The attacker can just sweep the most common ones and have a hit.</p><p>In response to other responses:</p><p>This is not about cookie-stealing. The victim is security-conscious and uses neither cookies nor credentials while on an untrusted network. This attack still owns the victim, because the cache persists until the victim is back on his trusted network where he enters credentials and accesses confidential information.</p><p>DNSSEC does not protect against this attack, because it is a routing-level attack. No DNS manipulation is necessary.</p><p>The problems are<br>1) trust of non-routable addresses as being safe from external interference and<br>2) the false belief that the risk of accepting information through untrusted networks only persists as long as the untrusted network is connected.</p></htmltext>
<tokenext>a ) No , the browser can not do anything against this attack .
As far as the browser is concerned , it is talking to the victim 's own server , so everything it sees can and will be cached .
The user will not visit his own server 's web page when on an untrusted network , but the admin of an untrusted network can ( trivially ) inject iframes into other HTTP-delivered pages and make the victim 's browser load URLs from the address of the victim 's own server.b ) The point of the paper is that people too easily trust other networks and think that using non-routable addresses somehow protects their own network .
A VPN is just one way to connect the victim 's computer to an untrusted network ( vendor , client , internet cafe , open WLAN , ... ) The paper lists some common scenarios where the sole purpose of the VPN is to protect the network that the client connects to .
The victim does not necessarily trust the VPN network .
Like you , the victim thinks : " My system is patched , my browser is not vulnerable , I 'm safe .
" c ) You have to visit just one arbitrary non-SSL page .
That 's it .
The attacker injects iframes into it , the iframes load URLs which collide with your local servers .
Guessing names of servers and script file URLs is not that hard because many networks use the same names/IPs and appliances .
The attacker can just sweep the most common ones and have a hit.In response to other responses : This is not about cookie-stealing .
The victim is security-conscious and uses neither cookies nor credentials while on an untrusted network .
This attack still owns the victim , because the cache persists until the victim is back on his trusted network where he enters credentials and accesses confidential information.DNSSEC does not protect against this attack , because it is a routing-level attack .
No DNS manipulation is necessary.The problems are1 ) trust of non-routable addresses as being safe from external interference and2 ) the false belief that the risk of accepting information through untrusted networks only persists as long as the untrusted network is connected .</tokentext>
<sentencetext>a) No, the browser can not do anything against this attack.
As far as the browser is concerned, it is talking to the victim's own server, so everything it sees can and will be cached.
The user will not visit his own server's web page when on an untrusted network, but the admin of an untrusted network can (trivially) inject iframes into other HTTP-delivered pages and make the victim's browser load URLs from the address of the victim's own server.b) The point of the paper is that people too easily trust other networks and think that using non-routable addresses somehow protects their own network.
A VPN is just one way to connect the victim's computer to an untrusted network (vendor, client, internet cafe, open WLAN, ...) The paper lists some common scenarios where the sole purpose of the VPN is to protect the network that the client connects to.
The victim does not necessarily trust the VPN network.
Like you, the victim thinks: "My system is patched, my browser is not vulnerable, I'm safe.
"c) You have to visit just one arbitrary non-SSL page.
That's it.
The attacker injects iframes into it, the iframes load URLs which collide with your local servers.
Guessing names of servers and script file URLs is not that hard because many networks use the same names/IPs and appliances.
The attacker can just sweep the most common ones and have a hit.In response to other responses:This is not about cookie-stealing.
The victim is security-conscious and uses neither cookies nor credentials while on an untrusted network.
This attack still owns the victim, because the cache persists until the victim is back on his trusted network where he enters credentials and accesses confidential information.DNSSEC does not protect against this attack, because it is a routing-level attack.
No DNS manipulation is necessary.The problems are1) trust of non-routable addresses as being safe from external interference and2) the false belief that the risk of accepting information through untrusted networks only persists as long as the untrusted network is connected.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302135</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302127</id>
	<title>Address space limitation?</title>
	<author>Anonymous</author>
	<datestamp>1244722620000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I think address space limitation is not an issue here. If I correctly understand this vulnerability means that for example some user has cached session cookies for intranet site like <a href="http://10.0.0.1/intranet" title="10.0.0.1">http://10.0.0.1/intranet</a> [10.0.0.1] - then if he connects to other network (that I control) via VPN I can forge <a href="http://10.0.0.1/intranet" title="10.0.0.1">http://10.0.0.1/intranet</a> [10.0.0.1] site in my network trick the browser by injecting JavaScript code and read this users session cookies? Do I understand this correctly?</p><p>Well if I do then SSL/TLS certificates and cryptography in general are the means to authenticate someones (or some servers) indentity.</p><p>So my question is: if sites in my intranet use proper PKI and SSL/TLS mechanisms am I still voulnerable to this flaw?</p></htmltext>
<tokenext>I think address space limitation is not an issue here .
If I correctly understand this vulnerability means that for example some user has cached session cookies for intranet site like http : //10.0.0.1/intranet [ 10.0.0.1 ] - then if he connects to other network ( that I control ) via VPN I can forge http : //10.0.0.1/intranet [ 10.0.0.1 ] site in my network trick the browser by injecting JavaScript code and read this users session cookies ?
Do I understand this correctly ? Well if I do then SSL/TLS certificates and cryptography in general are the means to authenticate someones ( or some servers ) indentity.So my question is : if sites in my intranet use proper PKI and SSL/TLS mechanisms am I still voulnerable to this flaw ?</tokentext>
<sentencetext>I think address space limitation is not an issue here.
If I correctly understand this vulnerability means that for example some user has cached session cookies for intranet site like http://10.0.0.1/intranet [10.0.0.1] - then if he connects to other network (that I control) via VPN I can forge http://10.0.0.1/intranet [10.0.0.1] site in my network trick the browser by injecting JavaScript code and read this users session cookies?
Do I understand this correctly?Well if I do then SSL/TLS certificates and cryptography in general are the means to authenticate someones (or some servers) indentity.So my question is: if sites in my intranet use proper PKI and SSL/TLS mechanisms am I still voulnerable to this flaw?</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28304007
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302511
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28304101
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302309
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28311037
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302127
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28305099
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301979
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301745
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302555
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302409
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302809
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302135
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28305685
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302135
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302607
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301809
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302381
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301745
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28311047
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301809
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28304279
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302309
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302237
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301809
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_11_2147240_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28306887
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302309
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301863
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302409
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302555
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301745
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301979
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28305099
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302381
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28306207
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301809
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302607
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28311047
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302237
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302309
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28304101
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28306887
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28304279
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302135
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28305685
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302809
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301755
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301775
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28303339
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301783
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301985
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302511
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28304007
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302147
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28302127
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28311037
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_11_2147240.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_11_2147240.28301787
</commentlist>
</conversation>
