| ActiveMac | Anonymous | Create a User | Reviews | News | Forums | Advertise |
|
|
|
User Controls |
|
New User |
|
Login |
|
Edit/View My Profile |
|
|
|
|
|
|
|
ActiveMac |
|
Articles |
|
Forums |
|
Links |
|
News |
|
News Search |
|
Reviews |
|
|
|
|
|
|
|
News Centers |
|
Windows/Microsoft |
|
DVD |
|
ActiveHardware |
|
Xbox |
|
MaINTosh |
|
News Search |
|
|
|
|
|
|
|
ANet Chats |
|
The Lobby |
|
Special Events Room |
|
Developer's Lounge |
|
XBox Chat |
|
|
|
|
|
|
|
FAQ's |
|
Windows 98/98 SE |
|
Windows 2000 |
|
Windows Me |
|
Windows "Whistler" XP |
|
Windows CE |
|
Internet Explorer 6 |
|
Internet Explorer 5 |
|
Xbox |
|
DirectX |
|
DVD's |
|
|
|
|
|
|
|
TopTechTips |
|
Registry Tips |
|
Windows 95/98 |
|
Windows 2000 |
|
Internet Explorer 4 |
|
Internet Explorer 5 |
|
Windows NT Tips |
|
Program Tips |
|
Easter Eggs |
|
Hardware |
|
DVD |
|
|
|
|
|
|
|
Latest Reviews |
|
Applications |
|
Microsoft Windows XP Professional |
|
Norton SystemWorks 2002 |
|
|
|
Hardware |
|
Intel Personal Audio Player 3000 |
|
Microsoft Wireless IntelliMouse Explorer |
|
|
|
|
|
|
|
Site News/Info |
|
About This Site |
|
Affiliates |
|
ANet Forums |
|
Contact Us |
|
Default Home Page |
|
Link To Us |
|
Links |
|
Member Pages |
|
Site Search |
|
Awards |
|
|
|
|
|
|
|
Credits |
 |
Spida bites Microsoft SQL servers | |
|
||
| Time: 02:53 EST/07:53 GMT | News Source: ZDNet | Posted By: Alex Harris | ||
|
Spida (js.spida.b.worm, also known as Double Tap and SQLSnake) is an Internet worm now attacking Microsoft SQL servers worldwide. Written in JavaScript, Spida actively scans port 1433 for access into systems with blank system administrator accounts. According to the SANS Institute, a computer research organization, system administrators began noticing an upsurge in scans on port 1433, which is used by Microsoft's SQL servers, on Monday, May 20, 2002. Within the first 12 hours, the number of scanned and infected systems rose sharply to more than 1,600, and those systems are now scanning for others on the Internet. In addition to port scanning, the worm collects and e-mails passwords from the infected servers. Users of Microsoft Windows 95, 98, or Me are not affected by the Spida worm. | ||
|
Write Comment
Return to News |
Displaying 1 through 25 of 441 Last | Next |
The time now is
7:54:45 AM
ET.
Any comment problems? E-mail us |
| #1 By 2332 (129.21.145.80) at 5/22/2002 3:07:38 AM |
|
"Users of Microsoft Windows 95, 98, or Me are not affected by the Spida worm."
In addition, those uses who have a DAMN CLUE are also not affected. |
| #2 By 2459 (66.25.124.8) at 5/22/2002 3:21:21 AM |
|
Also of note:
"... the password dump tool works only if Syskey is not enabled, which is the default condition for NT 4.0. Syskey is enabled by default in Windows 2000 and XP." |
| #3 By 20 (24.243.51.87) at 5/22/2002 10:04:19 AM |
|
Ok, dear lord. There's an element of Darwanism playing out in the Internet today.
Viruses like these are taking out all the stupid and lame people who can't understand why putting a back-end DB server directly on the 'Net is a stupid thing to do. I hope they all get infected and their sites go down. Just like the wounded aged cow that can't keep up with the herd distracts the predators while the healthy herd moves on to safety. |
| #4 By 135 (209.180.28.6) at 5/22/2002 10:28:10 AM |
|
Databases should be behind firewalls, obviously.
|
| #5 By 3339 (65.198.47.10) at 5/22/2002 1:04:37 PM |
| I agree anyone running SQL Server should know that MS stupidly leaves the default admin password blank and that other measures (like firewalls) should protect network-accessible databases... But doesn't the problem start with MS stupidly leaving the default admin password blank and active? Haven't we all known this for years? Isn't this the first thing someone learns when using SQL Server? So why didn't Microsoft learn years ago? It shouldn't have taken a stupid memo from Bill or another worm to have figured out this bit of stupidity! |
| #6 By 116 (129.116.86.41) at 5/22/2002 1:20:15 PM |
| I can't speak for 7.0 but 2000 asks you for a password upon installation and you have to configure mixed mode to begin with for this to be a problem. I don't see this as much MS's failure as user training. There are instances when you would want a blank password (for training) but no production server should have a blank password. |
| #7 By 3339 (65.198.47.10) at 5/22/2002 1:31:09 PM |
| So you add a blank password to your training db--you don't by default have an unprotected user for every db created. Fixing it in 2000 doesn't wash MS's hands of the problem either. If anything, it shows they knew it was a problem but didn't give a sh!t and/or wanted to force a migration. It is an MS design failure--now, you have to make sure every user knows the first thing they do is change this password--in other words, it didn't ease the user process by eliminating setting up a username/password in the beginning of the build process--all it does is complicate the process--because you have to do this user setup and/or have an insecure database. And people wonder why, even with good benchmarks, some say MS SQL Server is not an enterprise-capable database. Because it wasn't designed to be taken seriously as meeting the needs of the enterprise. |
| #8 By 3339 (65.198.47.10) at 5/22/2002 1:42:09 PM |
| btw, even though this is common knowledge, no where in any MS documentation does it tell the user to do this. You would have to know about the security bulletin they released finally last year and/or be trained by a good instructor/experienced SQL person and/or read a non-Microsoft book that starts off with "MS was stupid for leaving the sa account password blank--first thing you do is change this..." |
| #9 By 135 (209.180.28.6) at 5/22/2002 2:03:15 PM |
|
sodajerk - You are absolutely right! Instead Microsoft should leave the password as CHANGE_ON_INSTALL like Oracle!
|
| #10 By 3339 (65.198.47.10) at 5/22/2002 2:14:06 PM |
|
The softy defenses are out in force: 1) it's an evolutionary thing, it's a good thing. It's there on purpose to weed out the weak. It's not a flaw; it's a test to determine who will survive or not. 2) Oracle does it too so MS is absolved.
How 'bout just admitting that since we all knew it was a problem for a long time MS should have addressed it a long time ago too? No, can't do that--MS is perfect. |
| #11 By 4209 (163.192.21.2) at 5/22/2002 3:28:13 PM |
| SodaJerk, what do you suggest that every version of SQL before 2000 be re-written to fix the problem? No they fixed it in the latest release and as #13 stated if you SP version 7 it will bitch at you. Any good administrator should know to change the password if they are not prompted for it. Sure MS should have required it in previous versions but that does not excuse the lack of knowledge of an Admin using it. An admin should know the flaws or weaknesses of any software they install, especially a databasing server. |
| #12 By 3339 (65.198.47.10) at 5/22/2002 3:37:54 PM |
| All I am saying is that admin knowledge doesn't absolve Microsoft of the problem. This has always been a problem; it has always been known. There may have been previous worms (I don't know) and certainly people have accessed SQL databases using this weakness before. Someone developed a new worm to exploit it, and now MS has to answer for it. It's bad security, everyone knew it would happen sooner or later, Microsoft just didn't care. |
| #13 By 135 (209.180.28.6) at 5/22/2002 3:38:55 PM |
|
sodajerk - No, I made the comment about Oracle because you were bitching that this was proof SQL Server wasn't enterprise ready. I just thought that was a funny comment.
It's easy to be hypercritical when you aren't familiar with the issues. My main concern actually is MSDE. I've had difficulty trying to install it in the past anyway, but as I recall you need access to SQL Server client tools in order to administrate it. Which probably is not normally going to be the case where people are using it. |
| #14 By 3339 (65.198.47.10) at 5/22/2002 3:47:11 PM |
| I know what your point was. I'm not an Oracle developer so so what? I'm just looking at an MS problem and am saying "it's Microsoft's problem." That's my point. It's not hypocritical when I'm not trying to comment on anyone else but Microsoft. |
| #15 By 116 (129.116.86.41) at 5/22/2002 4:11:21 PM |
| Its easy to talk to people about problems. What would you like the solution to be SodaJerk? Do you consider it to be a problem in 2000 as well? What is your solution? |
| #16 By 4209 (163.192.21.3) at 5/22/2002 5:57:23 PM |
| SodaJerk, I was just asking what MS is to do? They fixed this issue in SQL 2K, do you want them to re-release the previous versions to fix it as well? People make mistakes and MS has a lot of software and code to go through, they are finding those mistakes as well and trying to fix them. But you can't expect them to go to each SQL install out there and slap the Admin for not knowing how to do his/her job and fix it for them. They did it in an update, which is all one can ask. So what is your point then? |
| #17 By 3339 (65.198.47.10) at 5/22/2002 7:02:44 PM |
| I think they should have provided a patch to all version of SQL Server in use by client's in production environments if they are susceptible to the problem. Not just fix their most recent version. |
| #18 By 6253 (12.237.192.187) at 5/22/2002 7:27:33 PM |
|
#21, they DO. Service Packs for SQL 7.0 complain about blank SA passwords. SQL 6.5 doesn't, but SQL 6.5 does not support all the features used by this worm (or that would be required by any worm), so it is not susceptible.
Also, it's bigger than MS, bigger than Oracle. There are tons of routers and switches sitting around whose administration passwords are left at the factory defaults. See http://www.astalavista.com/library/auditing/password/lists/defaultpasswords.shtml for an example of a list whose sole value depends on the fact that people don't change default passwords regardless of whether they are blank or CHANGE_ON_INSTALL or password. So while I agree with you that MS should never have allowed blank sa passwords, they were in conformance with industry-standard practices. And now they have addressed the issue for all versions still likely to be in production. If anyone is running 4.2 or 6.0, they've got Y2K and other problems more severe than this. |
| #19 By 4209 (163.192.21.2) at 5/23/2002 10:42:09 AM |
| Yep once again SodaJerk does not comprehend what he reads. As stated they do have a patch for the previous version. How many versions should they patch? If it is 6.5 you are talking of, then it has been in production so long the admin should have already set the password by now, or upgraded to gain features and then patched so the password would need to be set. |
|
Write Comment
Return to News |
Displaying 1 through 25 of 441 Last | Next |
The time now is
7:54:45 AM
ET.
Any comment problems? E-mail us |
