Security News

Episode 208 Show Notes

After Carlos does the tech segment, this episode is not intended for human consumption.

Episode 208 Part 2 - Direct Audio Download

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce,Carlos Perez

Audio Feeds:

(author unknown)02921839077878952869

Episode 208 Show Notes

After Carlos does the tech segment, this episode is not intended for human consumption.

Episode 208 Part 2 - Direct Audio Download

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce,Carlos Perez

Audio Feeds:

(author unknown)02921839077878952869

http://www.exploit-db.com/exploits/14875

http://www.exploit-db.com/exploits/14875

Version 1.4 des freien Protokollanalysators beseitigt mehrere Fehler und bringt neue Funktionen mit.(author unknown)02921839077878952869

Version 1.4 des freien Protokollanalysators beseitigt mehrere Fehler und bringt neue Funktionen mit.(author unknown)02921839077878952869

Please join Tenable's own Ron Gula, Renaud Deraison, Marcus Ranum and Paul Asadoorian for a Security Showcase on October 6, from 8:30am to 2:00pm at the New York Marriott East Side, 525 Lexington Ave. at 49th Street in New York City. Breakfast and lunch will be provided during this half-day FREE event.

Topics we will cover include:

The current status and future development plans for Nessus and our enterprise vulnerability assessment, compliance and log management products: SecurityCenter, Passive Vulnerability Scanner and Log Correlation Engine

The advantages of pairing active and passive scanning

What security strategies are outdated and what new trends are half-baked

"How I Learned to Stop Worrying and Love Regulatory Compliance"

"Zen and the Art of Nessus Web Application Scanning"

During lunch you will also be given a live demonstration of our enterprise solutions as they relate to the themes above.

Contact Donal McRae (dmcrae -at- tenablesecurity.com) to reserve your seat (space is limited for this event). We hope you can make it as the showcase is a rare opportunity to receive firsthand insight from four leading experts.

Please join Tenable's own Ron Gula, Renaud Deraison, Marcus Ranum and Paul Asadoorian for a Security Showcase on October 6, from 8:30am to 2:00pm at the New York Marriott East Side, 525 Lexington Ave. at 49th Street in New York City. Breakfast and lunch will be provided during this half-day FREE event.

Topics we will cover include:

The current status and future development plans for Nessus and our enterprise vulnerability assessment, compliance and log management products: SecurityCenter, Passive Vulnerability Scanner and Log Correlation Engine

The advantages of pairing active and passive scanning

What security strategies are outdated and what new trends are half-baked

"How I Learned to Stop Worrying and Love Regulatory Compliance"

"Zen and the Art of Nessus Web Application Scanning"

During lunch you will also be given a live demonstration of our enterprise solutions as they relate to the themes above.

Contact Donal McRae (dmcrae -at- tenablesecurity.com) to reserve your seat (space is limited for this event). We hope you can make it as the showcase is a rare opportunity to receive firsthand insight from four leading experts.

Alle Lücken finden sich in WebKit und lassen sich zum Kompromittieren eines Systems missbrauchen.(author unknown)02921839077878952869

Alle Lücken finden sich in WebKit und lassen sich zum Kompromittieren eines Systems missbrauchen.(author unknown)02921839077878952869

Abysssec Research 1) Advisory information Title Rainbowportal Multiple Remote Vulnerabilities Version Rainbow 2.0 Production/Stable (2.0.0.1881e) VS 2005 | VS 2008 .NET 2.0-3.5 Discovery http://www.abysssec.com Vendor http://www.rainbowportal.net Impact Ciritical Contact shahin [at] abysssec.com , info [at] abysssec.com Twitter @abysssec 2) Vulnerability Information Class 1- Login Weakness 2- Non-persistent XSS 3- Persistent XSS 4- SQL Injection Impact [...]admin

Abysssec Research 1) Advisory information Title Rainbowportal Multiple Remote Vulnerabilities Version Rainbow 2.0 Production/Stable (2.0.0.1881e) VS 2005 | VS 2008 .NET 2.0-3.5 Discovery http://www.abysssec.com Vendor http://www.rainbowportal.net Impact Ciritical Contact shahin [at] abysssec.com , info [at] abysssec.com Twitter @abysssec 2) Vulnerability Information Class 1- Login Weakness 2- Non-persistent XSS 3- Persistent XSS 4- SQL Injection Impact [...]admin

19 posts left…

So Pyloris doesn’t work particularly well for port exhaustion on the server, but what if we can exhaust the connections on the client to better meter out traffic? That would make it easier for a MITM to see each individual request if it worked. So I started down a rather complicated path of using a mess load of link tags on an HTTP website trying to affect the connections on the HTTPS version of the same domain. No joy. It turns out that the limits placed on one port don’t affect what happens on another (at least in Firefox). So while I can exhaust all the connections to a domain over a single port I can’t do anything using HTTPS - or so it seemed (unless I was willing to muddy the water further by sending a bunch of requests that I knew are a certain size to the HTTPS site - which just seemed more painful than helpful).

Then, based on some earlier research I stormed into id’s office and I started bitching that there was no point in trying to stop port exhaustion if they were going to allow tons of connections, just over multiple sockets anyway. As the words came out of my mouth I realized I had come up with the answer - a ton of webservers. I guessed that there must be some upper bound of outbound connections and it’s probably at or less than 130. You should have seen id’s face as I asked him to set up 130 connections / 6 connections per socket = 22 web-servers for me. Hahah… I thought he’d kill me.

It turns out it’s nowhere near 130 open connections. Firefox sets a rather arbitrary 30 connection limit. So if you can create 5 open web-servers and exhaust 30 connections and only free up one long enough to allow the victim to download one request at a time, I think we’re in business. Makes sense in theory. The problem is that it’s REALLLLY slow. I mean… painful. In my testing it seemed more like the server was broken entirely from the victim’s perspective. But eventually… and in some cases I mean minutes later - it would load. I’m sure that the attack could be optimized to work based on the fact that no more packets are being sent when the image gets downloaded or whatever… which would signal the program to free up a connection. This is opposed to my crapola time based solution combined with chunked encoding to force the connection to stay open without downloading anything that I came up with for testing. So I bet this attack could work if someone put some tender loving care into it, but it was kind of a huge waste of time for me personally - and for poor id.

Incidentally, for those who have never seen or met id, and would like to know a little about the other side of webappsec that I don’t talk about much here (the configuration, operating system and network), you’re chance is nearing. There’s a rumor that he’ll be speaking at Lascon in October. He’ll be talking on how he’s managed to secure ha.ckers.org for all these years despite how much of a target I’ve made it. Should be fun.

19 posts left…

So Pyloris doesn’t work particularly well for port exhaustion on the server, but what if we can exhaust the connections on the client to better meter out traffic? That would make it easier for a MITM to see each individual request if it worked. So I started down a rather complicated path of using a mess load of link tags on an HTTP website trying to affect the connections on the HTTPS version of the same domain. No joy. It turns out that the limits placed on one port don’t affect what happens on another (at least in Firefox). So while I can exhaust all the connections to a domain over a single port I can’t do anything using HTTPS - or so it seemed (unless I was willing to muddy the water further by sending a bunch of requests that I knew are a certain size to the HTTPS site - which just seemed more painful than helpful).

Then, based on some earlier research I stormed into id’s office and I started bitching that there was no point in trying to stop port exhaustion if they were going to allow tons of connections, just over multiple sockets anyway. As the words came out of my mouth I realized I had come up with the answer - a ton of webservers. I guessed that there must be some upper bound of outbound connections and it’s probably at or less than 130. You should have seen id’s face as I asked him to set up 130 connections / 6 connections per socket = 22 web-servers for me. Hahah… I thought he’d kill me.

It turns out it’s nowhere near 130 open connections. Firefox sets a rather arbitrary 30 connection limit. So if you can create 5 open web-servers and exhaust 30 connections and only free up one long enough to allow the victim to download one request at a time, I think we’re in business. Makes sense in theory. The problem is that it’s REALLLLY slow. I mean… painful. In my testing it seemed more like the server was broken entirely from the victim’s perspective. But eventually… and in some cases I mean minutes later - it would load. I’m sure that the attack could be optimized to work based on the fact that no more packets are being sent when the image gets downloaded or whatever… which would signal the program to free up a connection. This is opposed to my crapola time based solution combined with chunked encoding to force the connection to stay open without downloading anything that I came up with for testing. So I bet this attack could work if someone put some tender loving care into it, but it was kind of a huge waste of time for me personally - and for poor id.

Incidentally, for those who have never seen or met id, and would like to know a little about the other side of webappsec that I don’t talk about much here (the configuration, operating system and network), you’re chance is nearing. There’s a rumor that he’ll be speaking at Lascon in October. He’ll be talking on how he’s managed to secure ha.ckers.org for all these years despite how much of a target I’ve made it. Should be fun.

20 posts left…

Pyloris is a python version of Slowloris, and since it is written in python it’s SSL version is thread safe. So what better way to lock up an SSL/TLS Apache install (given that Apache still hasn’t fixed their DoS)? Well, one of the big problems attackers have when trying to decipher SSL/TLS traffic is the fact that browsers not only send a lot of request down a single connection but they also connect use a bunch of open connections over separate sockets. What if we could use pyloris to exhaust all but one open socket?

Well it turns out that while this sorta works, there are a lot of issues with the concept. Firstly, it requires Apache. Secondly the server can’t be using a load balancer (assuming the load balancer isn’t using Apache itself). Thirdly it requires that there are no other users on the system or there will be a seriously annoying user experience for the poor victim who can’t reach the site that the man in the middle is trying to decipher traffic from. Alas… So while this didn’t work particularly well in my testing, I’m certain with more thinking someone can figure out a way to do this.

20 posts left…

Pyloris is a python version of Slowloris, and since it is written in python it’s SSL version is thread safe. So what better way to lock up an SSL/TLS Apache install (given that Apache still hasn’t fixed their DoS)? Well, one of the big problems attackers have when trying to decipher SSL/TLS traffic is the fact that browsers not only send a lot of request down a single connection but they also connect use a bunch of open connections over separate sockets. What if we could use pyloris to exhaust all but one open socket?

Well it turns out that while this sorta works, there are a lot of issues with the concept. Firstly, it requires Apache. Secondly the server can’t be using a load balancer (assuming the load balancer isn’t using Apache itself). Thirdly it requires that there are no other users on the system or there will be a seriously annoying user experience for the poor victim who can’t reach the site that the man in the middle is trying to decipher traffic from. Alas… So while this didn’t work particularly well in my testing, I’m certain with more thinking someone can figure out a way to do this.

21 posts left…

If you’re familiar with XSHM this is going to look awfully similar (but better). When a script creates a new popup (or tab) it retains control over where to send it at a later date. I talked about this concept before. But let’s see what else can be done. What if the attacker uses the history.length function to calculate how many pages a user has visited after they left the tab for wherever they landed. The attacker could do something like this:

a.location = &apos;data:text/html;utf-8,<script>alert(history.length);history.go(-1);<\/script>&apos;;

By setting either a recursive setTimeout or using some manual polling mechanism, the attacker can (in this case) cause a popup which monitors how many pages they’ve gone. Normally it wouldn’t cause a popup, the attacker would redirect to another domain that they had access to which would do the same history.length check. Voila. The user only sees a brief white flash and then the same page they were just on - as if nothing happened. They’d probably just think their browser is messing up again. This could be helpful in a number of esoteric situations where the number of pages visited may change, or you may want to force them through several flows (and back and forth again) all with a single mouse click - giving you authority to popup in the first place. The best part is that this will follow them while they surf for as long as both windows stay open.

21 posts left…

If you’re familiar with XSHM this is going to look awfully similar (but better). When a script creates a new popup (or tab) it retains control over where to send it at a later date. I talked about this concept before. But let’s see what else can be done. What if the attacker uses the history.length function to calculate how many pages a user has visited after they left the tab for wherever they landed. The attacker could do something like this:

a.location = &apos;data:text/html;utf-8,<script>alert(history.length);history.go(-1);<\/script>&apos;;

By setting either a recursive setTimeout or using some manual polling mechanism, the attacker can (in this case) cause a popup which monitors how many pages they’ve gone. Normally it wouldn’t cause a popup, the attacker would redirect to another domain that they had access to which would do the same history.length check. Voila. The user only sees a brief white flash and then the same page they were just on - as if nothing happened. They’d probably just think their browser is messing up again. This could be helpful in a number of esoteric situations where the number of pages visited may change, or you may want to force them through several flows (and back and forth again) all with a single mouse click - giving you authority to popup in the first place. The best part is that this will follow them while they surf for as long as both windows stay open.

22 posts left…

While thinking about the previous issue and listening to Jeremiah’s preso and talking with the guys at Microsoft I got to thinking about cookie clobbering. Let’s say that Microsoft thinks HTTP cookies overwriting secure cookies is a big enough problem to fix. Let’s walk through the use cases. Let’s say there is a separate place for secure cookies that can’t be overwritten by non-secure cookies. Does that mean two cookies are replayed in HTTPS space, or that the HTTPS cookie always wins? Okay… let’s say it wins and the secure flag cookie cookie is the only one sent. Well let’s not forget about Jer’s cookie clobbering script.

When an attacker forces overwriting of the cookie jar, they get the exact same effect. Now the victim has no cookies secure or otherwise if the global cookie jar stays the same size and it remains a LIFO system. So now you’re saying, well the attacker can just use a SSL/TLS enabled cookie clobbering scripts - you’re right! So now there has to be a per-site container… or something - and doesn’t that completely defeat the purpose of the upper limits on cookies anyway? Now DoS conditions become an issue with overwriting the disc with tons of huge cookies, and so on. Anyway… this probably needs a lot more thought, and I’m certainly not advocating “fixing” this, just to end up with a worse situation than we already have. But certainly secure cookies shouldn’t be clobbered by HTTP cookies - in my opinion.

22 posts left…

While thinking about the previous issue and listening to Jeremiah’s preso and talking with the guys at Microsoft I got to thinking about cookie clobbering. Let’s say that Microsoft thinks HTTP cookies overwriting secure cookies is a big enough problem to fix. Let’s walk through the use cases. Let’s say there is a separate place for secure cookies that can’t be overwritten by non-secure cookies. Does that mean two cookies are replayed in HTTPS space, or that the HTTPS cookie always wins? Okay… let’s say it wins and the secure flag cookie cookie is the only one sent. Well let’s not forget about Jer’s cookie clobbering script.

When an attacker forces overwriting of the cookie jar, they get the exact same effect. Now the victim has no cookies secure or otherwise if the global cookie jar stays the same size and it remains a LIFO system. So now you’re saying, well the attacker can just use a SSL/TLS enabled cookie clobbering scripts - you’re right! So now there has to be a per-site container… or something - and doesn’t that completely defeat the purpose of the upper limits on cookies anyway? Now DoS conditions become an issue with overwriting the disc with tons of huge cookies, and so on. Anyway… this probably needs a lot more thought, and I’m certainly not advocating “fixing” this, just to end up with a worse situation than we already have. But certainly secure cookies shouldn’t be clobbered by HTTP cookies - in my opinion.