MS Windows 2003 SP2
Looking deeper into the security aspects of Windows 2003 SP2, we received a list of known CVEs that are supposed to be fixed in SP2 for Windows 2003:
| CVE name | Affected | Reference |
|---|---|---|
| CVE-2006-5578 | MSIE 6 | MS06-072 |
| CVE-2006-5577 | ||
| CVE-2006-3443 | Winlogon | MS06-051 |
| CVE-2006-3281 | MSIE 6 | MS06-045 |
| CVE-2006-2385 | MSIE | MS06-021 |
| CVE-2006-2384 | ||
| CVE-2006-2379 | TCP/IP stack | MS06-032 |
| CVE-2006-2375 | ? | ? |
| CVE-2006-2218 | MSIE 6 | MS06-021 |
| CVE-2006-1992 | ||
| CVE-2006-1388 | MSIE 6 | MS06-013 |
| CVE-2006-1359 | ||
| CVE-2006-1315 | Server Service | MS06-035 |
| CVE-2006-1313 | Microsoft JScript | MS06-023 |
| CVE-2006-1192 | MSIE | MS06-013 |
| CVE-2006-1190 | ||
| CVE-2006-1189 | ||
| CVE-2006-1188 | ||
| CVE-2006-1185 | ||
| CVE-2006-0026 | IIS | MS06-034 |
| CVE-2006-0021 | TCP/IP stack | MS06-007 |
| CVE-2006-0006 | Media player | MS06-005 |
| CVE-2005-4089 | MSIE | MS06-021 |
| CVE-2005-3240 | MSIE race condition | MSRC blog |
| CVE-2005-2388 | USB driver | ? |
| CAN-2006-1626 | MSIE | MS06-021 |
| CAN-2005-2129 | ? | ? |
| CAN-2005-2123 | WMF | MS05-053 |
| CAN-2005-0944 | Jet DB | CERT vuln id 176380 |
| CAN-2005-0803 | EMF | MS05-053 |
| CAN-2005-0109 | Hyperthreading support | CERT vuln id 911878 |
| CAN-2004-1331 | MSIE | CERT vuln id 743974 |
| CAN-2004-1173 | MSIE | ? |
| CAN-2004-1060 | TCP/IP stack | MS05-019 |
There are a number of interesting things in here for sure.
--
Swa Frantzen -- NET2S
Keywords:
0 comment(s)
Allaple worm
This comes from one of our friends over at the Finish cert team CERT-FI / FICORA.
"CERT-FI has been tracking the situation with the Allaple worm
for about 8 months now. We have traced the evolution of the
worm since the first variants came out.
Allaple is a polymorphic worm. The first variants spread through
Radmin installations that had weak passwords.
Every variant so far also tries to locate
all html files on the harddisk to prepend an <object> -tag
into the file to ensure activation of the worm when a local
webmaster views the files. Traces of this behaviour can be
seen on some websites: There's an <object> tag right below the
<html> tag in the page, with the source pointing to a random
UUID.
The first variants were DDOSsing only 1 target and the DDOS was a basic
SYN flood. Shortly there after another target was added to the DDOS routine in the
code.
A bit after that the spreading mechanisms were changed from
Radmin scans to basic catering of Windows exploits,
and yet another target or victim was added.
The SYN DDOS routine has been the same from the first variant
to the latest variant available. Early in the winter code was
added to do HTTP GETs on the target websites. A few other ports
were also targeted. One site is currently getting gentle packet
love on tcp ports 22,80 and 97. Another site is getting packets and
HTTP gets on port 80, and yet another is getting packets on
ports 80 and 443.
The worms have absolutely no Command and Control channels in them.
Once released, there is no way to make them disappear. Their sole
purpose is to spread and DDOS.
In case you are in the correct position, and you feel you would
want to help in this pesky problem, here are a few tricks you can
use to identify Allaple variants on the loose in your networks:
1) ICMP packets with the string "Babcdefghijklmnopqrstuvwabcdefghi",
sans quotes, in the payload.
2) Echo requests to entire networks including host octets of 255 and 0.
We have reason to believe that there will be more variants,
it's just a matter of time when a new one pops out into the open.
CERT-FI is interested in any information or observations regarding the DDOS
or the malware itself. We can be contacted at cert(at)ficora.fi"
"CERT-FI has been tracking the situation with the Allaple worm
for about 8 months now. We have traced the evolution of the
worm since the first variants came out.
Allaple is a polymorphic worm. The first variants spread through
Radmin installations that had weak passwords.
Every variant so far also tries to locate
all html files on the harddisk to prepend an <object> -tag
into the file to ensure activation of the worm when a local
webmaster views the files. Traces of this behaviour can be
seen on some websites: There's an <object> tag right below the
<html> tag in the page, with the source pointing to a random
UUID.
The first variants were DDOSsing only 1 target and the DDOS was a basic
SYN flood. Shortly there after another target was added to the DDOS routine in the
code.
A bit after that the spreading mechanisms were changed from
Radmin scans to basic catering of Windows exploits,
and yet another target or victim was added.
The SYN DDOS routine has been the same from the first variant
to the latest variant available. Early in the winter code was
added to do HTTP GETs on the target websites. A few other ports
were also targeted. One site is currently getting gentle packet
love on tcp ports 22,80 and 97. Another site is getting packets and
HTTP gets on port 80, and yet another is getting packets on
ports 80 and 443.
The worms have absolutely no Command and Control channels in them.
Once released, there is no way to make them disappear. Their sole
purpose is to spread and DDOS.
In case you are in the correct position, and you feel you would
want to help in this pesky problem, here are a few tricks you can
use to identify Allaple variants on the loose in your networks:
1) ICMP packets with the string "Babcdefghijklmnopqrstuvwabcdefghi",
sans quotes, in the payload.
2) Echo requests to entire networks including host octets of 255 and 0.
We have reason to believe that there will be more variants,
it's just a matter of time when a new one pops out into the open.
CERT-FI is interested in any information or observations regarding the DDOS
or the malware itself. We can be contacted at cert(at)ficora.fi"
Keywords:
0 comment(s)
Mac OS X patches
Well, looks like this month we get more Apple fixes than Windows patches for a change. Mac OS X 10.4.9 is out, and according to US-CERT, this is an upgrade that plugs "arbitrary code execution and SYSTEM level access" type of vulnerabilities. Sounds like a fix even Apple fanboys with lots of faith into the unbreakable nature of their system should consider applying real soon. The same fix covering only the security portion but leaving out the functionality upgrade is also available as Security Update 2007-003, and installs on 10.3.9. More information on both can be found on the Apple Docpage.
Keywords:
0 comment(s)
The end of the trend
I used to be an avid reader of the port statistics of my firewalls, because I can remember a time when they actually told me something. Lately though - it must have started in the second half of 2006 - I've come to the conclusion that the daily stroll through the firewall stats isn't much worth my time anymore. Purists always considered "enumerating badness" as one of the dumber things to spend your time on, but fact is that statistical analysis of firewall drop logs did in the past successfully act as an early warning system for new nasties. My guess (and your opinion is of course entitled to differ) is that these days are past. Looking at my firewall stats, I see lots of things making their way to the top of the trend radar and blinking at me in scary red. Investigation turns out that it is - who knows what, some botnet gone wild, some kid boldly scanning the port no kid has scanned before. For the past months, things on top were invariably neither a trend nor a new attack, simply a random escape of the Internet's intestinal gas.
What really made me think though was the conspicious absence of telnet scans when the Sun snafu came to light a few days back. My stats, while covering lots of IP space, didn't show the scary bright red upswing of tcp/23 badness that - I admit - I was almost gleefully waiting for. Careful manual inspection then showed that - oh! - the telnet probing did happen at my perimeter, but it was well below the level of all that noise that makes it to the top of the "trend" radar. On one day, where a single IP address from South Africa slowly probed a good portion of my IP space for telnet, we also got slammed by a 2000-nodes-in-parallel scan for tcp/17458. And. And. Enough to make the telnet thingy rank on position 84, way below my attention span.
As a couple folks who are more savvy at inspecting network traffic than I am have suggested, trending and comparing the in/out flows on ports that are permitted through the firewalls is of much more value than converting the hits on dropped ports into colorful statistics. They are right - but, alas, as most commercial firewall log analysis tools show, enumerating badness is so much easier to do...
What really made me think though was the conspicious absence of telnet scans when the Sun snafu came to light a few days back. My stats, while covering lots of IP space, didn't show the scary bright red upswing of tcp/23 badness that - I admit - I was almost gleefully waiting for. Careful manual inspection then showed that - oh! - the telnet probing did happen at my perimeter, but it was well below the level of all that noise that makes it to the top of the "trend" radar. On one day, where a single IP address from South Africa slowly probed a good portion of my IP space for telnet, we also got slammed by a 2000-nodes-in-parallel scan for tcp/17458. And. And. Enough to make the telnet thingy rank on position 84, way below my attention span.
As a couple folks who are more savvy at inspecting network traffic than I am have suggested, trending and comparing the in/out flows on ports that are permitted through the firewalls is of much more value than converting the hits on dropped ports into colorful statistics. They are right - but, alas, as most commercial firewall log analysis tools show, enumerating badness is so much easier to do...
Keywords:
0 comment(s)
OpenBSD IPv6 remote vulnerability
OpenBSD 3.9 and 4.0 have fixed an issue to correct a problem in the IPv6 stack.
Source code patches are available at:
# vi /etc/pf.conf
The patch itself is a kernel patch, so you will need to recompile a kernel, install it and reboot the affected machines.
Update (Arrigo): the 3.9 patch applies cleanly to the 3.8, 3.7 and even 3.0 trees. No excuse not to patch older systems!
--
Swa Frantzen -- NET2S
Source code patches are available at:
- ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.0/common/010_m_dup1.patch
- ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.9/common/020_m_dup1.patch
# vi /etc/pf.conf
Add a line:# pfctl -f /etc/pf.conf
block drop in inet6 all
To load the new rules in the pf packet filter# pfctl -s rules
Check the rule got loaded in the runtime rules.The workaround does disable all incoming IPv6 packets on the machine.
The patch itself is a kernel patch, so you will need to recompile a kernel, install it and reboot the affected machines.
Update (Arrigo): the 3.9 patch applies cleanly to the 3.8, 3.7 and even 3.0 trees. No excuse not to patch older systems!
--
Swa Frantzen -- NET2S
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments