E. <bellyup@the.bar> wrote:
> The point Leythos and others have been trying to make, which has been
> lost in the noise, is about having layers, layers and more layers of
> security.
> No single, double, triple or quadruple exploit should ever be able to
> penetrate anything if you have proper layers in place.

This will not work, if one does not understand how to make it impossible
for things to happen, because one is understanding exactly how things work,
but only how to buy products and believe in advertizing.

Then you can have "layers and layers and layers" of such "security",
and everything will be as unsecure as ever.

And I don't have the impression that "Leytos" understands anything he's
writing about. All of his arguments contain "real" firewalls (a term,
he maybe heard in advertizing) or "better and not comparable to" (but
without any argument about what's going on in a technical view, so there
is a reason one could see, and not only believing).

As a matter of fact, he doesn't understand a bit of network protocols,
he does not understand how NAT works, he does not understand why NAT
is a problem for active FTP, which means having also a TCP socket back
from server to the client and which needs stateful inspection and
exceptions for NAT, he does not understand what ICMP is and why it's
not evil, but a needed part of any IP implementation, he does not
understand anything about all that stuff which is needed to talk about
network security.

All what he offers, is believing in the advertizing of the manufacturers
of the "professional security products".

And this I will never do, of course I want to see what's behind their
products.

> > But until I see a proof here, I will not believe that. Sorry.
> If I could recall the exact details, i'd post them.

Would be nice ;-)

> If you really want more reading, I would recommend subscribing to the
> bugtraq mailing lists @ securityfocus.com

Of course I'm reading bugtraq.

> (rant) what really pisses me off is when a client asks for your advice
> (and pays for it), then takes the advice of the son-of-a-neighbour who
> knows everything because he works in retail PC shop over yours. Advice
> like "you don't actually need encryption on WLAN's, just changing the
> SSID to something non-standard will protect you" (and then broadcasting
> it and handing out IP's to everyone within range, i might add) makes me
> want to start cutting the stupid gene out of peiople with a blunt nail
> file.
> Sitting out front in the driveway and sniffing his email
> username/password and handing it to him convinced him that
> son-of-neighbour was a loon that shouldn't be allowed to touch a
> computer again, ever.
> (/rant)

;-)

> English version: <http://www.pcwelt.de/know-how/extras/103039/> German
> version: <http://www.pcwelt.de/news/sicherheit/103013/>

Yes. This was not a bug in the Windows-Firewall, but a bug in the
setup route which does the software update from a machine, which
uses Windows XP SP1 with configured ICF and an exception for the
LAN for file- and printservices, and is then updated to Windows XP
SP2. Afterwards, you have to configure the Windows-Firewall manually,
because the setup routine of the update fails to convert the settings
correctly.

> Oh, and here's one about ICMP...

> In our sample scenario, a web-client (10.0.0.1, TCP port 3270) is
> downloading a file from a web-server (192.168.0.1, TCP port 80). If the
> TCP/IP implementations of both end-points are vulnerable,you can attack
> any of them, to cause the TCP connection to be aborted.
> Let's suppose we have OS-fingerprinted the client, and know it runs
> Windows. As stated in one of my other other e-mails, Windows chooses the
> port numbers for its outgoing connections from the range 1024-4999.
> So we could run our tool icmp-reset
> (http://www.gont.com.ar/tools/icmp-attacks) as-follows:
> # icmp-reset -c 10.0.0.1:1024-4999 -s 192.168.0.1:80 -t client -r 128
> This simple command would reset the connection. The tool just needs to send
> 3976 packets. With a 128kbps link (more than usual nowadays), we would
> need about 12 (twelve) seconds to reset the connection (and I'm
> considering the worst case, that is, that the port number in use by the
> client is 4999, so it would be our last try that would reset the
> connection).

This DoS attack is not a bug in Windows-Firewall, but in the TCP
implementation of Windows' TCP/IP stack. It works with or without any
"Firewall".

It can be detected by some IDS, though.

> This is a generic problem of common Personal Firewall products which are
> accept shortcuts or provide an interface that enables to click without
> require a password for controlled actions (acting as server -listening
> ports-, executing another program, connecting to another computer etc.).

This is what Chippy's autoclicker tool uses in our test. What the
incident description is missing here, is, that also a password does
not help, if it can be entered by the normal user, too.

And this is why I'm mentioning opening popups as a security flaw.

> Proof of Concept;
> -------------------------------------------------------------------
> 2 Proof of Concepts attached to advisory (also some other POCs for some
> firewalls)

You could test Chippy's autoclicker, too. Here they come:

For Kerio: http://copton.net/vortraege/pfw/kerio-autoklick.c
For Symantec: http://copton.net/vortraege/pfw/norton-autoklick.c

> Solution;
> -------------------------------------------------------------------
> All firewalls should ask password for all kind of "Allow" actions. In
> fact passwords can be fooled because of its nature but it is the best
> user friendly / secure solution for protection.

This is wrong. It's not a solution for this problem, because an
autoclicker can wait until the user entered his password, and change
settings right before the "Personal Firewall" receives the commit.

The only way to prevent this would be not to show such popups for
normal users.

Yours,
VB.
--
MAC-Filtering bringt so viel Schutz vor "Hackern" wie Zeitungspapier vor
einer Atombome. (MAC filtering is protecting against "hackers" like newsprint
is protecting against a nuclear bomb)
- Christian Forler in de.comp.security.misc