Posted by
CmdrTaco
on from the random-dune-reference-here dept.
randomErr writes "The worms, Slapper.B and
Slapper.C, which exploits a known buffer overrun vulnerability in the Secure Sockets Layer 2.0 (SSLv2) handshake process has infected thousands of Web servers worldwide, according to Helsinki-based F-Secure Corp., a computer and network security company. "
use chkrootkit to see if you've gotten it
by
motorsabbath
·
· Score: 5, Informative
http://www.chkrootkit.org/
version 0.37 has been updated to find the slapper - JB
-- The heat from below can burn your eyes out
Re:use chkrootkit to see if you've gotten it
by
RudeDude
·
· Score: 2, Informative
FYI The most common MD5 sig for the 0.37 tarball seems to be: b0feebea67655daa440da92099dd5187
But for some reason I also see a different MD5 for what is supposed to also be 0.37: edf50a9c8c6bf09b0a9147f2e6168826 BUT that is actually the signature from 0.35
So the bottom line is, try not to panic. Some mirrors are just a little out of sync. I am still a little nervous running this thing as root since I haven't seen anyone report that it's not a trojan itself. I guess some code review is in order.:)
-- RudeDude
Perl/Linux/PHP hacker
Re:A few hopes...
by
larien
·
· Score: 5, Informative
The patches have been out for over a month, I'm pretty sure of that. I downloaded the patches as soon as Debian had the new ones online.
So, in short, it's an old bug, it's been patched, and the only ones getting hit are people who haven't patched their openssl libraries.
Same mantra applies to Linux and MS sysadmins:
by
bittmann
·
· Score: 5, Informative
1) Don't enable services and features you don't need (or in MS sysadmin speak--DISABLE all of the services and features you don't need that have "helpfully" been activated in the base install); and
2) Keep up to date on your patch levels.
You don't have to be bleeding-edge on patches, but when a security vulnerability with malicious code in the wild has been detected, it's time to *DO* something about it!
Really, I wonder how many of these infected websites were actually USING SSL, as opposed to having that port hot but unused...
Re:Same mantra applies to Linux and MS sysadmins:
by
petard
·
· Score: 5, Informative
I would add the following:
3) Don't install a development environment (e.g. gcc, which is required for this worm to propogate) on a publically exposed web server!
Obviously, this won't work for people with only one box who want to run their personal web server off of it as well as do their dev work there, but for *real* servers this is a good practice. People who must have compilers on their web server are probably not using SSL, as you stated:-).
If you must use a compiler on your web server, FFS run the publically accessible service in a chroot jail!
-- .sig: file not found
CERT Advisory
by
Anonymous Coward
·
· Score: 5, Informative
How to test yourself
by
pbur
·
· Score: 5, Informative
If you were like me and wondered if after the OpenSSL upgrade that you actually patched everything right, you can compile and run this program to find out:
http://cert.uni-stuttgart.de/advisories/openssl- ss lv2-master/openssl-sslv2-master.c
It will connect to your HTTPS server and check it. Unfortunatly, it won't connect to SSH. It helped me make sure I was patched up at least for apache.
And I have never quite understood why the advisory says to recompile your apps as well. If they are using the Shared Library, where the problem actually exists, then they get the upgrade by default. Now, if you had some static compiles, then sure.
Pbur
Re:How to test yourself
by
jooniqzb1tch
·
· Score: 3, Informative
be sure to check your sendmail as well if you're using TLS,possibly stunnel and any other ssl enabled server you run.. (well it does not check ssh). I had patched apache immediately but this tool made me realise I had forgotten about sendmail:)
Lets just hope Taco isn't doing too much sys admin work these days because this is really old news. Slapper was spotted over a week ago and the news appeared on LWN at the URL below.
here is my mirror of the source: http://sage.che.pitt.edu/~harrold/tmp/chr ootkit.ta r.gz
-- --
john
Re:what does it look like?
by
EkiM+in+De
·
· Score: 2, Informative
Well I'm not entirely sure but I found that in my error_log a couple of bad hits from other Apache Servers. I found the Apache Test page on these servers which I suspect is a bit of a giveaway that perhaps these are not active servers. Anyway I could be completely wrong, but since these hits were from Web servers I kind of suspect that these servers have not been patched.... God I hope that the log entries below don't indicate that I've been hit and damaged
Anyway the hits looked like this:
It doesn't prove that much as there may be fewer Apache-SSL sites on linux than there are IIS sites. Code Red hit all IIS boxes, Slapper only hits Apache on linux, and even then, it requires the presence of gcc and some other conditions to be met before it works.
That said, I would like to see a more in-depth analysis of the proportions of machines which have been hit and are infected. Also, we should bear in mind that the impact is much less on linux as Apache normally runs as a non-root user while IIS almost always runs as a system/admin user.
Re:what does it look like?
by
ceejayoz
·
· Score: 3, Informative
Posted earlier in the thread:
to detect the worm, simply do a ls -al in/tmp you will find.bugtraq.c file etc etc
Also, come the 2.6 kernel, and pluggable security modules, installing stack protectors and tiered security models will be more commonplace and a lot of the stupid holes that have allowed these attacks will simply go away.
One thing that would fix a whole lot of problems is for a security model to be installed that allowed root to delegate low-port and raw-protocol access to non-root accounts.
Granted these particular worms would not have cared, but there have been many remote root exploits that happened only because a daemon needed to be root to create a low port or perform raw protocol manipulation.
Time to chroot apache
by
Icy
·
· Score: 2, Informative
I don't know why more people don't chroot apache or patch to use chroot(2). It can be a pain at times, but it can't be worse then having to reformat and reinstall the entire os because your are not sure what was tampered with. I know chroot is not perfect and you can break out of it, but as long as you are carefull about what goes in it, you are relatively safe. It would at least keep rootkits away from gcc, which seems to be required for most of these rootkits.
Re:We're not really catching up
by
rindeee
·
· Score: 2, Informative
10% of what market you genius? The sector that matters here is machines with direct connection to the Internet. In that sector, Linux outnumbers Windows boxes by a strong (about 3.5 to 1 according to latest Netcraft stats giving Linux/Apache around 60% market share). Me thinks an "Introduction to Elementary Statistics" is in order my friend.
Slappers.
by
burbledrone
·
· Score: 4, Informative
A linguistic note for Americans and other aliens....
"Slapper" is an EnglishEnglish term for a woman with an easily exploited hole....
No, you are actually wrong on that. If you compare the number of IIS servers (they're all windos) and the number of Apache/Linux servers, then Apache/Linux is up front. Even if you double the number to account for people running IIS on their home-desktop, you get nowhere near the "infected-to-unaffected" ratio.
Remember that all the "95% market share" babble is about desktop systems, while both Slapper and CodeRed are targetting server systems, where windos is one among many, and by far not the leader.
It shows that CodeReds growth was exponential at the critical time, which measured only a few hours. Days have passed since Slapper hit the 10k mark, and we haven't seen any considerably higher estimates.
Re:what does it look like?
by
KMitchell
·
· Score: 5, Informative
You'll get some additional stuff in your access log and potentially error log but the telltale sign that (on a patched system) someone is pinging you for the exploit is something like this in your ssl_error_log:
I think the idea is that the slapper worm will try to grab something from server X (which it believes to be infected) and it tries to run that. If I replaced what it was expecting with something else, that can't be my fault - an external entity was grabbing code off my servers and executing it, not me.
Re:Slapper: The threat that wasn't?
by
Dionysus
·
· Score: 2, Informative
Not all Apache servers run on Linux. Not all Linux systems run Apache. Not all Linux/w Apache has mod_ssl.
-- Je ne parle pas francais.
Re:Source Code?
by
whovian
·
· Score: 3, Informative
one might write a wee proggie to sit on UDP port 2002,
Not good enough, I don't think.
I'm seeing remote ports 2140:2144 being used to attempt to connect to port 443.
So, I'm denying port 443 incoming and monitoring all outgoing unaccounted for udp. (Yes, we were infected.)
-- To-do List: Receive telemarketing call during a tornado warning. Check.
Watch for trojans! Use your own binaries!
by
Wee
·
· Score: 3, Informative
Since chkrootkit normally uses lots of stuff that usually lives in/bin (strings, ps, ls, find, etc), make extra sure that you use the '-p <directory>' flag when you run it. That tells chkrootkit to look for the binaries it needs in directory instead of wherever they are found in your path. Before you can do this, however, you need to (from a fresh, known-to-be-clean install) either copy all the needed binaries to a CD-R or to a partition re-mounted as read-only. A real paranoid would re-compile static versions of those utils and then use those. YMMV.
It does very little good to check for a rootkit when all the good GNU stuff in/bin has been trojaned...
-B
--
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Every time I hear about anohter buffer overflow, I scratch my head and ask, "Why doesn't anybody use libsafe? This is a library which, once installed, protects all processes, regardless whether they have been patched or not.
It transparently replaces the libc functions that are the usual targets of stack smashing attacks, and checks whether the stack frame has been overrun. If the stack has been smashed, the process gets terminated forcefully, and root (or other designated contact) gets an e-mail with all the details.
This has been out for several years now, and I am amazed that no major distribution includes this in a standard server install.
-Steve
-- Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
It's NOT a Linux Worm
by
sjvn
·
· Score: 2, Informative
And, it's not an Apache worm either. It's an OpenSSL worm that exploits security holes in OpenSSL 0.9.6f and earlier.
While the current generation of Slapper targets only OpenSSL on Linux, it will try its attack on any system. And, with a little code tweaking, the next generation of Slapper could hammer on any OS that uses older versions of OpenSSL such as AIX, Solaris, Windows. In short, pretty much any OS that uses OpenSSL is potentially a victim.
Could you have it? If you're a Unix/Linux admin, use chkroot version 0.37 and up to find out. It's available at:
http://www.chkrootkit.org/
In any case, anyone who uses OpenSSL should update with OpenSSL 0.9.6g or higher ASAP. And, while you're at, be certain to relink everything since OpenSSL isn't used just by Apache. ISC, for example, used it in their BIND 9.1. Slapper wouldn't hit BIND, but would you care to bet that someone couldn't modify the code to launch a BIND attack--and aren't we all really, really sick of BIND getting bungled?
For more on Slapper, and a listing of patches for many operating systems see:
Slapper: The FUD and the Danger http://www.practical-tech.com/network/n091 82002.ht m
Finally, most of these patches, which would have stopped Slapper dead, were available in late July/early August. Consider it more proof that security is a full time system administrator job.
http://www.chkrootkit.org/
version 0.37 has been updated to find the slapper - JB
The heat from below can burn your eyes out
So, in short, it's an old bug, it's been patched, and the only ones getting hit are people who haven't patched their openssl libraries.
1) Don't enable services and features you don't need (or in MS sysadmin speak--DISABLE all of the services and features you don't need that have "helpfully" been activated in the base install); and
2) Keep up to date on your patch levels.
You don't have to be bleeding-edge on patches, but when a security vulnerability with malicious code in the wild has been detected, it's time to *DO* something about it!
Really, I wonder how many of these infected websites were actually USING SSL, as opposed to having that port hot but unused...
http://www.cert.org/advisories/CA-2002-27.html
If you were like me and wondered if after the OpenSSL upgrade that you actually patched everything right, you can compile and run this program to find out:
- ss lv2-master/openssl-sslv2-master.c
http://cert.uni-stuttgart.de/advisories/openssl
It will connect to your HTTPS server and check it. Unfortunatly, it won't connect to SSH. It helped me make sure I was patched up at least for apache.
And I have never quite understood why the advisory says to recompile your apps as well. If they are using the Shared Library, where the problem actually exists, then they get the upgrade by default. Now, if you had some static compiles, then sure.
Pbur
Lets just hope Taco isn't doing too much sys admin work these days because this is really old news. Slapper was spotted over a week ago and the news appeared on LWN at the URL below.
http://www.lwn.net/Articles/10026/
Thanks.
here is my mirror of the source:
http://sage.che.pitt.edu/~harrold/tmp/ch
-- john
Anyway I could be completely wrong, but since these hits were from Web servers I kind of suspect that these servers have not been patched.... God I hope that the log entries below don't indicate that I've been hit and damaged
Anyway the hits looked like this:
Patriotism is the opium of the masses
That said, I would like to see a more in-depth analysis of the proportions of machines which have been hit and are infected. Also, we should bear in mind that the impact is much less on linux as Apache normally runs as a non-root user while IIS almost always runs as a system/admin user.
Posted earlier in the thread:
/tmp .bugtraq.c file etc etc
to detect the worm, simply do a ls -al in
you will find
Also, come the 2.6 kernel, and pluggable security modules, installing stack protectors and tiered security models will be more commonplace and a lot of the stupid holes that have allowed these attacks will simply go away.
One thing that would fix a whole lot of problems is for a security model to be installed that allowed root to delegate low-port and raw-protocol access to non-root accounts.
Granted these particular worms would not have cared, but there have been many remote root exploits that happened only because a daemon needed to be root to create a low port or perform raw protocol manipulation.
I don't know why more people don't chroot apache or patch to use chroot(2). It can be a pain at times, but it can't be worse then having to reformat and reinstall the entire os because your are not sure what was tampered with. I know chroot is not perfect and you can break out of it, but as long as you are carefull about what goes in it, you are relatively safe. It would at least keep rootkits away from gcc, which seems to be required for most of these rootkits.
10% of what market you genius? The sector that matters here is machines with direct connection to the Internet. In that sector, Linux outnumbers Windows boxes by a strong (about 3.5 to 1 according to latest Netcraft stats giving Linux/Apache around 60% market share). Me thinks an "Introduction to Elementary Statistics" is in order my friend.
A linguistic note for Americans and other aliens....
"Slapper" is an EnglishEnglish term for a woman with an easily exploited hole....
No, you are actually wrong on that. If you compare the number of IIS servers (they're all windos) and the number of Apache/Linux servers, then Apache/Linux is up front.
Even if you double the number to account for people running IIS on their home-desktop, you get nowhere near the "infected-to-unaffected" ratio.
Remember that all the "95% market share" babble is about desktop systems, while both Slapper and CodeRed are targetting server systems, where windos is one among many, and by far not the leader.
Assorted stuff I do sometimes: Lemuria.org
Yes, I actually do believe that we are somewhere near the peak. Maybe not quite yet, maybe we've already passed it.
o deredv2_analysis.xml#infectionrate
Why? Because of worm propagation history. Slapper is old news by now.
Compare this graph:
http://www.caida.org/analysis/security/code-red/c
It shows that CodeReds growth was exponential at the critical time, which measured only a few hours. Days have passed since Slapper hit the 10k mark, and we haven't seen any considerably higher estimates.
Assorted stuff I do sometimes: Lemuria.org
You'll get some additional stuff in your access log and potentially error log but the telltale sign that (on a patched system) someone is pinging you for the exploit is something like this in your ssl_error_log:
[Sun Sep 22 12:45:51 2002] [error] mod_ssl: SSL handshake failed (server YOURSERVER:443, client aaa.bbb.ccc.ddd) (OpenSSL library error follows)
[Sun Sep 22 12:45:51 2002] [error] OpenSSL: error:1406B458:SSL routines:GET_CLIENT_MASTER_KEY:key arg too long
I think the idea is that the slapper worm will try to grab something from server X (which it believes to be infected) and it tries to run that. If I replaced what it was expecting with something else, that can't be my fault - an external entity was grabbing code off my servers and executing it, not me.
Perhaps I misread this idea tho?
creation science book
Not all Apache servers run on Linux. Not all Linux systems run Apache. Not all Linux/w Apache has mod_ssl.
Je ne parle pas francais.
one might write a wee proggie to sit on UDP port 2002,
Not good enough, I don't think.
I'm seeing remote ports 2140:2144 being used to attempt to connect to port 443.
So, I'm denying port 443 incoming and monitoring all outgoing unaccounted for udp. (Yes, we were infected.)
To-do List: Receive telemarketing call during a tornado warning. Check.
It does very little good to check for a rootkit when all the good GNU stuff in /bin has been trojaned...
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
It transparently replaces the libc functions that are the usual targets of stack smashing attacks, and checks whether the stack frame has been overrun. If the stack has been smashed, the process gets terminated forcefully, and root (or other designated contact) gets an e-mail with all the details.
This has been out for several years now, and I am amazed that no major distribution includes this in a standard server install.
-Steve
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
And, it's not an Apache worm either. It's an OpenSSL worm that exploits security holes in OpenSSL 0.9.6f and earlier.
1 82002.ht m
While the current generation of Slapper targets only OpenSSL on Linux, it will try its attack on any system. And, with a little code tweaking, the next generation of Slapper could hammer on any OS that uses older versions of OpenSSL such as AIX, Solaris, Windows. In short, pretty much any OS that uses OpenSSL is potentially a victim.
Could you have it? If you're a Unix/Linux admin, use chkroot version 0.37 and up to find out. It's available at:
http://www.chkrootkit.org/
In any case, anyone who uses OpenSSL should update with OpenSSL 0.9.6g or higher ASAP. And, while you're at, be certain to relink everything since OpenSSL isn't used just by Apache. ISC, for example, used it in their BIND 9.1. Slapper wouldn't hit BIND, but would you care to bet that someone couldn't modify the code to launch a BIND attack--and aren't we all really, really sick of BIND getting bungled?
For more on Slapper, and a listing of patches for many operating systems see:
Slapper: The FUD and the Danger
http://www.practical-tech.com/network/n09
Finally, most of these patches, which would have stopped Slapper dead, were available in late July/early August. Consider it more proof that security is a full time system administrator job.
Steven