Bots: They are not just for Windows anymore.
Couple readers noted the use of the "kaiten" bot in some of the recent php exploits. The php vulnerability is used to install kaiten, which like all well behaved bots will connect to an IRC channel and do its master's bidding.
We kind of have come used to seeing "bots" as a Windows issue. But to be fair: Kaiten probably pre-dates a lot of the Windows worms and bot. IMHO: its so much easier to write a bot for Linux. You got perl after all. I wouldn't be surprised to find one written in bash.
On realy quick and dirty way to fool bots in Linux: make 'tmp' its own partition and mount it as non-executable. This will fool probably 80% of the bots, as they start out by writing themselves to /tmp. Don't forget to make /usr/tmp and /var/tmp symlinks. If you don't want to repartition: use a loopback file. Most Linux malware will compile itself on the target system. So removing development tools is always an option but a bit painful for many. And you may not be able to do without perl. I wouldn't be able to make coffee in the morning without it, and without coffee not much would be happening here.
We do get LOTS AND LOTS of reports about various php exploit attempts. Its one of these things where you are probably already long exploited if you are vulnerable. The exploit attempts target a long list of vulnerable php applications. Nothing particular fancy, just more and more of it.
We kind of have come used to seeing "bots" as a Windows issue. But to be fair: Kaiten probably pre-dates a lot of the Windows worms and bot. IMHO: its so much easier to write a bot for Linux. You got perl after all. I wouldn't be surprised to find one written in bash.
On realy quick and dirty way to fool bots in Linux: make 'tmp' its own partition and mount it as non-executable. This will fool probably 80% of the bots, as they start out by writing themselves to /tmp. Don't forget to make /usr/tmp and /var/tmp symlinks. If you don't want to repartition: use a loopback file. Most Linux malware will compile itself on the target system. So removing development tools is always an option but a bit painful for many. And you may not be able to do without perl. I wouldn't be able to make coffee in the morning without it, and without coffee not much would be happening here.
We do get LOTS AND LOTS of reports about various php exploit attempts. Its one of these things where you are probably already long exploited if you are vulnerable. The exploit attempts target a long list of vulnerable php applications. Nothing particular fancy, just more and more of it.
Keywords:
0 comment(s)
Getting Ready for the Holidays
We had a couple reports from readers, who tried to contact abuse departments or notify companies about breached systems, only to receive a "vacation" reply indicating that the systems are on autopilot until sometime next year.
Unless you turn off the systems, they will still need a bit of watching and caring. Do you have someone on call in case the burglar alarm goes off? Make sure you have someone checking the 'abuse' or 'security' mailboxes once a day (at least). You may have them even forwarded to a pager if you can filter the spam.
And while I am on the topic: Make sure you do actually have an 'abuse' and a 'security' alias for all of your domains. There are a number of aliases you should define for each of your domains:
RFC2142 provides a number of references to other RFCs, and suggests the following aliases:
Spam to these addresses has become a problem. I don't think there is a great solution, as some of the mail sent to these mail boxes may include copies of spam messages (even if you don't send them, others may impersonate you and you still want to know. Abuse reports are one way you will find out).
I can't find a reference right now (but I am sure someone will write with the correct RFC for it), but it is commonly suggested to also maintain a '/security' URL on all your websites. This URL should be used to provide contact information for security issues and information about security patches or such for any products you may offer. But this standard, while usefull, is not widely implemented (is it still a 'standard'?).
Last but not least: Have fun this weekend. I think I will run some network cable in my house (already got the big drill, but still need one more Home Depot trip for some conduit). The holiday security guide should be live sometime tomorrow. We got some great input.
Unless you turn off the systems, they will still need a bit of watching and caring. Do you have someone on call in case the burglar alarm goes off? Make sure you have someone checking the 'abuse' or 'security' mailboxes once a day (at least). You may have them even forwarded to a pager if you can filter the spam.
And while I am on the topic: Make sure you do actually have an 'abuse' and a 'security' alias for all of your domains. There are a number of aliases you should define for each of your domains:
RFC2142 provides a number of references to other RFCs, and suggests the following aliases:
- postmaster@domain (RFC822). This should exist on all mail servers. You should also have postmaster@IP-Address-of-the-mail-server.
- usenet@domain (RFC977). I know a lot of people will write to say differently. But I consider usenet dead for all practical purposes. You can probably do without this address.
- abuse@domain
- trouble@domain
- noc@domain
- security@domain
Spam to these addresses has become a problem. I don't think there is a great solution, as some of the mail sent to these mail boxes may include copies of spam messages (even if you don't send them, others may impersonate you and you still want to know. Abuse reports are one way you will find out).
I can't find a reference right now (but I am sure someone will write with the correct RFC for it), but it is commonly suggested to also maintain a '/security' URL on all your websites. This URL should be used to provide contact information for security issues and information about security patches or such for any products you may offer. But this standard, while usefull, is not widely implemented (is it still a 'standard'?).
Last but not least: Have fun this weekend. I think I will run some network cable in my house (already got the big drill, but still need one more Home Depot trip for some conduit). The holiday security guide should be live sometime tomorrow. We got some great input.
Keywords:
0 comment(s)
Update - Symantec RAR File Parser Remote Heap Overflow
ISS X-Force's Symantec RAR File Parser Remote Heap Overflow analysis says "The likelihood of this vulnerability being leveraged by a worm is low as successful exploitation requires a very large RAR file, in the area of 35-40MB. Files this large are not generally passed by mail servers and can eliminate this as a vector for a worm. X-Force believes this is still a serious threat since the vulnerability can be leveraged to exploit AV mail gateways. Desktops which employ the on-demand scanning function could also be exploited without user intervention when scanning files downloaded by FTP or HTTP on the desktop."
Thank you for the information X-Force!
Symantec's announcement -
SYM05-027, December 21, 2005, Symantec AntiVirus Decomposition Buffer Overflow
Thank you for the information X-Force!
Symantec's announcement -
SYM05-027, December 21, 2005, Symantec AntiVirus Decomposition Buffer Overflow
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments