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: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:)
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.
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: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.
Slashdot Mirror
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
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.
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
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.