Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Old SQL Worms Won't Die

ScuttleMonkey posted more than 6 years ago | from the looking-for-a-user-security-patch dept.

Security 64

narramissic writes "In a recent ITworld article, Security researcher Brent Huston ponders how it is that versions of SQL worms dating back to 2002 represent nearly 70% of all malicious traffic on the Internet today. 'I have made a few attempts to backtrack hosts that perform the scans and at first blush many show the signs of common botnet infections. Most are not running exposed SQL themselves, so that means that the code has likely been implemented into many bot-net exploitation frameworks. Perhaps the bot masters have the idea that when they infiltrate a commercial network, the SQL exploits will be available and useful to them? My assessment team says this is pretty true. Even today, they find blank "sa" passwords and other age-old SQL issues inside major corporate clients. So perhaps, that is why these old exploits continue to thrive."

Sorry! There are no comments related to the filter you selected.

of course (4, Funny)

stoolpigeon (454276) | more than 6 years ago | (#22550230)

cut them in half and now you just have 2 worms! stop the madness!

stop the madness! (4, Interesting)

Gary W. Longsine (124661) | more than 6 years ago | (#22550806)

I'm surprised by this article. I thought it was common knowledge that botnets are full of these old exploits. The guessed purpose is exactly what's going on. Worms these days don't spread as rapidly as they used to on the wild internet because botnets are serving a purpose -- they are making somebody money. If they spread like wildfire on the internet as a whole, they would attract too much attention, and get cleaned up. They can't get into most corporate networks using worm probes, either, but they can and do get in by exploiting browsers, as email attachments, and so forth. Once inside, they probe around looking for all manner of things. It's not just SQL exploits, either. I'd guess the sample data they looked at was biased somehow. Maybe some big botnet was running a sweep with those particular exploits during the sample period.

Re: I think you opened a can of worms (0)

Anonymous Coward | more than 6 years ago | (#22554306)

Besides, it's hard to teach an old worm new tricks.

Old SQL worm's don't die (0)

techpawn (969834) | more than 6 years ago | (#22550314)

They just fade away... into am obscure mess of system tables/schema of new releases and older hardware and unpatched servers for old releases.

Besides, you can't kill what's isn't "alive"...

Re:Old SQL worm's don't die (1)

LiENUS (207736) | more than 6 years ago | (#22550910)

Besides, you can't kill what's isn't "alive"...
But you can blast it into chunky kibbles...

Re:Old SQL worm's don't die (1)

joaommp (685612) | more than 6 years ago | (#22551512)

or you can DELETE worm FROM table; and INSERT INTO oblivion VALUES(worm);

Re:Old SQL worm's don't die (1)

Hognoxious (631665) | more than 6 years ago | (#22552526)

you can't kill what's isn't "alive"...
Steve Ballmer fucking can.

Re:Old SQL worm's don't die (0)

Anonymous Coward | more than 6 years ago | (#22558884)

Who? You mean ole uncle Fester?

Unfixed exploits? (1)

NeilTheStupidHead (963719) | more than 6 years ago | (#22550318)

You mean that people are still exploiting 'exploits' that were never fixed? Shocking! And passwords will always be a problem. There will always be people who never change the default passwords so that will always be a viable mode of attack.

Re:Unfixed exploits? (1)

profplump (309017) | more than 6 years ago | (#22550434)

It doesn't have to be; the default password could be set (or even just randomized) on installation, or the account marked for "must change password" if the auth mechanism supports that concept. Either way users would be to required to pick a password before logging in. That obviously doesn't stop anyone from using bad passwords, but you can most certainly stop default passwords -- they've always been a bad idea from lazy installation systems.

Re:Unfixed exploits? (1)

Martin Blank (154261) | more than 6 years ago | (#22551492)

Microsoft is already doing this with Windows Server 2008. After installation, before proceeding any further, the Administrator password must be set. I installed WS2008 last week after downloading it from Technet, and was pleasantly surprised to see this at first login.

Re:Unfixed exploits? (1)

Amouth (879122) | more than 6 years ago | (#22552014)

it was required in server 03 too.. and even complains if you use simple passwords.

Re:Unfixed exploits? (1)

ydra2 (821713) | more than 6 years ago | (#22556206)

Thank you mister...

User: Administrator
Password: Password

Oh, that's not you? Well it's about a million others, so who cares. Botnets aren't looking for you anal password types, they're looking for everybody else, and the non-anal-retentive password people outnumber everybody else by thousands to one or maybe even worse.

Maybe servers should have better 'default' passwds (1)

JSBiff (87824) | more than 6 years ago | (#22550534)

I've wondered about this before. Perhaps server software vendors need to come up with a better default password scheme than just a blank password, or even a static, generic password like 'admin', or 'linksys'. Something where a unique password is generated for every machine during installation, displayed to the user, then saved to a text document on their desktop or a standard 'repository' for the passwords (something like KeePass, Apple's keychain, etc, where you provide a master password to lookup the current password).

Something. I'm just brainstorming here, so I'm sure someone could come up with something that is better in the particulars, but the principal, I think, is good - don't use a known default password that is the same for every installation of a server product. That will shut down a heck of a lot of problems like this.

Re:Maybe servers should have better 'default' pass (2, Insightful)

antifoidulus (807088) | more than 6 years ago | (#22551376)

The safer(imo) is to make the product do almost nothing until the default password is changed. However, most vendors like to advertise "works out of the box!" so the odds of this happening are about 0....

Re:Maybe servers should have better 'default' pass (1)

Carnildo (712617) | more than 6 years ago | (#22553348)

For hardware like home NAT routers and the like, I'd just print the default password on the label, right next to the serial number -- or just use the serial number as the default password.

Re:Maybe servers should have better 'default' pass (1)

Marcos Eliziario (969923) | more than 6 years ago | (#22563338)

It's not good because serial Numbers are err.... serial.
You could of course print a somewhat random formula to be used as a hash function to be fed with the serial. The user would have to calculate this by hand to find out the default password. Anything involving partial differential equations would nicely fit this purpose with the advantage of being utterly user-friendly.

Re:Maybe servers should have better 'default' pass (1)

Carnildo (712617) | more than 6 years ago | (#22577708)

Doesn't matter if they're sequential -- if there are a hundred thousand Linksys WRT54Gs out there, that's a hundred thousand passwords you'll have to try for each router you're attacking.

Passwords (1)

Jack Conrad (898450) | more than 6 years ago | (#22550612)

Actually, if you forced everyone, upon installing/activation/account generation to implement a passcode, then this would not be as much of a problem. (And by force, I mean this program will not install or run; or the user's account will not be created unless the user creates a password).

Re:Unfixed exploits? (1)

speculatrix (678524) | more than 6 years ago | (#22550860)

I'm sad to say that even people who should know better are lazy with security. A guy a work is a good web designer, and before they hired me as sysadmin, shared the admin with a couple of colleagues, and *seemed* to know what he was doing. Well, not at all. His webapps connect to the database using his own personal login, with dictionary words as passwords, he doesn't set a root password, doesn't put anything into the mysql tables to restrict which hosts/users have access, and thus the system is wide open. His reasoning? Because the DB is behind a firewall it doesn't need any security.

we took away his logins to the DB... but snag is the time it will take to fix his code to ensure it uses a minimally priviledged login.

sigh. so, yes, this /. thread does not surprise me, and I'm sad, people have learned nothing :-(

Re:Unfixed exploits? (1)

Architect_sasyr (938685) | more than 6 years ago | (#22552516)

I routinely wiped the database via the website at a place I used to work at, and detailed the process every time.

Two years later and I see that the database is still attackable via anyone with a copy of "Advanced SQL Injection" and an hour spare.

Never underestimate the power of human stupidity.

Re:Unfixed exploits? (1)

speculatrix (678524) | more than 6 years ago | (#22557042)

I recall a recruitment agency whose job search put the SQL into webpage as links for next and previous. Do could change the URL to be "drop table X" instead, and it worked. Yes really. I'm still stunned by that.

Re:Unfixed exploits? (0)

Anonymous Coward | more than 6 years ago | (#22555486)

Just last week I did a short gig with a fairly respectable design firm. They're using root with no password for MySQL authentication. This is on a server hosting 20+ _live_ commercial PHP projects/sites. As for me, I just shook my head and didn't even mention it.

Re:Unfixed exploits? (1)

LrdDimwit (1133419) | more than 6 years ago | (#22553850)

Nobody should be surprised by password issues anymore. That's like being surprised that some people cheat on their taxes; it's just a fundamental part of human nature.

Anyone remember these [wired.com] stories [hamptonroads.com] ? Someone got an ATM manual off the web, learned the default password ... and walks up to an ATM, switches it to debug mode, makes it think the $20's were actually fives -- oh, and dispense everything in fives. And promptly makes off with hundreds of dollars by cleaning out (untraceable) prepaid debit cards.

One of the most telling points is that there's a year's difference between these two stories. Another is that the default passcode to some models of ATM is 123456. And this is for ATMs, where there's a very obvious and immediate impact to lax security (many thousands of dollars lost per incident since the reprogramming can go undetected for days). Considering this, it's not surprising that SQL server passwords don't get changed, for exactly the same reason: "I cut meat and I sell groceries. That's my job. I don't know anything about [securing] an ATM." is not all that far from "I'm just an application developer, I use SQL to get stuff done for the business. What do I know about security?"

Both are regrettable (they both have the same end result; pwnage) and they both flow from human nature.

Curious blind spot (1)

KublaiKhan (522918) | more than 6 years ago | (#22550340)

Presumably, the sysadmins at those companies are at least semi-competent, given that they've blocked SQL access from outside--but why is it that the various vulnerabilities have not been patched?

Is it perhaps because SQL is not something that is particularly high-profile patchwise, unlike operating systems and webservers? Or are unauthorized users running various SQL databases for internal department issues or whatnot, outside the official purview of the IT departments? Or perhaps is it a case that the administrators of the databases are simply unaware that they can be compromised in this fashion?

Re:Curious blind spot (1)

techpawn (969834) | more than 6 years ago | (#22550460)

Or perhaps is it a case that the administrators of the databases are simply unaware that they can be compromised in this fashion?
I think you, sadly, have nailed it. I find more companies have someone who is not qualified to be a DBA performing DBA tasks. I've been to too many SQL classes as refresher courses where the people are coming from data entry positions to DBA roles. Blind leading the blind.

Re:Curious blind spot (1)

KublaiKhan (522918) | more than 6 years ago | (#22550536)

Ah, so the usual: educational weaknesses with a side order of shiny-suit apathy towards said education.

Well, it's a way to sell custom DB installations, I guess--whip up a glossy brochure with lots of FUD over DB insecurities, and offer a "locked down" version with an installer that asks for the SA password on installation, much like most current Linux distros.

Or, hell, just whip up a script that'll "secure against intrusion" and sell that off for a few thousand bucks per unit. Higher the price the better--if it's expensive, it -must- be worth it.

Re:Curious blind spot (0)

techpawn (969834) | more than 6 years ago | (#22550610)

I have no problem with people "working their way up". It kind of makes me glad to see it, but, I feel you do need SOME kind of IT background. SQL Admin isn't just wizard ran software there homeslice.
In my experience the SQL Admin is a bit of a developer, a bit of a sysadmin, and something all of their own. To hear that they where only ever data entry makes me shutter! I'm more comfortable with shifting from within IT than from the secretary pool.

Re:Curious blind spot (1)

Shados (741919) | more than 6 years ago | (#22550570)

Yup. I worked in a company thats in the fortune top 10... so a company that has millions upon millions of dollars of transaction saved per day... Their DBA Is a "Senior" DBA, having almost more years of DBA experience than I have years of BREATHING experience...

Yet they had no clue what synonyms were... no clue how to solve table locking issues (a common SQL Server problem and one of its main flaws in the 2000 edition and before, but if you're going to go the SQL Server route, you need to know how to handle it), no clue how to configure any kind of horizontal scaling except for replications... It was seriously pathetic... And that person was the only one who had admin access to the database... it was rediculous.

I know close to nothing about database administration, and I could remotely own that server in 20 minutes, and cause all sorts of hell. In the current IT environment, good DBAs are rare...and existing (crappy) DBAs are never replaced unless things aren't working (and as long as they're not hacked, things are "working", even if poorly).

Re:Curious blind spot (1)

Splab (574204) | more than 6 years ago | (#22551014)

I work as a DBA and have never heard of synonyms, but thats because its a MS SQL specific thing? I have worked a few years as TA on introduction to SQL, and I'm pretty sure none of the books I have mentions synonyms. (Just googled it and it seems to be MS and oracle specific which is DBMS I've never worked with, while I see the usefulness of it, slamming someone for not knowing about them or not wanting to use them is wrong (imo))

Solving locking issues can be very tricky, especially since quite a lot DBMS out there hides how locks are acquired, if you can't look under the hood, figuring out whats wrong is something you would probably pay the DBMS provider to fix.

"... no clue how to configure any kind of horizontal scaling except for replications..."

So its that easy, just point n click next a few times and everything works? Managing multiple write masters (read scaling is trivial) is very hard and can easily lead to transactions working on bad or outdated data, do you have some magic wand that solves this? I sure as hell would like one of those.

"I know close to nothing about database administration,"

But yet you chose to slam someone for not taking the route you want, even though you properly have no idea about what decisions are behind the current setup. Do you have any idea how complicated it can be to change anything on a live database? Just figuring out the performance impact of ADDING an index to a table can be quite a horrendous task. Nothing is simple, especially when the system you are trying to keep alive is an outdated box which probably isn't allowed to be taken off line for updates.

Re:Curious blind spot (1)

Shados (741919) | more than 6 years ago | (#22551482)

You didn't know of synonyms, but you've also haven't been working (from your post) with RDBMSs that have it as a first class feature for almost a decade, so its normal... I don't know much about non-standard compliant features of MySQL or Postgres either. In an SQL Server environment however, its no more obscure than the temporary table syntax. For locking issues, in SQL Server, its stupid simple: if your stored procedure is used mostly in static data (a report or something), you add the No Lock optimizer hint. If you're in SQL Server 2005, you have to investigate the various locking mechanisms, especially the snapshot kind. While thats not the answer to everything, 90% of the time those 2 things solve it (assuming you don't use explicit cursors, in which case it does become tricky, but in SQL Server, which is the environment it was in, there's a big red flag around cursors, so there wasn't a single one in any of the T-SQL written anywhere). For the other 10%, you have system stored procedures that will pop up exactly the cause of the lock, when it happened, why, at which level, its progression, etc. Add the SQL Server profiler, and you're set.

For horizontal scaling, I said no clue on how to configure. That is, didn't even know which options were available. The method they selected was a real time replication. If you're willing to take the performance hit of real time synchronisation of any kind (that is, transaction per transaction), then virtually all methods you can pick WILL be "point and click". The only time its tricky is if its not real time sync (which is most of the time for any real system, and THAT is hard...but its not what that DBA had picked). Mirroring, table partitioning. All simple methods that need to at least be CONSIDERED. But if you don't even know they -exist- (not you, the person I'm replying to, but them), its quite troublesome.

For "the impact of adding an index on a table", I may not be a DBA, but I've always had to handle this, yes, including on live databases. So yes, I am well aware of how that works :)

Really, I don't know which RDBMS you are used to admining...different ones have different things that are easy or hard about them. There are a lot of things about SQL Server and Oracle that are far beyond my grasp. Even the most complex index, locking scheme, or replication system aren't part of them.

Again though: If you're neither a Oracle or SQL Server DBA (which are more or less direct competitor, so have a remotely similar set of features), then obviously my comment may come as a huge "WTF!". For the little I've worked with DB2, MySQL, DBase, Pervasive and Postgres, they were totally different beasts. The DBA I'm thinking off was purely an SQL Server/Oracle DBA, however (we had DB2 databases, but aside for the security aspect, they were handled by external consultants).

Re:Curious blind spot (1)

Splab (574204) | more than 6 years ago | (#22555906)

I should probably have clarified it. We use Solid for our HA/HP system, their replication scheme is probably the fastest I have seen around.

Hinting a no lock will of course remove any issues, but asking it to remove the locks might not be a good idea, I would certainly have someones head removed if they decided to run without locks on my system.

And we do use explicit cursors, its fast and we get to choose what is dropped when.

About the horizontal scaling, you just made it sound like everything is a piece of cake, when running a HA/HP setup nothing is easy, you have to be very careful stuff breaks easily. The reason why I talked about adding an index is most people are unaware of the fact that an index might make things run quite a bit slower, you might fix one little part of your system, but others might start to go to a grinding halt.

and yeah, those comments made me go WTF :D

Re:Curious blind spot (1)

KiloByte (825081) | more than 6 years ago | (#22550766)

Not just DBAs, it's nearly all administrators.

I have seen one (1) customer where the resident admin asked for an account to install the server-side piece of our software provided something else than "root", even when explicitely told not to. I don't think I need to describe the rest of the security at their places. I've learned that trying to tell them anything about the basic common sense rules is counterproductive, too. If I try, I and our company get labelled as "troublemakers" behind our backs. Even (or especially) if there's some push from higher up.

Re:Curious blind spot (0)

Anonymous Coward | more than 6 years ago | (#22551524)

I have seen one (1) customer where the resident admin, when asked for an account to install the server-side piece of our software, provided something else than "root", even when explicitely told not to.

It took me a while to parse your original statement, so I added some commas and a "when" to make it easier to read for those who come after me. Hopefully I parsed it correctly.

Re:Curious blind spot (1)

jellomizer (103300) | more than 6 years ago | (#22551068)

A good SQL Developer not a DBA Make. I am a good SQL Developer, My SQL Calls really blow the pants off some people who said to me that you can't do that in SQL... But... I would make a sub par DBA. I can probably get the job done and keep the company in one piece, But I would probably make bad decisions on what policies to set up for the users Give them to much or too little, etc... It is the same time as a good software developer doesn't make a good system administrator. They are actually very different skills. A good DBA could Stink as a SQL Developer the same as a Good System Administrator is a bad programmer.
There are some people that can do both jobs equally well and above average but others take some tradeoffs.

It's cheap to try (1)

Threni (635302) | more than 6 years ago | (#22550352)

Trying SA,"" is cheap. Why wouldn't you try it?

Cloudy pee (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22550368)

If you eat a whole jar of Horlicks or other malted milk drink your pee with go cloudy.

Try it.

http://en.wikipedia.org/wiki/Horlicks [wikipedia.org]

The problem is (0)

Anonymous Coward | more than 6 years ago | (#22550384)

that you need to take a stick, wind it around the worm, and slowly pull the worm out over a period of a couple of months. If you pull too hard it will break. So you need to be patient. I think this is a metaphor for life and computers, though a little diethylcarbamazine will make the infestation much more pleasant.

pulling the worms out (2, Funny)

Gary W. Longsine (124661) | more than 6 years ago | (#22550728)

Your metaphor is creepy. I won't be using it in any marketing campaigns.

Re:The problem is (1)

kalirion (728907) | more than 6 years ago | (#22551466)

Wouldn't it be easier to wind the worm around the stick?

70% really? (1)

liquidpele (663430) | more than 6 years ago | (#22550390)

I don't see that many myself... that's a pretty high number.
Most of mine lately are the windows RCP exploits and the exploit for old symantec overflows on port 2967. That, or I used to get a lot of traffic from SSH brute force attacks and malicious HTTP stuff...

Re:70% really? (1)

cnettel (836611) | more than 6 years ago | (#22550680)

I don't see that many myself... that's a pretty high number.
Most of mine lately are the windows RCP exploits and the exploit for old symantec overflows on port 2967. That, or I used to get a lot of traffic from SSH brute force attacks and malicious HTTP stuff...
Do you mean RPC? (Not trolling, I was really confused and that's the explanation that makes most sense to mean.)

Re:70% really? (3, Informative)

tcopeland (32225) | more than 6 years ago | (#22550842)

> I used to get a lot of traffic from SSH brute force attacks

Yup. One of the first bits I install on a new server is DenyHosts [sf.net] ; "service denyhosts start" and an hour later there are a half dozen IPs in /etc/hosts.deny. Good times.

Re:70% really? (1)

VGPowerlord (621254) | more than 6 years ago | (#22553158)

I used to use denyhosts on a remote machine until I nearly locked myself out while trying to set up a svn+ssh client (I had the syntax wrong).

The only reason I wasn't locked out is because I had an open SSH session currently in progress.

Re:70% really? (1)

tcopeland (32225) | more than 6 years ago | (#22554270)

> I nearly locked myself out while trying to set up a svn+ssh client

Yeah, that's a bad feeling. But the good thing is that you can usually ssh in from some other subnet. Unless you've already set up AllowHosts or something, in which case, yeah, a drive to the colo is in your near future :-)

Re:70% really? (1)

plague3106 (71849) | more than 6 years ago | (#22550942)

I used to get a lot of brute force SSH attacks as well when I was running a Linux server. I was glad that I ONLY allowed access via public key exchange and not passwords.

Re:70% really? (1)

SailorFrag (231277) | more than 6 years ago | (#22553698)

Instead of disabling passwords completely to stop the brute force SSH attacks, I disable password authentication but leave public key and keyboard-interactive enabled. Keyboard-interactive is just a fancy way to request a password by default, but won't work with the brute force attacks I've seen so far. It's not going to work forever, but seems to be effective for now.

Re:70% really? (1)

TheLink (130905) | more than 6 years ago | (#22554570)

I just run the sshd on a different port. That way if someone targets my sshd, I KNOW something unusual is going on.

If someone writes a "zero day" worm, they are likely to stick to the default ports to maximize the spread speed. So that means I have more time to fix the affected service.

There are people who think obscurity isn't useful, and there are people who genuinely have more time to read Slashdot :).

Re:70% really? (0)

Anonymous Coward | more than 6 years ago | (#22551292)

You apparently did a little too much LDS during college.

Re:70% really? (1)

TeknoHog (164938) | more than 6 years ago | (#22551664)

You apparently did a little too much LDS during college.

Yeah, too much of those Latter Day Saints can really ruin your life.

Team 17 just made it too good (3, Funny)

Alzheimers (467217) | more than 6 years ago | (#22550662)

What can I say? Team 17 made it a fun, accessible, simple yet requiring thought and strategy. The later 3D versions had problems with the camera, and the humor never matched up to the original.

Re:Team 17 just made it too good (1)

ashridah (72567) | more than 6 years ago | (#22550704)

Rofl. That took me way too many rereads to get.

Thinking to myself, "Worms, what does worms have to do with an article about sql worms .... oh. right."

I really need to take a nap after lunch, it appears.

Worms: 2 was the best... (1)

techpawn (969834) | more than 6 years ago | (#22550738)

The First of many...

maybe... (1)

mitchplanck (1233258) | more than 6 years ago | (#22550694)

I can imagine a legacy system never getting patched because everyone is afraid that it won't boot up properly or they need it up 100% of the time.

I can imagine a blank password due to struggling with ignorant users and bad application coding.

Re:maybe... (1)

Briden (1003105) | more than 6 years ago | (#22551058)

I see, you must have really worked in the industry then. Fact is, there is a reason that defaults are used, and that they are attacked: simplicity. Simplicity is also responsible for many deliberate "loosening" of security reasons, most commonly in development to "get it working", then, a thought is put to beefing up security later. a good thing? certainly not. what's going to keep happening? certainly. i'd have liked to see the look on someones face when the first piece of malicious traffic ever traversed the internet. it'd look like this: >:( shit. i never thought someone would do that. dammit. 30 years later and the same stuff is still happening, is anyone surprised? Out of curiosity, does anyone know the specifics on when the first "malicious" packet was sent? this seems like the right place to ask.. from where to where, and from whom to whom?

Why?? duuh (1)

xtracto (837672) | more than 6 years ago | (#22551044)

Because 0ld SQ00l never dies!!

*rimshot*

Hmm, viable infection vectors still used... (0)

kabocox (199019) | more than 6 years ago | (#22551086)

Let's see. Viable infection vectors are still being used. This is kinda common sense. I expect to see a Phd paper on it next week.

Let's compare this to medical infection vectors. There is sexual, by touch, by air, by liquid/drink, or by food. I can't really think other disease transmission ways. We've got what millions of bacteria/viruses spreading by those means every second. As long as its still effective, it'll still be in use.

I think of net security sort of like keeping a eco system healthy and without too many hostile diseases/organisms about.

Humans don't have to worry about too many predators because we kill off any thing that tries to kill us. We've only recently become aware of microscopic things trying to kill us. So it's not surprising if we'd try to kill off all the diseases that usually attack us before they get us. We aren't too good at it, yet. There is a part of me that thinks that one of the reasons that we'll finally crack nano machines is that we'd have our unofficial war on all disease and spend trillions on it.

Now apply that thinking to the virtual world. Currently, we can only be economically hurt by ID theft through security breaches. I guess there is potential to get really upset if your medical info or other private stuff is leaked in a breach, but we generally can live through it and since we do "live through it" we can scream bloody murder at the people/companies responsible to stop that behavior in the future. Worse comes to worse we can even take political action and get the government to do something.

Our whole virtual ecosystem isn't very old. Wait for it to get a few decades older and then let's see if these same attacks are still around. How many attacks from the 70s or 80s are still floating around and effective? I wouldn't be surprised it all to find 90s stuff targetting win95/win98 computers still around.

More disease vectors -- mostly OT (1)

patio11 (857072) | more than 6 years ago | (#22554342)

Blood to blood contact (fairly rare, thankfully -- mostly of a concern to medical workers)
Parasitic infection (mosquito is carrier of malaria, mosquito bites you, etc)
Pathogen touches skin (thankfully, we're pretty robust against this, but it worths for some pathogens and for folks with weakened immune systems. You might be familiar with planter's warts, athlete's foot, etc.)
Pathogen enters through compromise in skin (nick finger, open floodgates)
etc, etc

Basically, all you need for an infection is to get a pathogen inside a cell it can infect. A vector can be anything that compromises your body's numerous and insanely effective defenses against that happening. (Oh sure, we get sick fairly frequently from our point of view, but we're walking around in a lethal organic soup for every minute of our lives. That tabletop you just disinfected makes the .ru namespace look like a threat-free Eden.)

Re:More disease vectors -- mostly OT (1)

kabocox (199019) | more than 6 years ago | (#22559320)

Basically, all you need for an infection is to get a pathogen inside a cell it can infect. A vector can be anything that compromises your body's numerous and insanely effective defenses against that happening. (Oh sure, we get sick fairly frequently from our point of view, but we're walking around in a lethal organic soup for every minute of our lives. That tabletop you just disinfected makes the .ru namespace look like a threat-free Eden.)

Sometimes I'd want my immune system running my virtual security. It would do a better job.

Running an entire suite of old exploits (1)

halcyon1234 (834388) | more than 6 years ago | (#22552600)

And why shouldn't some malicious attacker use every single exploit they've ever written/downloaded/stolen in their botnet payload? It's not like they're really concerned about bandwidth or CPU loads.

Umm....SQL? (0, Offtopic)

Karellen (104380) | more than 6 years ago | (#22552676)

Uh.....so what is so special about SQL? Why are SQL worms so prevalent compared to C worms, or PHP worms, or Java worms, etc...?

OK, so SQL injection doesn't require the kind of in-depth knowledge to exploit that buffer overflows in C do, so I imagine SQL exploits might be easier to craft to begin with ... but surely they're easier to spot. If you're pasting values into an SQL string instead of using named/positional parameters, you're vulnerable. That sort of thing should be much easier to do an automated search for in your source than buffer size tracking through C sources.

Also, does anyone else think the following does not make much sense: "Most [botnet hosts that perform the scans] are not running exposed SQL themselves..."? Why not "...running badly-written SQL..." or "vulnerable SQL"? Seems like a really weird choice of words.

Re:Umm....SQL? (1)

Karellen (104380) | more than 6 years ago | (#22557400)

Offtopic? WTF? How is "I read TFA and it doesn't make sense or explain things well" offtopic?!?

Because my boss won't let me patch my SQL Servers! (0)

Anonymous Coward | more than 6 years ago | (#22557668)

I have several SQL Server 2000 boxes that are totally unpatched -- they're at the RTM level. They are theoretically vulnerable to Slammer, I have to have faith that my network security guys know what they're doing.

Yes, I've jumped through the hoops, put in requests, submitted an action plan along with a failure plan. He hasn't done anything. So there my servers sit, vulnerable.

At least I have the paperwork to show that I tried.

I'm not sure that the quote is meaningful... (1)

argent (18001) | more than 6 years ago | (#22558196)

It seems to me that what they are saying is not that 70% of malicious traffic is SQL worms, and 30% is other kinds of worms, but that 70% of the worms include SQL attacks in their repertoire.

I have made a few attempts to backtrack hosts that perform the scans and at first blush many show the signs of common botnet infections. Most are not running exposed SQL themselves, so that means that the code has likely been implemented into many bot-net exploitation frameworks. Perhaps the bot masters have the idea that when they infiltrate a commercial network, the SQL exploits will be available and useful to them? My assessment team says this is pretty true. Even today, they find blank "sa" passwords and other age-old SQL issues inside major corporate clients. So perhaps, that is why these old exploits continue to thrive.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?