Fully Automated IM Worms on the Way?
nanycow writes "The sudden appearance of a rootkit file in a spyware-laden IM worm attack has set off new fears that malicious hackers are sophisticated enough to launch a fully automated worm attack against instant messaging networks. Researchers say the stage is set for a worm writer to use an unpatched buffer overflow in an IM app to unleash a worm that is capable of infecting millions or users without the use of malicious URLs that require a click."
How is this any different any other services attached to a port on your computer? Whenever a listening program has an overflow vulerability there is the potential for "A fully automated worm." Granted there is a lot of IM software out there, but there have been plenty of ports and services on Windows that have been exploited in a fully automated way in the past. At least IM software is a _bit_ more heterogeneous than Windows.
Spencer Ogden
No social engineering by seducing (l)users to click on a link. Real virus multiply themselves!
So what is the issue with this?
My wife's sketchblog Blob[p]: Gastrono-me
Its a shame that AIM is so widly used in the workplace even though is so vunerable .... ....
I know our IT department frowns upon it but walking around you still see it used
Its only a matter of time until something like this came out that has the potential to severly damage both corporate and private networks
Ahh... not so fast.
;-)
These viruses seem to be intelligently designed.
Not quite. Biological viruses evolve. Computer viruses, however, are products of intelligent design, for certain values of 'intelligent'.
Computer viruses aren't a force of nature. Behind every one of them is a malicious programmer.
Eventually, I imagine we'll see polymorphic and self-modifying code reach the point where it can evolve in the same way as biological viruses, but that's probably quite a way off. The nearest I've heard of to that is viruses programmed to alter their appearance to avoid detection.
Real Daleks don't climb stairs - they level the building.
The editors usage of the term rootkit is correct, and proper. You may as well argue that the usage of 'cockpit' for the pilot seat and control area of an airplane is incorrect. From the relevent wikipedia article.
.exes and registry entries.
Generally now the term is not restricted to Unix based operating systems, as tools that perform a similar set of tasks now exist for non-Unix operating systems such as Microsoft Windows (even though such operating systems may not have a "root" account).
Rootkit is no longer a term restricted to gaining "root" user access. The term now stands for any suite of hack and/or programs (the "kit") that enables the malware to disguise its presence in the OS in a more sophistocated manner than simply having obscurely named
Furthermore, in my entirely humble and sincerely personal opinion, the term is an appropriate, apt, and succinct way of decribing these types of malicious programs, both in distinguishing them from the less deeply embedded malware types, and in emphasising the increased security threat these programs pose.
May the Maths Be with you!
Your safe. Not because Adium can't be compromised, but because no one cares enough to do it.
What's stopping MS from implementing a Unix-style security model?
Your mom. Litereally.
I understand users/groups/file permissions. I assume you do too. What about your parents?
--You will rephrase your request for me to go to hell. Goto statements are not acceptable programming constructs
At a user level, to "see" a process, you would open the task manager (Windows) or use the PS command in Unix. But you must note that these are merely applications that ultimately make a call to a OS level API and request this information; then they display whatever this API returns them.
The OS level API is just a piece of code that will have access to the internal OS data structures that hold the information for the processes. This code would piece together a response with the processes names, etc. and return this "list".
So, what would happen if I go and modify the code that pieces together this list of processes and omit the "worm.exe" process everytime? Well, that's pretty much a rootkit virus strategy.
The result is that you wouldn't be able to see the process anywhere. Any program that uses this OS API call would not see the process, be it ps, the Task Manager or an Antivirus.
So . . . why not providing every program with a direct access to the running processes structures so that they can "see" all the information there and "figure out" by themselves whether there is a virus or not.
Well . . . that's a disaster from a security standpoint since it would provide an avenue for viruses to exploit. And this "direct access" is never direct, it is always through another OS API that may in turn be modified to hide the virus . . .
So . . . why not scanning the disk?, I mean, the virus must be stored somewhere if it will run.
Well . . . file access is done by an OS call that may be modified to hide the virus.
So . . . why not doing an OS module that performs an CRC check and make sure that the OS APIs have not been modified?
Well . . . this too can be modified not to include the file that you infected in the first place.
So . . . why not making OSs "unmodifiable".
Well . . . how would you then install it in the first place? (that is pretty much a modification) or install security updates? (that's another modification).
So . . . Well . . . ad infinutum.
I think I made my point.
Anyways, the bottom line is that you can only do all those modifications *if* you have privileges to modify system files. You have to have "root" access for that. So once you have broken the security of an OS to the point where your virus can modify OS system files, you are pretty much doomed.
Ideally, the solution is a secure operating system, where regularly you run your user programs with an account whose privileges do not include modifying OS files and any processes that you start cannot breach that security (again *ideally*). You would only use the root account to do OS installs and updates (if the virus gets you while you are at it, you are doomed again, so shut down AIM!).
That's why Windows is so dangerous, because the normal XP user is running with an Administrator account (similar to having root privileges), so any application that is infected can potentially cause a root-level infection.
And then, no matter how much you program securely, the missing piece as usual is education. At some point, even in the ideal OS, the user would have to log in with the root account to do OS changes or at least explicitly authorize in some manual way the modification of system files (that would be my choice just to make things easier to learn for everyone in the real world).