MS SQL Server Worm Wreaking Havoc

defile writes "Since about midnight EST almost every host on the internet has been receiving a 376 byte UDP payload on port ms-sql-m (1434) from a random infected server. Reports of some hosts receiving 10 per minute or more. internetpulse.net is reporting UUNet and Internap are being hit very hard. This is the cause of major connectivity problems being experienced worldwide. It is believed this worm leverages a vulnerability published in June 2002. Several core routers have taken to blocking port 1434 outright. If you run Microsoft SQL Server, make sure the public internet can't access it. If you manage a gateway, consider dropping UDP packets sent to port 1434." bani adds "This has effectively disabled 5 of the 13 root nameservers."

As I said in a previous post...

[caluml]

I find it lucky that the worm writer didn't make the worm fire out random traffic on random udp ports with spoofed addresses.

It's only the fact the traffic is all destined for a certain destination port that makes it easy to filter.
You are filtering it out on your firewalls, aren't you?
/sbin/iptables -I FORWARD -p udp --dport 1434 -j DROP

This could have been a lot lot harder to filter out. I expect we'll see ThisWorm v2 soon.

I dread the day someone finds a hole in Apache, Sendmail or something really popular and writes a worm like this...

been watching this all night

[h2odragon]

the fun's almost over now

Collected a packet disasembly and some urls here [freedom.org].

Everyone seems to be assuming this is a new use of an old (July) hole; I'm not certain of that. Any facts welcomed, see above url.

Patch

[sql*kitten]

Microsoft released a patch [microsoft.com] for this 24th July, 2002.

ZDNet and Yahoo stories

[tigress]

ZDNet [zdnet.co.uk] and Yahoo.

Re:As I said in a previous post...

[bwalling]

It's only the fact the traffic is all destined for a certain destination port that makes it easy to filter.
You are filtering it out on your firewalls, aren't you? /sbin/iptables -I FORWARD -p udp --dport 1434 -j DROP

Exactly. From the MS Security bulletin:

The risk posed by the vulnerability could be mitigated by, if feasible, blocking port 1434 at the firewall.

What the heck was it doing open in the first place?

Information about the worm

[Anonymous Coward]

This site has a disassembly with an explanation: http://www.boredom.org/~cstone/worm-annotated.txt [boredom.org]

Re:As I said in a previous post...

[sql*kitten]

You are filtering it out on your firewalls, aren't you? /sbin/iptables -I FORWARD -p udp --dport 1434 -j DROP

I bloody hope no-one is specifically blocking this port. That's not how firewalls are supposed to be used. First you block everything then only open the specific ports you need. In most cases, these are 80 and 22 and maybe 25. There's no reason a database server's protocol port should ever be exposed to the public Internet!

Turn your SQL server off?

[blowdart]

If you run Microsoft SQL Server, make sure the public internet can't access it.

What a pathetic overkill response. If you're running SQL server, make sure it's patched. When the last set of bind exploits came out no-one said "Unplug all your DNS servers", why is this any different?

SQL is easy to secure, and the guidelines are well known

• Make sure you do not have a blank SA password. You can either run SQL in NT authentication mode (preferred) or mixed mode. Mixed mode exposes you to password attacks.
• MSDE (The desktop edition) is installed, by default with a few pieces of software, including Visio Enterprise, MacAfee's centralised virus admin thingy (hey, I've only just woken up, I can't remember the name ), FlipFactory (an automated video encoding system) and others. There is no user interface to MSDE, you'd have to install SQL tools from a "grown up" installation, then add it as a new server, then set the SA password.
• Consider dropping built in stored procedures like xp_cmdshell, xp_regwrite.
• Run SQL as a limited service account, not as localsystem

And of course, patch it when patches appear

Another look at the worm

[valdezjuan]

From digitaloffense: A new worm which exploits a vulnerability in MS SQL Server is bringing the core routers to a grinding halt. The speed of the propagation can be attributed to the attack method and simplicity of the code. The worm sends a 376-byte UDP packet to port 1434 of each random target, each vulnerable system will immediately start propagating itself. Since UDP is connection-less, the worm is able to spread much more quickly than those using your standard TCP-based attack vectors (no connect timeouts). Some random screen shots and information about the worm can be found HERE. [digitaloffense.net]

best writeup

[numatrix]

Best writeup I've seen is over at iss.net [iss.net]. They were the first to update their internet status homepage alerting of the vulnerability as far as I can tell.

Some Links

[Isomer]

Reachability issues caused by the worm:
http://average.matrixnetsystems.com/Daily/markR.ht ml [matrixnetsystems.com]
http://mrtg.nac.net/switch9.oct.nac.net/3865/switc h9.oct.nac.net-3865.html [nac.net]

The advisory announcing the flaws:
http://www.nextgenss.com/advisories/mssql-udp.txt [nextgenss.com] Various disassemblies and discussions: http://www.snafu.freedom.org/tmp/1434-probe.txt [freedom.org] http://www.digitaloffense.net/worms/mssql_udp_worm / [digitaloffense.net] http://www.boredom.org/~cstone/worm-annotated.txt [boredom.org]

Writeups:
http://www.cnn.com/2003/TECH/internet/01/25/intern et.attack.ap/index.html [cnn.com]
http://news.bbc.co.uk/2/hi/technology/2693925.stm [bbc.co.uk]
http://story.news.yahoo.com/news?tmpl=story&u=/ap/ 20030125/ap_wo_en_po/na_gen_internet_attack_2 [yahoo.com]
http://bvlive01.iss.net/issEn/delivery/xforce/aler tdetail.jsp?oid=21824 [iss.net]

Re:As I said in a previous post...

[blowdart]

What the heck was it doing open in the first place?

Because sometimes you need to connect to SQL from somewhere outside the local LAN? For example, we have SQL passed logging services running in Sydney that connect back to a SQL server in London. Of course, inbound connections are limited to the correct address range.

Re:First hand report

[bwalling]

Needless to say I've been working since then to apply appropriate firewall rules accross our network to block port 1434.

What you really need to do is to assess which ports you need to leave open, and to which hosts they correspond. You need to block everything, and then set rules to enable only the ports/hosts that are necessary (open ports 80/443 to webserver, etc).

Otherwise, you'll be doing the same thing for the next worm.

Collected info:

[Anonymous Coward]

There's a stream of related info in the comments of Slashdot's Cross-Site TRACE [slashdot.org] story.

Some snippets from there:

Mabu's message says: Here's what we've been able to learn, at 4:30am Central time.

We have reason to believe that something called the "SQL Worm" is in play. Some sort of DDOS attack which creates overwhelming traffic on port 1434. This is all preliminary stuff, so take it as such but I have one link up and 3 others down.

I don't have confirmation or details on what systems are affected but we have information to indicate that the following networks are currently affected: Quest, Cable & Wireless, Broadwing, Sprint (partially). My Worldcom link seems to be unaffected (which is why I can post). Note that the connectivity interruptions may be regional but that's what we are dealing with in the South Central area of the US. This has been going on now for about 4-5 hours.

What we are seeing is a major outage due to DDOS on port 1434, on portions of the Internet backbone. At this point, the exact pattern of the outage has not been clarified.

Expect the problem to potentially be addressed when the backbone providers start filtering port 1434. However, it's taken them at least four hours to figure this out.

We just got notice (a few moments ago) that Quest finally started filtering port 1434 and everything went back up. So now we need to figure out what vulnerability this was. My information indicates that port 1434 is MS SQL server resolution service (see related CERT advisory [cert.org]. My initial impression is that while this vulnerability was discovered awhile back, someone just recently figured out a very effective exploit using the vulnerability. I am looking forward to hearing more about what people find out.

The issue currently happening, from what anyone can tell at any rate is that a flaw in MSSQL has been found, due to everyone noticing a lot of traffic on 1434.. MSSQL port anyhow, I was running MSSQL earlier and my dns crapped out ctrl+alt+del'd and saw 85% cpu used by mssql server, killed it and boom everything was okay, possibly a worm traveling around, http://internethealthreport.com/ UUnet seems absolutely destroyed ;)

I'm watching my firewall logs fill up even as I type, and all the 1434 hits are coming from different IPs... no dupes yet that I can see (maybe there are... but I'm not planning on sitting here all night reading logs).

http://www.nextgenss.com/advisories/mssql-udp.txt [nextgenss.com] is an advisory about port 1434

http://average.matrix.net/Daily/markR.html [matrix.net] shows a vivid picture of overall net health due to this

SQLServer listens to 1434 to accept incomming connections. SQLServer 7 would then normally transfer these connections to 1433 by default. SQLServer 2000 would transfer the connection to a random port.

It's best to 'hide' the SQLServer from the internet, and/or disable TCP/IP listening for SQLServer totally when it's connected to the Internet. MS also suggests SQLServer should never be exposed to the Internet directly. You can hide SQLServer (2000) directly, using the Server network utility, shipped with SQLServer. You can there first deselect TCP/IP as a protocol that's active, and if you need it, you can select 'hide' to hide the server on the internet, however it's better to disable TCP/IP totally, since you do not need it when you work with SQLServer from the same box (f.e. a website running on the same box accessing the SQLServer).

Oh, of course it should be mentioned, there is a patch for this available at MS' technet site.

http://www.kb.cert.org/vuls/id/370308 [cert.org] may be the CERT article related to this vuln.

Resent-From: [e-mail]
From: Michael Bacarella Date: Fri Jan 24, 2003 11:11:41 PM America/Los_Angeles
Resent-To: [e-mail]
To: nylug- [e-mail], [e-mail], [e-mail]
Subject: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!

I'm getting massive packet loss to various points on the globe. I am seeing a lot of these in my tcpdump output on each host.
02:06:31.017088 150.140.142.17.3047 > 24.193.37.212.ms-sql-m: udp 376
02:06:31.017244 24.193.37.212 > 150.140.142.17: icmp: 24.193.37.212 udp port ms-sql-m unreachable [tos 0xc0

It looks like there's a worm affecting MS SQL Server which is pingflooding addresses at some random sequence. All admins with access to routers should block port 1434 (ms-sql-m)!

Everyone running MS SQL Server shut it the hell down or make sure it can't access the internet proper! I make no guarantees that this information is correct, test it out for yourself!

-- Michael Bacarella 24/7
phone: [phone]
Netgraft Corporation http://netgraft.com/
"unique technologies to empower your business"
Finger email address for public key. Key fingerprint: C40C CB1E D2F6 7628 6308 F554 7A68 A5CF 0BD8 C055

Re:As I said in a previous post...

[bwalling]

Because sometimes you need to connect to SQL from somewhere outside the local LAN? For example, we have SQL passed logging services running in Sydney that connect back to a SQL server in London. Of course, inbound connections are limited to the correct address range.

If you limited the IP address range, then you don't have it open. You have controlled access to the resource.

Re:As I said in a previous post...

[Anonymous Coward]

What the heck was it doing open in the first place?

When the SQL Server 2000 client Net-Libraries connect to an instance of SQL Server
2000, only the network name of the computer running the instance and the instance
name are required. When an application requests a connection to a remote computer,
Dbnetlib.dll opens a connection to UDP port 1434 on the computer network name
specified in the connection. All computers running an instance of SQL Server 2000
listen on this port. When a client Dbnetlib.dll connects to this port, the server
returns a packet listing all the instances running on the server. For each instance,
the packet reports the server Net-Libraries and network addresses the instance is
listening on. After the Dbnetlib.dll on the application computer receives this
packet, it chooses a Net-Library that is enabled on both the application computer and
on the instance of SQL Server, and makes a connection to the address listed for that
Net-Library in the packet.

So the UDP 1434 port is open when the SQL Server is started to listen all the clients
with any IP address on this port. SQL Server only receives the packet from the client
on this port to determine which instance the client attempts to access and return the
related information of the SQL Server to the clients. Then, the clients can create
the connection to the SQL Server with the protocol enabled on the server side.

How to get control of your box again

[rolandbm]

It looks like if you stop the proccess sqlservr.exe it will take all of the CPU proccess back down to normal. Obviously you dont want to delete this file, but with it stopped you can at least get the box on the network to trouble shoot this stuff. So far from what we can tell, when you restart SQL the load stays down, but that could also just be that its sitting there idle waiting to be activated again. Hope this helps.

Alchemy Support
Alchemy Communications

Who said anything about turning it off?

[Chuck Chunder]

Any server that doesn't need to be accessed from the public internet in the course of it's normal use should be firewalled off from it. That's just common sense.

Dissassembled & annotated

[ediron2]

http://www.boredom.org/~cstone/worm-annotated.txt [boredom.org] has a great annotated geeks-eye-view of this worm.

Kudos to cstone@boredom. Interesting & educational, with a nutty crunchy flavor.

Re:What's inside ?

[AirLace]

There are no SQL commands in the worm. It just initiates a bouncing ping between two MS SQL servers that continues until the network or one of the servers is brought down. An annotated dissection of the worm is provided here [boredom.org].

Re:CNN & AP Beat Slashdot

[LinuxParanoid]

It was covered by the Slashdot masses on another security-related [slashdot.org] thread earlier this morning.

If you want an non-editor-controlled story queue, with story selection subject to user moderation, try submitting/reading here [slashdot.org]; the capability is now possible on Slashdot. It's not as simple as it could be, and it's only a week old, but it works without you having to leave Slashdot.

--LP

Re:What's inside ?

[Anonymous Coward]

Here is the snort packetdump of the exploit:

01/25-14:15:08.249303 128.218.88.115:1102 -> 80.235.37.125:1434 UDP TTL:109 TOS:0x0 ID:48583 IpLen:20
DgmLen:404
Len: 384
04 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................
01 DC C9 B0 42 EB 0E 01 01 01 01 01 01 01 70 AE ....B.........p.
42 01 70 AE 42 90 90 90 90 90 90 90 90 68 DC C9 B.p.B........h..
B0 42 B8 01 01 01 01 31 C9 B1 18 50 E2 FD 35 01 .B.....1...P..5.
01 01 05 50 89 E5 51 68 2E 64 6C 6C 68 65 6C 33 ...P..Qh.dllhel3
32 68 6B 65 72 6E 51 68 6F 75 6E 74 68 69 63 6B 2hkernQhounthick
43 68 47 65 74 54 66 B9 6C 6C 51 68 33 32 2E 64 ChGetTf.llQh32.d
68 77 73 32 5F 66 B9 65 74 51 68 73 6F 63 6B 66 hws2_f.etQhsockf
B9 74 6F 51 68 73 65 6E 64 BE 18 10 AE 42 8D 45 .toQhsend....B.E
D4 50 FF 16 50 8D 45 E0 50 8D 45 F0 50 FF 16 50 .P..P.E.P.E.P..P
BE 10 10 AE 42 8B 1E 8B 03 3D 55 8B EC 51 74 05 ....B....=U..Qt.
BE 1C 10 AE 42 FF 16 FF D0 31 C9 51 51 50 81 F1 ....B....1.QQP..
03 01 04 9B 81 F1 01 01 01 01 51 8D 45 CC 50 8B ..........Q.E.P.
45 C0 50 FF 16 6A 11 6A 02 6A 02 FF D0 50 8D 45 E.P..j.j.j...P.E
C4 50 8B 45 C0 50 FF 16 89 C6 09 DB 81 F3 3C 61 .P.E.P........<a
D9 FF 8B 45 B4 8D 0C 40 8D 14 88 C1 E2 04 01 C2 ...E...@........
C1 E2 08 29 C2 8D 04 90 01 D8 89 45 B4 6A 10 8D ...).......E.j..
45 B0 50 31 C9 51 66 81 F1 78 01 51 8D 45 03 50 E.P1.Qf..x.Q.E.P
8B 45 AC 50 FF D6 EB CA .E.P....

This is inside...

[dark-br]

Disassembly of the 404 bytes being sent by affected systems [freedom.org]

Re:been watching this all night

[Anonymous Coward]

The reason that he doesnt think it is the old hole is because the packet doesnt start with 0x04 in his dump because he accidently included the ip/udp headers as well. If you look at the start of the UDP data section, you can see that it does indeed begin with 0x04.

Re:Why would anyone use anything else?

[sporty]

Postgresql and oracle are like screw drivers. Do you use one screw driver for all tasks? No. There are some things that oracle really kicks ass at that postgres really plain sucks at. Vice versa as well.

Re:As I said in a previous post...

[sporty]

Actually, then the firewall rules are screwed up. If there is an ISP with billions and billions of servers, the firewall should block all traffic to the servers while routing all traffic to specific subnets. Block first, allow through later.

Re:been watching this all night

[numatrix]

I'm relatively sure it ~is~ the old vulnerability. Notice in your very own hex dump.

It starts off with 04 (the same hex byte as in my IDS signature for the Server resolution service buffer overflow everyone thinks this is) and then a bunch of padding with 0101. I myself am skeptical based on volume alone how this could be an old vulnerability, but remember, Code Red and Nimda were old too, and they didn't have any problem finding lots of new hosts very quickly.

What end of the world ?

[Anonymous Coward]

Despite panicky headlines, and mails to bugtraq with titles such as "MS SQL WORM IS DESTROYING THE INTERNET", reports of "some hosts being hit by as many as ten packets a minute" don't seem too serious to me.
Take a look at the LINX traffic statistics at
https://stats.linx.net/cgi-pub/combined?log=combin ed.upps
and
https://stats.linx.net/cgi-pub/combined?log=combin ed.bits
and you won't even see a glitch.

End of the world? I don't think so.

A bug in CISCO routers is helping to control this!

[weave]

A post to bugtraq by George William Herbert, notes that the floods caused by this worm is causing many cisco routers to shut down, which helps contain the damage ironically enough. I've seen this happen at one of my work sites that is admined by someone else. The infected box, according to MRTG, was nailing its closest router at 100 megabits/sec for about an hour, then the router itself went down. Sweet...

"...the volume from this triggers the Cisco netflow switching bug and is causing routers to lock up at places, etc."

not quite free

[Anonymous Coward]

The MS educational site license is a flat $40 per year for every computer, including Apples and Suns.

For that, a school can install any and every MS product where ever they please. Not only that, MS supplies training and testing materials and answer keys with that. So the classes are pre-written, too, and a GTA or undergrad can run them.

So yes, MS SQL is all over the place, and they've got lab assistants and volunteers admining them.

Re:this reason

[Iamthefallen]

That doesn't mean that Amazon's DB servers have public IPs you know. There is no reason to have a DB connected to the internet, unless you just wanna see what happens...

Re:As I said in a previous post...

[silas_moeckel]

That depends on what sort of routers they are using. A lot of Cisco gear an others have overhead running ACL's (first Cisco that can do compiled is a 7200 I think) so you want to accept/deny your most common traffic first so your router dosent die when your throughput goes up.

Re:As I said in a previous post...

[bwalling]

So the UDP 1434 port is open when the SQL Server is started to listen all the clients
with any IP address on this port. SQL Server only receives the packet from the client
on this port to determine which instance the client attempts to access and return the
related information of the SQL Server to the clients. Then, the clients can create
the connection to the SQL Server with the protocol enabled on the server side.

There is a difference between a port being open on the machine the service is on and the port being open to the world. You should not leave this port open to the world. If people outside your firewall need access to your internal MSSQL server, you leave TCP 1433 open to selective hosts.

It can get inside a firewall

[codepunk]

Yes it can indeed get inside a firewall. Say you got bonehead web developer front page dude at home running the developer version. It is no doubt infected with the worm since said developer is using front page and MS SQL on his home xpeeee box. He thanks you by logging in via VPN into your network and spreads the joy. Priceless.....

Ironic timing...

[weave]

Gates pledges better software security [cnn.com] (btw, isn't this basically a repeat of what he spammed out last July?)

Gates acknowledged that the technology industry must make significant improvements, adding that, "Microsoft has a responsibility to help its customers address these concerns, so they no longer have to choose between security and usability."

How about easier ways to apply hotfixes remotely to desktop computers? (There are ways apparently, but requires installing IIS and SQL ironically, to run something called SUS.) I'd prefer the hotfix to simply have an option like '-m\\machine' to apply to domain machines in a domain admin context so I can script the installs to my tastes and needs. No need to get overly complex. Besides, I'd rather not have an IIS server at my site if I can help it. Apache runs everything. Just another damn thing to learn for something that should be simple.

Also, the hotfixes themselves only have about 10 different ways of applying at the command line unattended. How about standardizing the hotfix installers too...

Example, this is what is run after an XP desktop install with SP1 at our location...

q329834 -u -n -z
q323255 -u -n -z
q329048 -u -n -z
start /wait q328310 -u -n -z
start /wait vm-sfix3 /q /r:n
start /wait q324929 /q /r:n
q329115 -u -n -z
q329390 -u -n -z
q810565 -u -n -z

It doesn't include latest javavm fix, which for some reason won't install right during the guirunonce part of an install, so I have to script to reboot the machine TWICE before running...

start /wait msjavwu.exe /q /r:n

Think that's bad? Here's some pre sp1 hotfix command lines from an earlier script..

Msjavx86.exe /c:"javatrig.exe /exe_install /l /qq" /q:a /r:n
vbs56nen /q /r:n
msxm /q /r:n
start /wait q318202 /q /c:"dahotfix /q /n"

And the syntax to install unattended is never easy to find on their site. I usually have to use google to search microsoft.com to find what I need, their search engine really sucks. Others must feel the same way since there is a dedicated google page for this at http://www.google.com/microsoft [google.com]

Attention! You must have SP3 or MS039!!

[Anonymous Coward]

I've been a call all morning and we are sure now that SP2 does NOT protect your server from this attack...YOU MUST APPLY MS-039 to protect your server

Report from Europe

[skillet-thief]

I'm in France. I have 1434 in my logs all morning, but nothing since about 11:30 greenwich. The source IP's are about half and half Europe/US.

A few things are down over here, like my university's network, but haven't noticed any major crashing.

Re:Attention! You must have SP3 or MS039!!

[RedWolves2]

Full description on NAI web site http://vil.nai.com/vil/content/v_99992.htm#Removal Instructions [nai.com]

Need both MS02-034 and MS02-039 MS02-034 must be included on SP3.

Re:.org and postgress must be smiling today

[PhreakinPenguin]

Another ignorant post because people insist on attacking the wrong person. EVERY protocol has vulnerabilities, that's the facts. The patch was release almost a year ago for this same issue. If you want to blame anyone, blame the shitty admins who don't filter out traffic if they must use MSSQL over the internet, or flat out block it if they don't. I know people think it's cool to bash MS, but in this case it's directed at the wrong person. Besides, last time I checked the root-servers weren't running Windows and they went down like a date on prom night.

IBM got hit hard...

[domenic v1.0]

...and we lost tons of money. We were down for more than 8 hours and no customer could call in to check on their server problem tickets, hospitals needed service and we couldnt get technicians out there...our servers were swamped. This is serious when companies who deal with the lives of idividuals are at risk. Hospitals had ptient databases that couldn't get accessed, nor banks needed techs onsite to install new software or hardware upgrades before the open of business....nothing could get done. This was the first time IBM got hit this hard where it brought down 95 percent of the company globally. Yikes....Now I got back to collecting the hair I've been pulling out for the past 8 hours.

Re:.org and postgress must be smiling today

[the eric conspiracy]

last time I checked the root-servers weren't running Windows and they went down like a date on prom night.

Actually NONE of the root nameservers went down, either during this worm incident, or during the Oct 21 incident. The network nameservers are generally highly overprovisioned, and do a very good job of responding to every request they receive, even under abnormal load.

What happened is that the increase in network traffic staturated some of the feeds to the root name servers making it impossible for requests to reach the name servers. This is the real danger of these attacks.

And as far as blaming negligent sysadmins for not patching their servers, well, sure. But sysadmins are not the only players in this game. Companies often have policies regarding software patches and validation that restrain what a sysadmin can do. And the fact is that the sysadmin did not put the vulnerability in the software, nor is this the first time a Microsoft product has servered as the vector for something like this.

dissem and NOTES

[hfx_ben]

A nice collection of data [digitaloffense.net] and NOTES.TXT [digitaloffense.net] here [digitaloffense.net].

Microsoft hotfix testing tool

[dr_db]

Here is a program they have for the NT/2000/XP line that lists hotfixes that have not been applied. It certainly is more comprehensive than the windows update site.... Hotfix Checker at MS [microsoft.com]

No they don't...

[kwenda]

Hotmail still has *nix at it's base, so it's still up.....

No [zdnet.com.au]
It [watchingmi...eahawk.com]
Doesn't. [securityoffice.net]

The site www.hotmail.com is running Microsoft-IIS/5.0 on Windows 2000.

Re:No they don't...

[Anonymous Coward]

Actually hotmail still uses BSD and the links you provided, if you'd bothered to read the articles they point to, do not state otherwise. They do state that MS would sure *like* to get rid of BSD.

The hotmail *website* is running W2K, the email backend is still run on BSD.

Re:PostgreSQL keeps .org up /MS-SQL brings down ne

[bovinewasteproduct]

If you haven't patched PostgreSQL within the last 6 months you are vulnerable to multiple buffer overflow/remote root exploits.

remote root???? Just about EVERY postgresql system runs as a normal user, how the hell do you get root out of that?

By default postgresql does NOT even support IP connections, you have to turn it on by either the -i option to postmaster or in the config file.

I think your looking at the Mordred buffer overflows from about 5 months ago. ALL of these require a valid user account to exploit. NONE were remote. Please post the location/posting of a REMOTE for a recent release of PostgreSQL. Versions 6.X, 7.1.X and 7.2.0 do count.

BWP

!!!ATTENTION MS ADMINS!!!

[spongman]

!!!ATTENTION MS ADMINS!!!

You should be using the Microsoft Baseline Security Analyzer [microsoft.com] to ensure that ALL the machines on your network are properly patched and locked down. It's so easy to run there should be no excuse for attacks like this.

!!!ATTENTION MS ADMINS!!!

Mod parent up!!!!

[moncyb]

I was just about to post the same thing! Moderators: mod this one up! People need to read this otherwise they'll think their cracked box is safe!

From securiteam.com [securiteam.com]: ..It can be configured such that clients can use named pipes over a NetBIOS session (TCP port 139/445) or sockets with clients connecting to TCP port 1433 or both. Whichever method is used the SQL Server will always listen on UDP port 1434. This port is designated as the Microsoft SQL Monitor port and clients will send a message to this port to dynamically discover how the client should connect to the Server.

Read further into the report. The exploits use the vulnerability in the code which listens to UDP port 1434. You can't turn this off!