Why do I need a software firewall?

Todd H. <comphelp@toddh.net> wrote:
> So, I agree that spending time with host based configuration on every
> device in the home can achieve the same security posture at a given
> instant, but what your arguments are ignoring is the value of defense
> in depth.

-v plz

> But...the difference is in terms of the likelihood of "what if the
> software firewall crashes, is diabled by nefarious software run on the
> machine, or (the most likely case) is disabled by the user at the
> direction of every tom dick and harry level 1 support technician that
> wants to fire a shotgun in the dark trying to debug some mysterious
> problem?

If the software firewall crashes, which I'm recommending, then you have a
kernel panic, which is called "blue screen" on Windows, because the
Windows-Firewall just configures the filtering software in Windows' kernel.

If malware already is running on the system, no protection is needed
any more, because then this machine has to flatten and rebuild anyway.
Also a hardware firewall cannot protect this machine any more.

If your support technician calls you to fool aroung, and you're doing
it, you're losing in any case. If users are fooling aroung, then nonsense
will happen, regardless of what you're trying to secure. This has nothing
to do with firewalls.

> > Usually, it is very easy to stop any servers on your Windows box - just
> > use Torsten's script on ntsvcfg.de or use www.dingens.org.
> You vasty overestimate the average user's patience for this sort of
> configuration. This requires user intervention and is simply something
> folks won't do, and can manage to screw up.

Hundreds of thousands of people are doing it already with these tools,
maybe millions.

> > Or use Windows XP SP2 with actual patches in the default
> > configuration; it is NOT vulnerable to any network based attack
> > because the Windows- Firewall is switched on by default. A hardware
> > device will not make it more secure than secure against
> > network-based attacks.
> True... but... what percentage of general users are using Windows XP
> SP2?

This is a problem, yes. And Microsoft is not solving it by making i.e.
a service pack for Windows 2000, which does the same for this OS.

Microsoft ist causing the security desaster, and afterwards they want
money from their customers to solve it again.

> > This is just nonsense. Why should one do that? Why should the user
> > make the "software firewall" "go down"?
> Nonsense? Ever observed a typical user on the phone with a tech
> support agent for even the simplest networking problem?

Yes. In spite of shit happening, it remains to be shit.

> One of the
> first things the support technician has them do is disable any
> software firewalls to eliminate the possibility that they're
> interfering.

I believe you, that many idiots are working as supporters - why not?
Many idiots are working as programmers, as admins, as politicians and
as clerks, so why not as supporters? :-/

But to what end will this discussion lead to? Securing the user against
himself/herself and against the dumb supporter will fail anyway.

> The world is well aware that NAT doesn't provide security in and of
> itself... but here's the newsflash: most of the devices if not all
> also include SPI firewalls enabled by default in addition to the
> obscuring of NAT. And nearly all require no configuration at all.
> You plug the thing in and every machine behind it becomes a lot less
> vulnerable to network based attacks. For a whopping $60.

The devices I saw all required extra filtering configuration to
filter out packets from outside with spoofed source addresses. And many
of the stateful inspection implementations of FTP are so bad, that
those boxes often leave vulnerable, what's behind.

What you're claiming here, gives me a new hope - perhaps the manufacturers
will learn at last.

Did you check that conscientiously, what you're telling here?

> > To make such a router secure, you have to configure it for
> > filtering, too. Esspecially, you have to filter out any packet,
> > which seems to come from inside, but arrives the outside network
> > interface. And even more, many stateful inspection implementations
> > i.e. for FTP are very unsecure.
> How many of the general users I'm talking about here are running ftp
> servers at home?

This is not the problem. I'm talking about the possibility to use FTP
clients, not servers.

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

Leythos <void@nowhere.lan> wrote:
> And you're wrong - the point of the router is to block IN-BOUND traffic
> as that's what mostly causes problems for users.

The problems I'm referencing are spoofed source addresses,
which seem to come from inside, and are not blocked because the filtering
rules misinterpret the packets as not from the outside, and b0rken FTP
inspection, which leads into making traffic possible again.

Both are problems with blocking what you're calling "in-bound traffic".

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

Leythos <void@nowhere.lan> wrote:
> In article <433e5519@news.uni-ulm.de>, bumens@dingens.org says...
> > Leythos <void@nowhere.lan> wrote:
> > > So, I'll stick with what
> > > I'm sure of, and I'm sure that SP2 firewall is not something I will
> > > trust.
> > May I ask you to offer _one_ _single_ technical argument for this point
> > of view now at last?
> Sure, as said several times before - the SP2 firewall runs on the same
> PC as the user who is most likely running as a local administrator and
> has control of the personal firewall.

So you're declining any host based packet filtering on Windows, or you're
requesting not to work as administrator.

With the first I would disagree, with the second, I agree.

I see, you don't have technical critics on the implementation of the
Windows-Firewall, though.

> If that's not enough of a
> TECHNICAL REASON then you are completely missing what security is really
> about.

"Leythos", could we please stop the pure polemics now? I don't want to
have a "discussion" by offending each other all the time.

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

Leythos <void@nowhere.lan> wrote:
> > The problems I'm referencing are spoofed source addresses,
> > which seem to come from inside, and are not blocked because the filtering
> > rules misinterpret the packets as not from the outside, and b0rken FTP
> > inspection, which leads into making traffic possible again.
> > Both are problems with blocking what you're calling "in-bound traffic".
> And a NAT Router is still better protection than Windows Firewall

I'm just stating now, that this is what you're claiming again and again,
and you're refusing to offer one single argument for in spite of the fact,
that I'm requesting you to offer one again and again.

> so,

ex falso quodlibet

> since few people run FTP servers in their Homes, it's still 500% better
> to use a NAT device than Windows Firewall - since Windows Firewall won't
> catch it either.

I'm not talking about FTP servers here, but about FTP clients.

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

Leythos <void@nowhere.lan> wrote:
> > > In article <433e5519@news.uni-ulm.de>, bumens@dingens.org says...
> > > > Leythos <void@nowhere.lan> wrote:
> > > > > So, I'll stick with what
> > > > > I'm sure of, and I'm sure that SP2 firewall is not something I will
> > > > > trust.
> > > > May I ask you to offer _one_ _single_ technical argument for this point
> > > > of view now at last?
> > > Sure, as said several times before - the SP2 firewall runs on the same
> > > PC as the user who is most likely running as a local administrator and
> > > has control of the personal firewall.
> > So you're declining any host based packet filtering on Windows, or you're
> > requesting not to work as administrator.
> > With the first I would disagree, with the second, I agree.
> > I see, you don't have technical critics on the implementation of the
> > Windows-Firewall, though.
> No, you miss the point - as usual - the firewall is breachable and even
> more so if the user is running as a Administrator. The firewall doesn't
> even block file/printer sharing in some situations based on how the user
> told the setup/install it was being used.

It blocks it _by_ _default_. So this is just wrong, what you're claiming
here.

> even Zone Alarm, if installed before
> connecting the network cable, is better than anything MS has presented.

And this is, what you're claiming (everytime), and are refusing to
offer one single argument for.

Do you know, that you're wrong, or do you have big problems with logics?

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

Leythos <void@nowhere.lan> wrote:
> the NAT device will protect
> the user regardless of the settings in the Windows Firewall

The Windows-Firewall will protect the user regardless of the settings
of the NAT device. So what?

> and since
> the File/Printer sharing is enabled by default

This is just wrong. To check this, one for example could do a nmap -P0
onto a box with Windows XP SP2 and actual patches in the default
configuration. Everybody will see then, that this is wrong, what you're
claiming.

> since the User manages
> the Windows Firewall

And the user is managing the NAT router, too. So what?

> since applications can also manage the Windows
> Firewall, etc...

If the computer of the user is compromized already, _every_ "Firewall"
is useless now. Also a NAT router cannot protect a PC, which is
compromized already.

> The NAT router is still better than Windows simple non-
> firewall.

No arguments yet, with the exception of easy to test wrong claims.

> Now, if you think I've not stated anything technical, read it
> again, try and learn a little about what I've typed, then don't come
> back if you don't understand.

I can see now, that anything you're stating here is wrong or at least
without any relevance. But you're getting better now: you're stating
_anything_ at last.

It's a pity, that it's all completely useless.

> > I'm not talking about FTP servers here, but about FTP clients.
> NAT does not break FTP, if you think so, then you know little about
> networking.

Please explain, how active and passive FTP are working, and what the
difference is. If you have problems with it, try to read RFC 959 first.

Of course, NAT is a problem for FTP clients. But, after all you were
writing, I'm not very surprised, that you even don't know how FTP works.

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

Leythos <void@nowhere.lan> wrote:
> What about the way that applications can
> make changes to the Windows firewall without the user knowing?

If the computer is compromized already, no filtering software will
help to secure this computer any more.

And, _every_ "Personal Firewall" has the same problem. You claimed
that Zonealarm would be better, so this couldn't be your argument then.

> What
> about the way that Windows Firewall is easier to mess up than any other
> firewall on the market

Please explain. Do you have a technical argument for this at last?

> > > even Zone Alarm, if installed before
> > > connecting the network cable, is better than anything MS has presented.
> > And this is, what you're claiming (everytime), and are refusing to
> > offer one single argument for.
> What refusing

I'm missing your argument for that. I'm asking it now for the last time:

WHY - and explain in detail, please - do you think that? What exactly is
worse with Windows-Firewall compared to Zonearalm in a technical view?

What problems does Zonealarm have, I explained in detail already - if you
forgot this, I can send you the references to re-read.

Please explain this now, or just shut up for your own sake - you're getting
more and more ridiculous arguing without _any_ facts.

> you're refusing to see the logic and technical details.
> Have you ever used a personal firewall other than Windows SP2 firewall?

I'm not using the Windows-Firewall and I'm not using a "Personal Firewall".
Why should I?

We tested both _in_ _detail_, though. The testing report for the "Personal
Firewalls" is here:

http://www.dingens.org/pf-bericht/bericht.html

A lecture about this topic, you'll find here:

http://www.ulm.ccc.de/chaos-seminar/personal-firewalls/

Unfortunately for many of the people who are reading here, this all is in
German language. Perhaps we will find someone to translate in future.

But just ask one of your friends (if you have any), who are understanding
German language, to translate.

More about the CCC you're finding here BTW: https://www.ccc.de

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

Volker Birk <bumens@dingens.org> writes:
> Leythos <void@nowhere.lan> wrote:
> > the NAT device will protect
> > the user regardless of the settings in the Windows Firewall
>
> The Windows-Firewall will protect the user regardless of the settings
> of the NAT device. So what?

Harder to crash, harder to disable, something separate to have to
disable. Security in depth.

> And the user is managing the NAT router, too. So what?

A vast majority of users are set and forget types, and if there's no
easy way to get at it, it won't ever BE disabled.

> If the computer of the user is compromized already, _every_ "Firewall"
> is useless now. Also a NAT router cannot protect a PC, which is
> compromized already.

To borrow your type of discussing, let me say:
This is nonsense.

A NAT router certainly can protect a compromised PC. Consider the
common case of malware opening a listener as a back door. It's
awfully hard to connect to that listener if there's an added layer of
firewalling that prevents a remote attacker from seeing past the
router to get to the listening back door.

More sophisticated malware, or course does exist whereby an active
outbound connection is made to join a botnet, or make another remote
control connection. However, to say that a NAT router cannot ever
protect a compromised PC is indeed nonsense.

The value of multi-layer protection or defense in depth is
lost on you.

The whole point of this discussion is that various classes of threats
are mitigated by each tool, and both software and hardware firewalls
are a prudent complimentary solution as part of a protection
strategy.

Best Regards,
--
Todd H.
http://www.toddh.net/

Todd H. <comphelp@toddh.net> wrote:
> Volker Birk <bumens@dingens.org> writes:
> > Leythos <void@nowhere.lan> wrote:
> > > the NAT device will protect
> > > the user regardless of the settings in the Windows Firewall
> > The Windows-Firewall will protect the user regardless of the settings
> > of the NAT device. So what?
> Harder to crash

Please show one single way to crash the Windows-Firewall from outside.
After you showed, I will believe.

> harder to disable

*plug* *plug* vs. *click* *click* - Maybe you're judging this so.

> something separate to have to
> disable.

Yes. And?

> Security in depth.

Please explain. If you want to say, maybe one could use a filtering NAT
router _and_ the Windows-Firewall, I'd agree. Why not?

I've nothing against filtering NAT devices. The claim, that filtering
NAT devices are better to secure from network based attacks than the
Windows-Firewall is just wrong, though.

The claim, that a host based packet filter like the Windows-Firewall
is better to secure from network based attacks than filtering NAT devices,
is wrong, too BTW (if they're filtering and not only implementing NAT).

> > And the user is managing the NAT router, too. So what?
> A vast majority of users are set and forget types, and if there's no
> easy way to get at it, it won't ever BE disabled.

But sometimes bypassed or abused. You can read in Joab Jackson's
interesting summary about a discussion on the IETF discussion list here
for example:

http://technology.newsforge.com/arti...&tid=28&tid=31

| That NATs themselves are used as security devices - in place of firewalls -
| led to more problems. It was not a role they were designed to perform.
| ...
| NATs also have security issues. Since NAT boxes must forward packets from
| the outside IP addresses to internal ones, it must change forwarding
| information. "Basically, once you've committed to rewriting the forwarding
| information in an IP datagram, then it's open season on all manner of
| horrible opportunities for intermediaries to engage in Internet abuse,"
| wrote James Woodyatt.

> > If the computer of the user is compromized already, _every_ "Firewall"
> > is useless now. Also a NAT router cannot protect a PC, which is
> > compromized already.
> To borrow your type of discussing, let me say:
> This is nonsense.
> A NAT router certainly can protect a compromised PC. Consider the
> common case of malware opening a listener as a back door. It's
> awfully hard to connect to that listener if there's an added layer of
> firewalling that prevents a remote attacker from seeing past the
> router to get to the listening back door.

Yes. And the malware could also connect to the outside, and you lose.

I don't understand, why so many people believe in this advertizing
nonsense, that a compromized machine can be protected any more by a
"Personal Firewall" or even a NAT router.

If software is running on the box, which is implemented to harm, it will
harm. This is how computers are working, the software which is running
makes the computer to do things, wether they're wanted or not. Semantics
are no obect.

Or is this the "better _some_ security than nothing" thing you're claiming?
Better to make it a little bit more difficult for an attacker than doing
nothing?

Well, attackers do know today, that there are many NAT boxes in the wild,
don't they? What do you think, if I would hack such a remote control
software we're talking about ("phoning home", "Trojan"), would I check
if I have an internal address, and if, then would I connect to the outside
instead of listening to an interface with 192.168.0.anything?

Of course I would.

So the deal to secure a PC against malware must be not to get malware
running on the PC. Is this so difficult to understand?

> More sophisticated malware, or course does exist whereby an active
> outbound connection is made to join a botnet, or make another remote
> control connection.

Yes, of course, and the rest of the malware vanishes. So what extra
security did NAT bring here? It changes the malware slightly. That's
it. I would not call this "security".

> However, to say that a NAT router cannot ever
> protect a compromised PC is indeed nonsense.

It cannot protect a PC from being compromized any more, because the
PC is already compromized. Hard to understand?

> The value of multi-layer protection or defense in depth is
> lost on you.

No, not at all. If multi-layer protection isn't just an excuse for
"I don't know enough about computer security and this network protocol
stuff, but I'm using many, many devices in layers, so I have the hope
that one of them will work anyway", then multi-layer protection can
be very useful.

As a matter of fact, only the term is fishy, better let's talk about
security zones.

But "hope" usually is somewhat like an antonym to "being secure".
If we're talking about multi-layer protection, or better about security
zones, then hope cannot be our goal, but reading protocols and deciding
what to do to be secure against different attack vectors.

> The whole point of this discussion is that various classes of threats
> are mitigated by each tool, and both software and hardware firewalls
> are a prudent complimentary solution as part of a protection
> strategy.

No.

The points of the discussion are the claims of Lythos. He claimed:

1) NAT devices are better to secure against network attacks than the
Windows-Firewall

2) Zonealarm is better to secure against various attacks than the
Windows-Firewall

Both claims are wrong. Correct would be:

1) Filtering NAT devices are as good as the Windows-Firewall in default
configuration to secure against network attacks, if they're properly
configured, because both make network based attacks impossible then

2) Zonealarm is as good as the Windows-Firewall to secure against network
based attacks. The rest of the features are not working as described,
and some of the advertizing is just nonsense, like "Stealthing". But
unlike the Windows-Firewall, Zonealarm opens additional attack vectors
for the Windows-System it's running on, because it offers the user
popups with security relevant questions, the user is not able to decide
correctly, and it makes the PC vulnerable to the SelfDoS attack.

His claim, the Windows-Firewall is "a piece of crap" and badly implemented,
we can forget, of course. He had no single argument for that.

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

Volker Birk wrote:
> Leythos <void@nowhere.lan> wrote:
>
>>And you're wrong - the point of the router is to block IN-BOUND traffic
>>as that's what mostly causes problems for users.
>
> The problems I'm referencing are spoofed source addresses,
> which seem to come from inside, and are not blocked because the filtering
> rules misinterpret the packets as not from the outside, and b0rken FTP
> inspection, which leads into making traffic possible again.
>
> Both are problems with blocking what you're calling "in-bound traffic".

At least some of the cheap NAT/Router/"Firewall" devices (I know Leythos
does not consider them to be firewalls, I'm not arguing that they are,
they just claim to have firewalls) will reject packets from the WAN
point that spoofed source IPs claiming to have originated in the LAN. So
in this instance the cheap HW device is clearly better than the Windows
firewall because the windows firewall has no way of knowing whether the
packet is coming from the internet with a spoofed address of from the
local network.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Volker Birk <bumens@dingens.org> writes:
> Todd H. <comphelp@toddh.net> wrote:
> > Volker Birk <bumens@dingens.org> writes:
> > > Leythos <void@nowhere.lan> wrote:
> > > > the NAT device will protect
> > > > the user regardless of the settings in the Windows Firewall
> > > The Windows-Firewall will protect the user regardless of the settings
> > > of the NAT device. So what?
> > Harder to crash
>
> Please show one single way to crash the Windows-Firewall from outside.
> After you showed, I will believe.

Today: Email attachment with proper social engineering for grandma to click
on it, leverage a zip buffer overflow, executable overflow turns of
the windows firewall.

Future potential: as yet unkown vulnerability in the program or OS
that brings down the protection directly.

> > harder to disable
>
> *plug* *plug* vs. *click* *click* - Maybe you're judging this so.

Yes...any time a support technician would have to convince my 70 year
old mother say, has to crawl behind the desk out of the chair and
recable something, I'd say it's harder to disable than "Click this
icon in the bottom right of the screen, now click Disable."

I'll also point out that clicking on no executable email attachment
would EVER recable her network for her.

>
> > Security in depth.
>
> Please explain. If you want to say, maybe one could use a filtering NAT
> router _and_ the Windows-Firewall, I'd agree. Why not?

Yes...bejesus! He sees the light!

Volker, that is what I've been advocating in this whole thread.
Remember way back to the original post where the guy with a firewall
device asked why he needed a software firewall too?

And please don't argue Leythos's points with me please.

> His claim, the Windows-Firewall is "a piece of crap" and badly
> implemented, we can forget, of course. He had no single argument for
> that.

As personal firewalls go, though, Windows Firewall is inferior because
it, while running, is NO better than a border firewall device, and
more likely to go down.

A personal firewall that actually has the ability to inercept/track
outbound traffic on a per-application basis would be a better choice
as complimentary protection to a hardware based SPI firewall device.

Best Regards,
--
Todd H.
http://www.toddh.net/

Todd H. <comphelp@toddh.net> wrote:
> > Please show one single way to crash the Windows-Firewall from outside.
> > After you showed, I will believe.
> Today: Email attachment with proper social engineering for grandma to click
> on it, leverage a zip buffer overflow, executable overflow turns of
> the windows firewall.

This is not what I meant with "from outside". Every technical security
system can be compromized with a social engineering attack, so this means
nothing.

> Future potential: as yet unkown vulnerability in the program or OS
> that brings down the protection directly.

The same potential is with every technical security system. So what?

I see, that you have no idea how to crash the Windows-Firewall from
outside. But don't be too sad - I don't have one either ;-)

> > > Security in depth.
> > Please explain. If you want to say, maybe one could use a filtering NAT
> > router _and_ the Windows-Firewall, I'd agree. Why not?
> Yes...bejesus! He sees the light!

I never contradicted here. Please read my postings.

> Volker, that is what I've been advocating in this whole thread.
> Remember way back to the original post where the guy with a firewall
> device asked why he needed a software firewall too?

I don't think, we're too different in our views here, too.

> And please don't argue Leythos's points with me please.

OK. This I can understand ;-)

> > His claim, the Windows-Firewall is "a piece of crap" and badly
> > implemented, we can forget, of course. He had no single argument for
> > that.
> As personal firewalls go, though, Windows Firewall is inferior because
> it, while running, is NO better than a border firewall device, and
> more likely to go down.
> A personal firewall that actually has the ability to inercept/track
> outbound traffic on a per-application basis would be a better choice
> as complimentary protection to a hardware based SPI firewall device.

I cannot see that, because I can easily proof, that no "Personal Firewall"
can intercept/track every outbound traffic, but only the traffic of
applications, which want to be controllable.

This means no security at all.

But many "Personal Firewalls" have huge drawbacks in security against the
Windows-Firewall.

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

Flash Gordon <spam@flash-gordon.me.uk> wrote:
> At least some of the cheap NAT/Router/"Firewall" devices (I know Leythos
> does not consider them to be firewalls, I'm not arguing that they are,
> they just claim to have firewalls) will reject packets from the WAN
> point that spoofed source IPs claiming to have originated in the LAN.

Yes. And I hope, that in future more and more such devices will be sold
configured like that.

> So
> in this instance the cheap HW device is clearly better than the Windows
> firewall because the windows firewall has no way of knowing whether the
> packet is coming from the internet with a spoofed address of from the
> local network.

You cannot compare that, because a user, who connects his computer with
the Internet directly and is using the Windows-Firewall has no "inside"
or "outside" addresses, because she/he is not using NAT.

If the user has a NAT router, then of course it should be configured
to filter, wether the user is using an extra Windows-Firewall or not.

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

Volker Birk <bumens@dingens.org> writes:

> I don't think, we're too different in our views here, too.

Then, in the future, when you have the urge to say "this is nonsense"
do think before you type.


--
Todd H.
http://www.toddh.net/

Todd H. <comphelp@toddh.net> wrote:
> Volker Birk <bumens@dingens.org> writes:
> > I don't think, we're too different in our views here, too.
> Then, in the future, when you have the urge to say "this is nonsense"
> do think before you type.

I didn't want to offend you. If I did, then I'm sorry.

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

Volker Birk wrote:

> Todd H. <comphelp@toddh.net> wrote:
>
>>>Please show one single way to crash the Windows-Firewall from outside.
>>>After you showed, I will believe.
>>
>>Today: Email attachment with proper social engineering for grandma to click
>>on it, leverage a zip buffer overflow, executable overflow turns of
>>the windows firewall.
>
>
> This is not what I meant with "from outside". Every technical security
> system can be compromized with a social engineering attack, so this means
> nothing.

I have encountered, in the wild, a worm which went straight through
(from outside) windows firewall and infected machines. I do not recall
the name of the virus. The vulnerability that allowed this has since
been patched.
I am unaware of any worms that can remotely disable XP FW at this point
from the outside on a fully patched machine. There are plenty (bagle-au
etc) that disable after infection from another vector.

So it has been done, and will probably be done again.
E.

E. <bellyup@the.bar> wrote:
> I have encountered, in the wild, a worm which went straight through
> (from outside) windows firewall and infected machines. I do not recall
> the name of the virus. The vulnerability that allowed this has since
> been patched.

Would be very interesting to know, what you're talking about. Could you
find any proofs for it?

> So it has been done, and will probably be done again.

Please understand, that I will believe this after I saw the proof.

To explain: I'm not very convinced about security in Microsoft's products
either. In fact, I'm typing this on a Apple Powerbook running Debian
GNU/Linux. I'm doing my Windows development on a Windows 2003 Server using
rdesktop in our inner zone.

But if one is using Windows, then she/he is trusting in Microsoft. If one
is not trusting in Microsoft, he/she just should not use Microsoft's
products.

And the Windows-Firewall is just a GUI for the packet filters in Windows'
kernel. If one isn't trusting into Windows kernel, then one should not
use Windows at all, because an operating system's kernel is the software
which has to control any other software program running on the OS, including
the "Personal Firewall" software programs of third party.

The KISS principle, I think, is very important for security either. So to
keep Windows as simple as possible (as a matter of fact, it's much too
complex already), adding another software program to make it secure is not
a very good idea anyway. This added software program then should offer a
huge extra of being secure against other attack vectors, so this compensates
making the system more complex.

I cannot see this with every "Personal Firewall" we tested. I only saw
very incompetent hacked software, most of them even breaching security
by ignoring Microsoft's design principles for system software.

And I saw no additional security at all compared with the Windows-Firewall.

But if the Windows-Firewall has such huge holes like you're claiming,
I will change my mind of course. Then Windows' packet filter would be
not a good idea to use. Then I would call people not to trust into any
host based packet filtering for Windows I know. I would call people
to filter with second devices before each Windows box, or to disable
Windows' servers only.

But until I see a proof here, I will not believe that. Sorry.

I know of a bug in Windows' IP stack, detected in June this year. It was
patched. Windows even was vulnerable to the "good old" LAND attack again.
Shame on Microsoft. But this has nothing to do with the Windows-Firewall,
and if it was used, a Windows box was not vulnerable in this way.

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

Volker Birk wrote:

> E. <bellyup@the.bar> wrote:
>
>>I have encountered, in the wild, a worm which went straight through
>>(from outside) windows firewall and infected machines. I do not recall
>>the name of the virus. The vulnerability that allowed this has since
>>been patched.
>
>
> Would be very interesting to know, what you're talking about. Could you
> find any proofs for it?

I can't remember the name of it. It was just yet another worm to me, so
it barely registered on the brainmap. 2 other techs I work with got
called out to jobs with the same infection over the remaindr of the week.
>
>
>>So it has been done, and will probably be done again.
>
>
> Please understand, that I will believe this after I saw the proof.

Symantec (NAV) eventually detected it, so it should be locateable on
their website, or on the securityfocus.com website.
> But if one is using Windows, then she/he is trusting in Microsoft. If one
> is not trusting in Microsoft, he/she just should not use Microsoft's
> products.

Don't trust anyone or anything, and suspect everything, until proven not
guilty.
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.

> But until I see a proof here, I will not believe that. Sorry.

If I could recall the exact details, i'd post them.

> I know of a bug in Windows' IP stack, detected in June this year. It was
> patched. Windows even was vulnerable to the "good old" LAND attack again.
> Shame on Microsoft. But this has nothing to do with the Windows-Firewall,
> and if it was used, a Windows box was not vulnerable in this way.
>
> Yours,
> VB.

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

(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)

E.


From bugtraq archives....

Hello, this might be interesting for you (see below): Please note that
all screenshots and more details can be found in the German article
only (see links), the English one is slightly shortened. cheers,
Andreas Marx PC-WELT discovers and fixes serious security issue in
Windows XP SP2 by Andreas Kroschel and Thorsten Eggeling; Sep 15, 2004
English version: <http://www.pcwelt.de/know-how/extras/103039/> German
version: <http://www.pcwelt.de/news/sicherheit/103013/> Windows XP
Service Pack 2 with Advanced Security Technologies helps you protect
your PC against viruses, hackers, and worms." - this is how Microsoft
promotes its Service Pack 2 on its website. What the company does not
say: Instead of viruses, worms, and hackers, the supposedly safe SP2
for Windows XP invites any Internet user to have a look around your PC.
As soon as you install SP2 on a Windows XP PC with a certain
configuration, your file and printer sharing data are visible
worldwide, despite an activated Firewall. This also applies to all
other services. The PC only has to provide sharing for an internal
local network and connect to the Internet via dial-up or ISDN. Users of
DSL services are also affected, if a firewall is not integrated into
the DSL modem or a common modem instead of a DSL router is used.
Additionally, Internet Connection Sharing of the PC has to be disabled.
A number of test scans run by PC-Welt revealed that this in fact is a
common configuration and not a rare sight. Without great effort, we
were able to discover private documents on easily accessible computers
on the Internet. It must be assumed, that these users wrongly believe
they are safe and that their sharing configurations are only visible in
their network at home: Often, we did not even encounter password
protection. Already Windows 95 affected by a similar problem
Experienced Windows users may remember that there was a similar problem
in the past, specifically with Windows 95. Back then, Microsoft forgot
to separate file and printer sharing from the dial-up network adapter
when such a connection was configured. In other words, this caused the
service to be released worldwide through the dial-up connection as soon
as you were connected to the Internet. Microsoft at that time issued an
update to patch the bug. The fact that file and printer sharing since
then is not connected to the dial-up connection anymore, can easily be
seen on your system: Right-click on the symbol "My Network Places" and
select "Properties". Repeat the right-click and selection with the icon
of your dial-up connection and select the tab "Settings". If there is
no check at "File and Printer Sharing", it indicates that this service
should not be made available through your dial-up connection. This in
fact is true for Windows XP without Service Pack. Since SP1, this
configuration is hardly more than cosmetics and does not serve any
purpose anymore. This means, the file and printer sharing service is
connected in general, also to the dial-up network adapter. This in
itself is a serious bug, since your shared data potentially could be
seen on the Internet. However, there are no catastrophic effects, as
every dial-up connection is configured with an activated firewall by
default. If you intended to deactivate this firewall, Windows displayed
an easily recognizable dialog, that this choice would allow access to
your computer. Despite the bug in SP1, the configuration of the
firewall was worked out in a clean way: You were able to run the
dial-up connection with a firewall and the internal network card
without, because the latter was supposed to enable access through the
Windows network. SP1 + SP2 leads to a catastrophic error Due to the
bug carried over from SP1 as well as a new bug, the firewall
configuration with SP2 has a catastrophic effect. The SP2 installation
simply uses the previous configuration of the firewall: If it was active
for the dial-up connection, now it also has been activated for the
network adapter. At the same time, an exception is determined for file
and printer sharing: For the internal network card - and astonishingly
also for all adapters. With the first use of the dial-up connection
after installing SP2, all of your shared data are available on the
Internet. Now, other users can start guessing your passwords for
administrator and guest and you basically are no more secure than the
first Windows 95 users with an Internet connection - thanks to Service
Pack 2. How to correct the problem It is not advisable to keep this
defective default configuration. However, the previous environment
cannot be restored: The configuration for the firewall was changed,
which does not allow the setting of active or inactive conditions or
exceptions for each network adapter anymore. Now this only works for
network areas. Choose "Windows Firewall" in the in the Windows Control
Panel and the there the tab "Exceptions". Select "File and Print
Services" and click on "Edit". Now you can see four ports which are
used by the file and print sharing service. To lock the service to the
outside and keep it open for the internal LAN, you have to individually
select and change its area with the respective button. Our reader Yves
Jerschov notified us of another bug: The value for the area set by
default "Only for own network (Subnet)" only works, if the Internet
Connection Sharing is activated. If this is not the case, your shared
data are visible worldwide. This error can be corrected by choosing
"User defined List" and entering the IP addresses that are supposed to
have access - the IP addresses of your LAN. A whole range of an IP area
can be entered as "192.168.x.0/255.255.255.0", if the respective
addresses start with 192.168.x. After these measures, you can be sure
to be as safe as you were with SP1. Great, don't you think? -- AV-Test
GmbH, Klewitzstr. 7, 39112 Magdeburg, Germany Phone: +49 (0)391 6075466,
<http://www.av-test.org>

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

Folks,

Here's the packet trace and the explanation of an ICMP-based blind
connection-reset attack.

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).

Here's the packet trace:

22:20:56.921433 192.168.0.1.80 > 10.0.0.1.3270: . 58849:60269(1420) ack
203 win 17040 (DF) (ttl 63, id 36261)
22:20:57.400206 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 51749 win 9940 (DF) (ttl 118, id 23142)
22:20:57.403911 192.168.0.1.80 > 10.0.0.1.3270: . 60269:61689(1420) ack
203 win 17040 (DF) (ttl 63, id 63275)
22:20:57.690641 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 53169 win 9940 (DF) (ttl 118, id 23143)
22:20:57.694341 192.168.0.1.80 > 10.0.0.1.3270: . 61689:63109(1420) ack
203 win 17040 (DF) (ttl 63, id 36878)
22:20:58.077059 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 54589 win 9940 (DF) (ttl 118, id 23144)
22:20:58.080702 192.168.0.1.80 > 10.0.0.1.3270: . 63109:64529(1420) ack
203 win 17040 (DF) (ttl 63, id 55051)
22:20:58.372458 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 56009 win 9940 (DF) (ttl 118, id 23146)
22:20:58.376206 192.168.0.1.80 > 10.0.0.1.3270: . 64529:65949(1420) ack
203 win 17040 (DF) (ttl 63, id 51041)
22:20:58.662963 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 57429 win 9940 (DF) (ttl 118, id 23147)
22:20:58.666648 192.168.0.1.80 > 10.0.0.1.3270: . 65949:67369(1420) ack
203 win 17040 (DF) (ttl 63, id 59428)
22:20:58.954124 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 58849 win 9940 (DF) (ttl 118, id 23148)
22:20:58.957766 192.168.0.1.80 > 10.0.0.1.3270: . 67369:68789(1420) ack
203 win 17040 (DF) (ttl 63, id 56440)
22:20:59.161094 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 60269 win 9940 (DF) (ttl 118, id 23152)
22:20:59.164797 192.168.0.1.80 > 10.0.0.1.3270: . 68789:70209(1420) ack
203 win 17040 (DF) (ttl 63, id 53543)
22:20:59.356094 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 61689 win 9940 (DF) (ttl 118, id 23153)
22:20:59.359768 192.168.0.1.80 > 10.0.0.1.3270: . 70209:71629(1420) ack
203 win 17040 (DF) (ttl 63, id 56257)
22:20:59.455306 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 63109 win 9940 (DF) (ttl 118, id 23154)
22:20:59.458961 192.168.0.1.80 > 10.0.0.1.3270: . 71629:73049(1420) ack
203 win 17040 (DF) (ttl 63, id 43027)
22:20:59.941338 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 64529 win 9940 (DF) (ttl 118, id 23156)
22:20:59.945036 192.168.0.1.80 > 10.0.0.1.3270: . 73049:74469(1420) ack
203 win 17040 (DF) (ttl 63, id 34869) 22:21:00.142370 10.0.0.1.3270 >
192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 65949 win 9940 (DF) (ttl
118, id 23158)
22:21:00.146012 192.168.0.1.80 > 10.0.0.1.3270: . 74469:75889(1420) ack
203 win 17040 (DF) (ttl 63, id 42831)
22:21:00.433104 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 67369 win 9940 (DF) (ttl 118, id 23159)
22:21:00.436766 192.168.0.1.80 > 10.0.0.1.3270: . 75889:77309(1420) ack
203 win 17040 (DF) (ttl 63, id 38361)
22:21:00.823041 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 68789 win 9940 (DF) (ttl 118, id 23162)
22:21:00.826725 192.168.0.1.80 > 10.0.0.1.3270: . 77309:78729(1420) ack
203 win 17040 (DF) (ttl 63, id 47968)
22:21:00.928689 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 70209 win 9940 (DF) (ttl 118, id 23164)
22:21:00.932333 192.168.0.1.80 > 10.0.0.1.3270: . 78729:80149(1420) ack
203 win 17040 (DF) (ttl 63, id 56881)
22:21:01.321744 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 71629 win 9940 (DF) (ttl 118, id 23165) 22:21:01.325420
192.168.0.1.80 > 10.0.0.1.3270: . 80149:81569(1420) ack 203 win 17040
(DF) (ttl 63, id 50563)
22:21:01.804138 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 74469 win 9940 (DF) (ttl 118, id 23167)
22:21:01.807833 192.168.0.1.80 > 10.0.0.1.3270: . 81569:82989(1420) ack
203 win 17040 (DF) (ttl 63, id 39445)
22:21:01.809033 192.168.0.1.80 > 10.0.0.1.3270: . 82989:84409(1420) ack
203 win 17040 (DF) (ttl 63, id 61324)
22:21:01.908884 192.168.0.1 > 10.0.0.1: icmp: 192.168.0.1 protocol 6
unreachable for 10.0.0.1.3270 > 192.168.0.1.80: [|tcp] (ttl 158, id
61654) (ttl 214, id 31456)
22:21:02.005231 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 75889 win 9940 (DF) (ttl 118, id 23169)
22:21:02.008909 192.168.0.1.80 > 10.0.0.1.3270: . 84409:85829(1420) ack
203 win 17040 (DF) (ttl 63, id 46016)
22:21:02.487527 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 78729 win 9940 (DF) (ttl 118, id 23171)
22:21:02.491159 192.168.0.1.80 > 10.0.0.1.3270: . 85829:87249(1420) ack
203 win 17040 (DF) (ttl 63, id 64644) 22:21:02.492360 192.168.0.1.80 >
10.0.0.1.3270: . 87249:88669(1420) ack 203 win 17040 (DF) (ttl 63, id 39376)
22:21:02.785749 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 80149 win 9940 (DF) (ttl 118, id 23173)
22:21:02.789412 192.168.0.1.80 > 10.0.0.1.3270: . 88669:90089(1420) ack
203 win 17040 (DF) (ttl 63, id 58117)
22:21:02.980601 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 81569 win 9940 (DF) (ttl 118, id 23175)
22:21:02.984257 192.168.0.1.80 > 10.0.0.1.3270: . 90089:91509(1420) ack
203 win 17040 (DF) (ttl 63, id 62887)
22:21:03.175183 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 82989 win 9940 (DF) (ttl 118, id 23176)
22:21:03.178854 192.168.0.1.80 > 10.0.0.1.3270: . 91509:92929(1420) ack
203 win 17040 (DF) (ttl 63, id 54586)
22:21:03.374078 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok]
203:203(0) ack 84409 win 9940 (DF) (ttl 118, id 23177)
22:21:03.377773 192.168.0.1.80 > 10.0.0.1.3270: . 92929:94349(1420) ack
203 win 17040 (DF) (ttl 63, id 56692)
22:21:03.380717 10.0.0.1.3270 > 192.168.0.1.80: R [tcp sum ok]
4174694923:4174694923(0) win 0 (ttl 118, id 23180)

The packet trace was obtained at some firewall close to the web server
and the attacker. That's why after the ICMP error message you still find
a few data segments and a few ACKs. From the point of view of the
attacked host (i.e., the web-client), as soon as it receives the ICMP
error, it aborts the connection, and sends a RST to the web-server.

After trying all the ports in the range 1024-4999, icmp-reset will start
again trying from port 1024. The idea is that the attacker will want to
reset the connection again and again. Thus, if the client restarts the
connection just after we reset it, every 12 seconds (or so) we will be
resetting the connection again and again. This may not make cause much
harm for a web-client downloading a file. But think about a blind
connnction-reset being performed against a BGP router, a mailserver, or
whatever.

Did we sniff the network? - NO! All these attacks are *blind*. That's
why they are so *trivial*.

You see it? Just 12 seconds to send the 3976 packets that this blind
connection-reset attack that can reset an arbitrary TCP connection
between any two systems of the Internet. And we are just attacking from
one host, with just a 128kbps communications link.

The attacks and the counter-measures are described at
http://www.gont.com.ar/drafts/icmp-a...ainst-tcp.html

You can get your vendor fix it, or have someone start a discussion about
this being "old news". A few "vendors" have done the former. Most have
done the latter, unfortunately.

Let's see if everybody understands the point: There are lots of systems
still vulnerable to these ICMP attacks. And lots of people arguing
*against* implementing counter-measures for them. And vendors claiming
that these attacks are hard to perform, etc.

These attacks are still current. And probably your vendor will not do
anything about it. So realize how simple they are to perform, and make
your vendor understand it and fix them, and get involved to have the
IETF specs address these issues.

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org

....and more on personal firewalls...

-------------------------------------------------------------------
Multiple Firewall Products Bypass Vulnerability
-------------------------------------------------------------------
Online URL : http://ferruh.mavituna.com/article/?769
Download POC : http://ferruh.mavituna.com/opensourc...wallbypass.zip
(Also I attached vbs files as txt, one of them is -mousecontrol.txt-
vb.net source code)

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.).

-------------------------------------------------------------------
Problem;
-------------------------------------------------------------------
Most of personal firewalls allow shortcuts or interface for controlling
traffic. It's simple to bypass these firewalls by a multithreaded
program and sending keys or by contolling mouse.

This flaw enables that any Trojan or similar programs can easily bypass
firewall and act as a server or access to another computer. Also most of
these firewalls have a "remember" option so if you bypass firewall and
successfully exploit it, firewall will never ask again.

This is a similar threat with shattering attacks, but different method
and impact.

Vulnerable Products (Sending Key Method and Mouse Control); These
products are vulnerable to both of "Sending Key Method" and "Mouse
Control Method"

Test Platforms;
Fully Patched Windows XP Professional and Windows 2003 Enterprise
Edition (May 19, 2004 - 01.01.2005)

1. ZoneAlarm / ZoneAlarm Pro (www.zonelabs.com) | Fixed
I. 4.5.530.000 - Tested
II. 4.5.538.001 - Tested
III. 5 and newer versions are not vulnerable...

2. Kerio (www.kerio.com)
I. 4.0.14 - Tested
II. All Versions

3. Agnitium Outpost Firewall (www.agnitium.com)
I. 2.1.303.4009 (314) - Tested
II. 2.5.369.4608 (369) - Tested
II. All Versions

4. Kaspersky Anti-Hacker (www.kaspersky.com)
I. 1.5.119.0 - Tested
II. All Versions

5. Look 'n' Stop (www.looknstop.com)
I. 2.04p2 - Tested
II. All Versions

6. Symantec's Norton Personal Firewall (www.norton.com)
I. 2004 - Tested
II. All Versions

-------------------------------------------------------------------
Vulnerable Products (Mouse Control);
-------------------------------------------------------------------
These products are only vulnerable to "Mouse Control Method", because
they don't accept shortcuts but still vulnerable to "Mouse Control" attacks.

1. Panda Platinum Internet Security
I. 8.03 (tested)
II. All Versions

2. Omniquad Personal Firewall
I. 1.1 (tested)
II. All Versions


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

First POC (bypassSendKey.vbs) written in VBScript (.vbs), This POC
include required samples for ZoneAlarm, Kerio, Agnitium, Kaspersky
Anti-Hacker, Look 'n' Stop and Symantec's Norton Personal Firewall. This
script is executing an instance of itself for multithreading and send
shortcuts to firewall while first instance trying to connect internet. I
didn't write an auto determine firewall function (but it's so easy), so
you need to set it by yourself.

Second (bypassMouseControl.txt) simulates an example of bypassing Zone
Alarm Firewall by with mouse control, code in VB.NET. Program is not
using a real multithread because some firewalls interrupt executing of
program directly.
So program is executing another instance of itself with an argument.

Both of them add themselves to secure app list of firewalls and then
bypass active firewall.

Also I attached testFirewall.vbs for testing your firewall for
application control.

-------------------------------------------------------------------
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.

As a user of these firewalls, if your firewall supports to "deny all
default" option, enable it, so your firewall deny all connections by
default. After that you may can manually select programs for allow them.

-------------------------------------------------------------------
Final Words;
-------------------------------------------------------------------
This is a methodology for bypassing interacted firewalls so it's
possible that this advisory affects other firewalls in market. Also it's
possible that future firewalls will be affected too. I think for now
this is a serious problem for firewalls, until they imply
password/random human need text method for "Allow/Deny" actions.

-------------------------------------------------------------------
History;
-------------------------------------------------------------------
Discovered: 03.05.2004
Vendors Informed: 28.08.2004
Published: 03.01.2005

-------------------------------------------------------------------
Vendors Status;
-------------------------------------------------------------------
Special thanks to ZoneLabs Team.


Ferruh Mavituna
http://ferruh.mavituna.com
pgpkey : http://ferruh.mavituna.com/PGPKey.asc

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