Re: pop mail recommendations
Hi all. Ted Roby wrote: I suggest popa3d from http://www.openwall.com but I'm not sure if you can use it in standalone mode. How about the combination of popa3d with postfix? Does this team up well? I thought of using qpopper, but I'm willing to think that over again if qpopper has major disadvanteges compared with popa3d. Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pop mail recommendations
Hi all. Ted Roby wrote: I suggest popa3d from http://www.openwall.com but I'm not sure if you can use it in standalone mode. How about the combination of popa3d with postfix? Does this team up well? I thought of using qpopper, but I'm willing to think that over again if qpopper has major disadvanteges compared with popa3d. Bye, Mike
Re:
Andrea Grandi (LevOn Inf.) wrote: subscribe Does that mean one can send mails to the list without being subscribed? Maybe this should be changed then in order to keep spammers away... just a thought. Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re:
Andrea Grandi (LevOn Inf.) wrote: subscribe Does that mean one can send mails to the list without being subscribed? Maybe this should be changed then in order to keep spammers away... just a thought. Bye, Mike
Re: unsubscribe
Hi. Matt Andreko wrote: When does it end with the unsubscribes? When does it end with people complaining about the unsubscribes that has been sent to the list? Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unsubscribe
Hi. Matt Andreko wrote: When does it end with the unsubscribes? When does it end with people complaining about the unsubscribes that has been sent to the list? Bye, Mike
recommendable security lists?
Hi all. One question I think that is not very off topic: what mailinglists, besides bugtraq, would you recommend for someone who wants to keep track of current security problems? My interest is mainly in security issues with wireless lan equipment (such as the two security wholes in current 22 mbit access points that have been reported in the last days on bugtraq). Is there a must read ressource for such things? Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
recommendable security lists?
Hi all. One question I think that is not very off topic: what mailinglists, besides bugtraq, would you recommend for someone who wants to keep track of current security problems? My interest is mainly in security issues with wireless lan equipment (such as the two security wholes in current 22 mbit access points that have been reported in the last days on bugtraq). Is there a must read ressource for such things? Bye, Mike
Re: Having been open relay for a moment
Hi. Anton Zinoviev wrote: 3. In the log-files of exim I have a huge list of e-mail addresses of spammers (such as [EMAIL PROTECTED]). Can I do something useful with them? As they most possibly are forged: no. Drop them in the dustbin and forget about them. It is not worth even to think about doing something with them in my opinion. 4. It seams to me that spammers ought to pay ordb.org for their service. A few years ago when I had similar problem ordb gave me enough time to fix the problem. Why don't they do the same now? As humans we can make mistakes. You should ask *them*, not this list :) Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian (Unstable) problem with SSH and PAM
Hi. Tom Cook wrote: Yea... you are getting nice... LaMer... i am a system administrador and a coder... so...shut up. *sigh* there was a time when trolls studied their field before they started posting. Trolls never know something about the field they are talking about, but they claim they are a pro in that subject. This is (amongst other things) what make trolls being a troll. Therefor: just ignore that one. Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian (Unstable) problem with SSH and PAM
Hi. Tom Cook wrote: Yea... you are getting nice... LaMer... i am a system administrador and a coder... so...shut up. *sigh* there was a time when trolls studied their field before they started posting. Trolls never know something about the field they are talking about, but they claim they are a pro in that subject. This is (amongst other things) what make trolls being a troll. Therefor: just ignore that one. Bye, Mike
Re: Newbie - wants to close ports
Hi. Zeno Davatz wrote: I am just gonna deinstall portsentry - why did I install it in the first place??? In order to get informed in cases when there are (more or less) obvious port scans? :) Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Newbie - wants to close ports
Hi. Zeno Davatz wrote: I am just gonna deinstall portsentry - why did I install it in the first place??? In order to get informed in cases when there are (more or less) obvious port scans? :) Bye, Mike
a.out apache exploit known?
Hi. Is there any known issue to a http request for a file named a.out? I was just wondering, because I had such a request today from a box which was in a .mil domain... he/she downloaded the source of slapper there, watched the index file (which is quite boring so far :)) and then tried to access a file a.out in the root of the webserver. Accident? Or anything that one should know of? Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
a.out apache exploit known?
Hi. Is there any known issue to a http request for a file named a.out? I was just wondering, because I had such a request today from a box which was in a .mil domain... he/she downloaded the source of slapper there, watched the index file (which is quite boring so far :)) and then tried to access a file a.out in the root of the webserver. Accident? Or anything that one should know of? Bye, Mike
Re: ot? apache directory listing mysteries
Hi. Javier Fernández-Sanguino Peña wrote: Did you take a look at the Referer of those access? It might help you to track it down... That's just might be how they get them in the first place. If you buddy downloaded the file and then contacted google.com there are chances that his browser sent the previous URL visited [0]. If it was added in google's database maybe somebody found this after a web search (although the fact that the referer is empty points that this might not be the case). Now there was one access with a referrer pointing to some kind of database containing links to movie downloads (yes, the large file I mentioned was a trailer). Along with the link there was the info that the link came from an irc channel in irc (quakenet). So the mysterie is partly resolved (regarding the fact where all those people came from). What still remains is the question how the first person found the file there... [0] is this a FUD? I believe google uses this as part of his spidering process, I'm also not sure if the browser would provide this information, though. It would provide this information in the referrer, this is how I found the link database. :) Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ot? apache directory listing mysteries
Hi. Ralf Dreibrodt wrote: at least netscape only sends a referer if i used a link. Right, that was one aspect that I forgot. what about the easiest questions: - did you used ssl or do you trust all the providers between your friend and your server? No SSL, but I don't trust any provider in between. In fact most of the accesses came from the same provider that was used by the friend, which is no magic because it is one of the largest providers here in germany (I guess you have heard of T-Online before, right? :)). - do you trust your friend? Yes. - do you trust the knowledge of your friend, e.g. that he has no trojaner on his client? This was the first idea that came to my mind. He is still checking that part. - do you trust all the software your friend installed? google toolbar, internet explorer itself, I'm not sure what software he has installed, but that would be another thing to have a look at. Thanks for the tip. Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ot? apache directory listing mysteries
Hi. Javier Fernández-Sanguino Peña wrote: Did you take a look at the Referer of those access? It might help you to track it down... That's just might be how they get them in the first place. If you buddy downloaded the file and then contacted google.com there are chances that his browser sent the previous URL visited [0]. If it was added in google's database maybe somebody found this after a web search (although the fact that the referer is empty points that this might not be the case). Now there was one access with a referrer pointing to some kind of database containing links to movie downloads (yes, the large file I mentioned was a trailer). Along with the link there was the info that the link came from an irc channel in irc (quakenet). So the mysterie is partly resolved (regarding the fact where all those people came from). What still remains is the question how the first person found the file there... [0] is this a FUD? I believe google uses this as part of his spidering process, I'm also not sure if the browser would provide this information, though. It would provide this information in the referrer, this is how I found the link database. :) Bye, Mike
Re: ot? apache directory listing mysteries
Hi. Ralf Dreibrodt wrote: at least netscape only sends a referer if i used a link. Right, that was one aspect that I forgot. what about the easiest questions: - did you used ssl or do you trust all the providers between your friend and your server? No SSL, but I don't trust any provider in between. In fact most of the accesses came from the same provider that was used by the friend, which is no magic because it is one of the largest providers here in germany (I guess you have heard of T-Online before, right? :)). - do you trust your friend? Yes. - do you trust the knowledge of your friend, e.g. that he has no trojaner on his client? This was the first idea that came to my mind. He is still checking that part. - do you trust all the software your friend installed? google toolbar, internet explorer itself, I'm not sure what software he has installed, but that would be another thing to have a look at. Thanks for the tip. Bye, Mike
Re: Fwd: bugtraq.c httpd apache ssl attack
Hi Florian. Florian Weimer wrote: If you want to do your own tests (without fooling around with the worm), you can use our tool: http://cert.uni-stuttgart.de/advisories/openssl-sslv2-master.php Great tool, thanks. The website of the RUS-CERT mentions in the description of the worm: Bei verwundbaren Systemen hinterläßt der Wurm angeblich keine Logfileeintragungen. (for the non-german readers: it's something like it is said that the worm does not leave any log entries on vulnerable systems). From what I can say this is not correct. I was able to see the following log entries: [Fri Sep 13 00:45:44 2002] [error] [client 210.243.234.135] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): / [Fri Sep 13 00:46:04 2002] [error] mod_ssl: SSL handshake failed (server localhost:443, client 210.243.234.135) (OpenSSL library error follows ) [Fri Sep 13 00:46:04 2002] [error] OpenSSL: error:1406908F:SSL routines:GET_CLIENT_FINISHED:connection id is different [Fri Sep 13 00:50:47 2002] [error] mod_ssl: SSL handshake timed out (client 210.243.234.135, server localhost:443) [... the last line was repeated for another 19 times with slightly different timestamps for the same client ip ...] The system is Red Hat Linux release 7.2 (Enigma), running openssl-0.9.6b-8, mod_ssl-2.8.4-9 and apache-1.3.20-16 (as delivered from RLX as management blade for the rlx 300ex). From what I heard (iirc you told me about that) the worm fired twenty requests towards any probed webserver, so the above logfile signature should at least give a clear hint, or am I wrong in that part? Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
slapper countermeasures
Hi all. How about the following idea: one could use the udp command language that is implemented within the slapper worm to issue some commands for self-deletion of the worm and informing the root user of every system about how to close the hole. As far as I understood there is a network between every infected server that uses communication over udp port 2002. If we could set up a script that is able to inject the appropriate commands to this network, that should shut down the whole network. It could possibly pop up again, but as soon as one of the p2p-nodes is known the complete new network should be accessible (if I understood the scheme correctly). Opinions? Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: slapper countermeasures
Hi. Jean Christophe ANDRÃ0/00 wrote: Same idea here this night! :) Hehe :) I was thinking about the *good* way to do it... May be something like this (root mail, some wait, virus self-kill): /bin/ls -la /tmp | /bin/mail -s You have been infected by the Slapper worm root /bin/sleep 300 # to wait for the propagation, some network are slow /bin/kill -9 $PPID # *MUST* CHECK IF IT WILL REALLY KILL THE *RIGHT* ONE!! The problem will be: every command that slapper executes runs with the uid of the infiltrated ssl webserver. So I guess that in most cases there won't be a chance to issue a kill or killall command. Hmm, is there a chance to cause the program to finish itself in a given condition? Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: slapper countermeasures
Hi. Opinions? you want to use a backdoor to get access a server, on which you are not allowed to get access. [...] I know this can rise problems. We recently had a discussion like this which showed up good arguments for both sides. Asking a lawyer won't be of much help because they can't know the laws of every part of the world. That's the damned thing at the internet. You are not allowed to defend yourself against obvious malicious programs. Yes, I understand the arguments of the server owners. But on the other hand: their server already has been infected. I see a easy chance to close the hole again, which might prevent becoming the server a part of a huge (and illegal) attack against another site. I don't cause more problems than there have been before. I know this is a problematic point of view, and I guess this could lead to another long discussion. So, let's forget about the idea, for the sake of the list and the readers that don't want to get another flood of mails of this kind :)) i already made some bad hedrivings a few years ago with something like this... But one thing I would like to know: what do you mean with hedrivings? :) Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: slapper countermeasures
Hi. Jean Christophe ANDRÃ0/00 wrote: The problem will be: every command that slapper executes runs with the uid of the infiltrated ssl webserver. So the kill will also run as the same uid... *bing* Ok, got the point. I forgot that the uid is allowed to kill processes with it's own uid. So I guess that in most cases there won't be a chance to issue a kill or killall command. I don't mean to kill anything else than the virus itself! Managing the webserver is to far away from what we can do without altering anything valuable on the server! killall .bugtraq would be suitable as well, and it would destroy every other instance of the program that is running currently. Even if detecting the current PPID does not work for whatever reason. Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ot? apache directory listing mysteries
Hi all. Maybe that's a little bit offtopic, but it is somehow related to security, so... :) I'm wondering if there is a way to get an directory listing from apache if there is an index.html available in that directory. The story behind that question: I put a large file on the webserver that was intended for download for a friend. The only one I told about this file was this friend, and he said he didn't tell anyone about it. Nevertheless since yesterday there have been some requests for this file from various places in the world, not only germany, but also sweden and switzerland, even one aol user accessed the file. Imagine the following situation: given is a webserver (apache) that answers to www.mydomain.tld, mydomain.tld and the ip address. All these addresses show the same content when given to the browser: the index.html in the root directory. Inside this index.html there is nothing but a senseless picture and three words, no link, nothing else. The large file is in the root directory as well, so it can be accessed for example with http://www.mydomain.tld/large.file, but there is no reference to this file, no link, nothing. How can someone find out about it? Did I miss something in the configuration? Am I completely stupid now? :) Currently this is nothing bad - the file caused some traffic since last night, but that's harmless. If they access the file now they see only a suitable crafted webpage telling them to look elsewhere for the file. But I'm curious how they found out about it... any ideas? Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ot? apache directory listing mysteries
Hi. Jean Christophe ANDRÃ0/00 wrote: Are you using the VirtualHost capability on this server? Yes. If so, you should be aware of using some _default_:* entry to catch all access not using (or using a bad) hostname for VirtualHost. I just tried to forge a http request targetting at a non-specified domain name that resolved to the correct ip. The result was that the root directory's index.html was shown. So I think this is not the problem. But I'm curious how they found out about it... any ideas? Did you take a look at the Referer of those access? It might help you to track it down... Had this idea, yes. But they all have no referrer when accessing this file. Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ot? apache directory listing mysteries
Hi. Andrew Pimlott wrote: Yes, if your apache isn't up-to-date. http://www.google.com/search?q=apache%20directory%20listing%20bug Is apache 1.3.26-0woody1 vulnerable to that? As far as I could see the answer should be no, right? Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: slapper countermeasures
Hi. Jean Christophe ANDRÃ0/00 wrote: But may be the main point is: is it really possible to have multiple instance of the .bugtraq program?!? If so, all of them would join the network and should receive the mail-sleep-kill command! I've seen two processes running on an infected server. But when thinking about it, this most probably was a forked part. Which would die as soon as the parent is killed. So the version you proposed, kill $ppid, should be safe. Bye, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: bugtraq.c httpd apache ssl attack
Hi Florian. Florian Weimer wrote: If you want to do your own tests (without fooling around with the worm), you can use our tool: http://cert.uni-stuttgart.de/advisories/openssl-sslv2-master.php Great tool, thanks. The website of the RUS-CERT mentions in the description of the worm: Bei verwundbaren Systemen hinterläßt der Wurm angeblich keine Logfileeintragungen. (for the non-german readers: it's something like it is said that the worm does not leave any log entries on vulnerable systems). From what I can say this is not correct. I was able to see the following log entries: [Fri Sep 13 00:45:44 2002] [error] [client 210.243.234.135] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): / [Fri Sep 13 00:46:04 2002] [error] mod_ssl: SSL handshake failed (server localhost:443, client 210.243.234.135) (OpenSSL library error follows ) [Fri Sep 13 00:46:04 2002] [error] OpenSSL: error:1406908F:SSL routines:GET_CLIENT_FINISHED:connection id is different [Fri Sep 13 00:50:47 2002] [error] mod_ssl: SSL handshake timed out (client 210.243.234.135, server localhost:443) [... the last line was repeated for another 19 times with slightly different timestamps for the same client ip ...] The system is Red Hat Linux release 7.2 (Enigma), running openssl-0.9.6b-8, mod_ssl-2.8.4-9 and apache-1.3.20-16 (as delivered from RLX as management blade for the rlx 300ex). From what I heard (iirc you told me about that) the worm fired twenty requests towards any probed webserver, so the above logfile signature should at least give a clear hint, or am I wrong in that part? Bye, Mike
slapper countermeasures
Hi all. How about the following idea: one could use the udp command language that is implemented within the slapper worm to issue some commands for self-deletion of the worm and informing the root user of every system about how to close the hole. As far as I understood there is a network between every infected server that uses communication over udp port 2002. If we could set up a script that is able to inject the appropriate commands to this network, that should shut down the whole network. It could possibly pop up again, but as soon as one of the p2p-nodes is known the complete new network should be accessible (if I understood the scheme correctly). Opinions? Bye, Mike
Re: slapper countermeasures
Hi. Jean Christophe ANDRÃ0/00 wrote: Same idea here this night! :) Hehe :) I was thinking about the *good* way to do it... May be something like this (root mail, some wait, virus self-kill): /bin/ls -la /tmp | /bin/mail -s You have been infected by the Slapper worm root /bin/sleep 300# to wait for the propagation, some network are slow /bin/kill -9 $PPID# *MUST* CHECK IF IT WILL REALLY KILL THE *RIGHT* ONE!! The problem will be: every command that slapper executes runs with the uid of the infiltrated ssl webserver. So I guess that in most cases there won't be a chance to issue a kill or killall command. Hmm, is there a chance to cause the program to finish itself in a given condition? Bye, Mike
Re: slapper countermeasures
Hi. Opinions? you want to use a backdoor to get access a server, on which you are not allowed to get access. [...] I know this can rise problems. We recently had a discussion like this which showed up good arguments for both sides. Asking a lawyer won't be of much help because they can't know the laws of every part of the world. That's the damned thing at the internet. You are not allowed to defend yourself against obvious malicious programs. Yes, I understand the arguments of the server owners. But on the other hand: their server already has been infected. I see a easy chance to close the hole again, which might prevent becoming the server a part of a huge (and illegal) attack against another site. I don't cause more problems than there have been before. I know this is a problematic point of view, and I guess this could lead to another long discussion. So, let's forget about the idea, for the sake of the list and the readers that don't want to get another flood of mails of this kind :)) i already made some bad hedrivings a few years ago with something like this... But one thing I would like to know: what do you mean with hedrivings? :) Bye, Mike
Re: slapper countermeasures
Hi. Ralf Dreibrodt wrote: experiences. i asked a friend, what i could say for erfahrungen in english, he answered hedrivings, so fast, that i didn't doubt. Ah, I see... english for runaways ;) Bye, Mike
Re: slapper countermeasures
Hi. Jean Christophe ANDRÃ0/00 wrote: The problem will be: every command that slapper executes runs with the uid of the infiltrated ssl webserver. So the kill will also run as the same uid... *bing* Ok, got the point. I forgot that the uid is allowed to kill processes with it's own uid. So I guess that in most cases there won't be a chance to issue a kill or killall command. I don't mean to kill anything else than the virus itself! Managing the webserver is to far away from what we can do without altering anything valuable on the server! killall .bugtraq would be suitable as well, and it would destroy every other instance of the program that is running currently. Even if detecting the current PPID does not work for whatever reason. Bye, Mike
ot? apache directory listing mysteries
Hi all. Maybe that's a little bit offtopic, but it is somehow related to security, so... :) I'm wondering if there is a way to get an directory listing from apache if there is an index.html available in that directory. The story behind that question: I put a large file on the webserver that was intended for download for a friend. The only one I told about this file was this friend, and he said he didn't tell anyone about it. Nevertheless since yesterday there have been some requests for this file from various places in the world, not only germany, but also sweden and switzerland, even one aol user accessed the file. Imagine the following situation: given is a webserver (apache) that answers to www.mydomain.tld, mydomain.tld and the ip address. All these addresses show the same content when given to the browser: the index.html in the root directory. Inside this index.html there is nothing but a senseless picture and three words, no link, nothing else. The large file is in the root directory as well, so it can be accessed for example with http://www.mydomain.tld/large.file, but there is no reference to this file, no link, nothing. How can someone find out about it? Did I miss something in the configuration? Am I completely stupid now? :) Currently this is nothing bad - the file caused some traffic since last night, but that's harmless. If they access the file now they see only a suitable crafted webpage telling them to look elsewhere for the file. But I'm curious how they found out about it... any ideas? Bye, Mike
Re: slapper countermeasures
Hi. KevinL wrote: killall .bugtraq would be suitable as well, and it would destroy every other instance of the program that is running currently. Even if detecting the current PPID does not work for whatever reason. *chuckle* Solaris is vulnerable to this bug? Solaris killall kills _everything_ - not just the named process. Erm... ok, good point. Never used Solaris so far :) Bye, Mike
Re: ot? apache directory listing mysteries
Hi. Jean Christophe ANDRÃ0/00 wrote: Are you using the VirtualHost capability on this server? Yes. If so, you should be aware of using some _default_:* entry to catch all access not using (or using a bad) hostname for VirtualHost. I just tried to forge a http request targetting at a non-specified domain name that resolved to the correct ip. The result was that the root directory's index.html was shown. So I think this is not the problem. But I'm curious how they found out about it... any ideas? Did you take a look at the Referer of those access? It might help you to track it down... Had this idea, yes. But they all have no referrer when accessing this file. Bye, Mike
Re: ot? apache directory listing mysteries
Hi. Andrew Pimlott wrote: Yes, if your apache isn't up-to-date. http://www.google.com/search?q=apache%20directory%20listing%20bug Is apache 1.3.26-0woody1 vulnerable to that? As far as I could see the answer should be no, right? Bye, Mike
Re: slapper countermeasures
Hi. Jean Christophe ANDRÃ0/00 wrote: But may be the main point is: is it really possible to have multiple instance of the .bugtraq program?!? If so, all of them would join the network and should receive the mail-sleep-kill command! I've seen two processes running on an infected server. But when thinking about it, this most probably was a forked part. Which would die as soon as the parent is killed. So the version you proposed, kill $ppid, should be safe. Bye, Mike
Re: Fwd: bugtraq.c httpd apache ssl attack
Hi all. I still have to see the worm, so I can't say for sure that you are safe, but it's a good time to update if you haven't done so. ;-) I have the source of the worm at hands now, as well as a working binary that has been placed on a server. Still interested in getting hands on that thingy? :) Bye, Mike
Re: Fwd: bugtraq.c httpd apache ssl attack
Hi all. As addition to my previous mail: the source is now available for download at the following URL: http://217.24.0.78/bugtraq.c.txt One thing that makes me wonder: after I wrote my first few lines about the attack on the rlx blade server that we experienced, someone gave a correct hint to the worm (describing it with some of its actions), and also mentioned a URL for the source code of the worm. When looking at that source (http://dammit.lt/apache-worm/apache-worm.c) it is quite obviously that our source is totally different. Is there a second variant of the worm, or is this another worm using the same exploit? Bye, Mike
Re: Fwd: bugtraq.c httpd apache ssl attack
Hi Noah. Noah L. Meyerhans wrote: There are two worms. One is old, one is new. The one at http://217.24.0.78/bugtraq.c.txt is the new one. It communicates via UDP port 2002, though I'm not actually sure what data gets sent on that port. Thanks for the information. I most probably have a tcpdump log of those packets (hopefully). I'm still trying to get it here, but I'm not sure if the log still exists. It has been done yesterday during the attack on an intermediate linux router box. Bye, Mike
Re: Fwd: bugtraq.c httpd apache ssl attack
Hi. Guille -bisho- wrote: [bugtraq list quote] After the program /tmp/.bugtraq starts running, it becomes a member of a virtual network. Network members comunicate using UDP port 2002. The program can, when instructed (using udp port 2002): [/bugtraq list quote] In 3 dias, about 1500 diferent IP address tried to contact my machine at UDP port 2002. Fortunally i have iptables configured. We experienced the same here. The peak was at about 4 MBit/s traffic which was the limit of the line the server is connected to. Now, after the bugtraq-process is not running anymore for longer than 24 hours still packets for port 2002 are fired against the server's ip address. I guess that the client implements some kind of cache for addresses of infected servers so that they can be contacted for giving them new orders. Maybe our ip is still in the cache. Any idea about the outgoing connections to port 80? We noticed that the bugtraq-process systematically tries to connect to port 80 in an ip block, and it keeps trying and trying, incrementing the ip addresses by one per step (1.2.3.4, 1.2.3.5, 1.2.3.6, and so on). We could not find out what is done with this connection, nor what the purpose of this scan is. Bye, Mike
Re: Fwd: bugtraq.c httpd apache ssl attack
Hi. Noah L. Meyerhans wrote: In 3 dias, about 1500 diferent IP address tried to contact my machine at UDP port 2002. Fortunally i have iptables configured. That's interesting. I haven't seen any traffic to udp port 2002 in the past couple of days at all. The worm uses the following code to pick targets at random: [...] I find it hard to believe that 1500 different hosts randomly chose your machine, while 0 randomly chose any of mine. As described in another mail: I can confirm that there was (and still is) a *huge* packet storm against port 2002 on the infected machine that I found. Even after cleaning the machine up (removing .bugtraq and closing the hole) they are bouncing in (or try to, they get smashed at the firewall). Bye, Mike
Re: bugtraq.c httpd apache ssl attack
Hi. Phillip Hofmeister wrote: Is this log evidence of our worm? Not exactly. Here is the log of our machine that has been attacked: === cut === [Fri Sep 13 00:45:44 2002] [error] [client 210.243.234.135] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): / [Fri Sep 13 00:46:04 2002] [error] mod_ssl: SSL handshake failed (server localhost:443, client 210.243.234.135) (OpenSSL library error follows ) [Fri Sep 13 00:46:04 2002] [error] OpenSSL: error:1406908F:SSL routines:GET_CLIENT_FINISHED:connection id is different [Fri Sep 13 00:50:47 2002] [error] mod_ssl: SSL handshake timed out (client 210.243.234.135, server localhost:443) (the last message was repeated for 20 times, telling about the timeout of every of the 20 connections to the https-port the worm opens after finding a running webserver on port 80) === cut === The given IP address (210. ...) was the address that the bugtraq-program was given as some kind of uplink server address. Bye, Mike
rlx blade server attacked
Hi all. The rlx blade server rack (better: the management blade) where my own server is located in has been attacked. I phoned to my ISP some minutes ago, and he described that there was a huge packet storm fired from the internet towards the management blade. He described that there were (and still are) lots of udp packets for port 2002, and on the management blade there are a lot of processes with the name bugtraq running. I will drive down there now to have a closer look at this stuff. Has anyone an initial idea what this could be? Maybe that helps for getting the server back on line faster. As soon as I have more information about it I will post them here. Bye, Mike
Re: rlx blade server attacked
Hi Jason. Jason Sopko wrote: The Apache worm you're infected with was posted on bugtraq earlier today. It exploits mod_ssl and can be identified by doing a ps -ax | grep bugtraq (it runs as the name .bugtraq). The source for it is here: http://dammit.lt/apache-worm/apache-worm.c Thanks a lot for the fast reply. You are right, I can approve that this is the worm that attacked the management blade. It started it's attack somewhere around noon (local time) today. The management blade is vulnerable to this attack as it is based on RedHat 7.3 (maybe it would have been better if RLX had stick to Debian as they used before). Thanks a lot for the help. Bye, Mike
suspicious apache log entries
Hi all. While digging through the error.log of my apache I found two lines that seem to hint toward a new (?) worm. I saw the first one some days ago, too: [Sat Aug 31 21:03:49 2002] [error] [client 64.152.12.2] request failed: erroneous characters after protocol string: CONNECT mailb.microsoft.com:25 / HTTP/1.0 Looks like there is someone trying to abuse a proxy to connect to a SMTP server? The second is a new one (which means I never saw it before). It appears several times in the log, below I quoted the first appearance: [Sat Sep 7 05:33:20 2002] [error] [client 202.224.228.106] Client sent malformed Host header Any idea what type of attack these lines give a hint about? I think Apache is safe here, this most probably would be an attack against IIS or something like that. But I would like to learn a little more about those ones... Bye, Mike
Re: suspicious apache log entries
Hi Anne. Anne Carasik wrote: Sounds like Code Red. We get a lot of these too, and the Microsoft attacks don't do much to an Apache server :) Ok, thanks for the info. I guess I didn't saw this one by now because Code Red seems to die more and more, right? :) Bye, Mike
Re: suspicious apache log entries
Hi Andreas. Andreas Syksa wrote: I've seen tons of ../script/ and ../cmd.exe's as I've got several machines with fixed ips. I also received quite a lot of those requests, although our server is not official by now, has no domain name (besides an work-around solution using dyndns during the time we still work on the server setup). I already told about that one or two weeks ago here on the list. Has anyone seen some Anti-Nimda/Code Red beside http://www.eye-net.com.au/csmall/myscripts/nimda.html ? I wrote a small php-script for tarpitting Nimda and Co., but as I told here this was not very successful. It seems meanwhile there are lots of variants of Nimda out there who don't care about endless connections - they quit a connection after a timeout of less than 15 seconds. Phillip Hofmeister stated that one could use the Nimda backdoor on the server that connects our server to setup a warning message on the attacking computer's desktop. I think this is a great idea, but I have not been able to track down what would be necessary to write code for doing so. Anyone on this list interested in teaming up on writing such an script? Bye, Mike
Re: suspicious apache log entries
Hi. Vineet Kumar wrote: Phillip Hofmeister stated that one could use the Nimda backdoor on the server that connects our server to setup a warning message on the attacking computer's desktop. If you do, be prepared to go to jail... For what reason? For telling stupid webserver administrators about a security problem they have? Well, while thinking about it, you may be right. There have been several incidents in the US where someone pointed out security problems and got sued because of that a few days/weeks later. Bye, Mike
Re: AW: suspicious apache log entries
Hi Marcel. Marcel Weber wrote: Why not introduce an official Internet Security Team that officially has the right to do such things. It would be for the good of the net! They could be a part of the ICANN or UNO or whoever. I don't think this would be successful. It's a great idea, no doubt about it. But the problems will begin as soon as you had to get legal approve by every possible country that is connected to the Internet. There are still countries in the world where it is not a crime to get inside a computer and steal data. I guess chances are low that such countries would even care about giving legal approvements to such a security team. Just my 0.02$ (maybe, most hopefully I'll be wrong with that - it would be a great step forward to have a team like this in my opinion) Bye, Mike
Re: suspicious apache log entries
Hi. Doug Winter wrote: It claimed that the HTTP libraries used by Nimda and Code Red were generic, and could be fooled by sending a redirect response like: Location: http://127.0.0.1/ Nice idea. Would it be enough to redirect them to the localhost-ip, or should the URI of the original request be appended to the redirection? Bye, Mike
experience with tarpitting nimda co
Hi all. I just wanted to let you know about some experiences with my nimda-tarpit script that I wrote. I've been using it for a little more than a week now. The script is written in php, and I'm using rewrite rules to direct nimda attacks to this script. It first displays two messages, waits some seconds in between, then it starts sending a * every 30 seconds in order to hold up the connection. The script stops running only when the client breaks up the connection. In order to prevent a DOS attack on my normal webservice I use a counter for every instance of the script that is running. If this counter exceeds a given threshold, the script just displays something like piss off and quits. After using this script for a while I can say the following: most of the attacks come from worms, not from script kiddies that run worm-like tools manually. Every attack (and there have been some) was aware of tarpitting connections, they disconnected within 15 seconds, so tarpitting them does not work at all. A negative side effect of the tarpit script is that the number of connections rised visibly during each attack. I guess this is because of the 200 they receive instead of the 404. I will shut down the tarpit script this weekend and remove the rewrite rules. It seems as if this experiment failed. Another idea that came to my mind was a iptables module that is able to redirect http worm attacks to the drop chain. They would not get through to the webserver, therefor would not get a webserver status response, and the amount of traffic that is caused by them would be minimal. Is there anything that speaks against that idea (apart from the fact that I have no experiences in writing such a module)? Bye, Mike
Re: Mail relay attempts
Hi Peter. Peter Cordes wrote: [tarpit for attacking worms] I remember hearing about people doing exactly that. Maybe it was mentioned on /. or the local LUG mailing list (http://nslug.ns.ca/). Sounds interesting. The LUG website is unreachable at the moment, but I will dig the slashdot archives about that. Thanks for the hint. Bye, Mike
Re: Mail relay attempts
Hi Dale. Dale Amon wrote: The only thing you can do is to make damn certain your box does not become part of the problem. I'll add to that: make sure you actually check your logs. I use syslog-ng to bring all essential realtime logging to a hardened server; I'll add another one to that: I started using syslogd-sql, which is a modified version of the syslog 1.4.1 that also allows logging to a MySQL database. I hope it is a step in the right direction to use advances SQL queries in order to support analyzation of logfiles. Any opinions on that from the more experiences ones on this list? :) Bye, Mike
Re: Mail relay attempts
Hi. Jones, Steven wrote: Ive found port sentry really good for detecting port scans and then routeing the return packets to no where. As an addition to that idea: would it be possible to cause similar effects to HTTP-server worms with a modified tarpit? Maybe a modified version of the kernel httpd: whenever a worm attack drops in the response will be a normal website containing a bogus content (no 404), coming over the line character by character with a huge delay. Comments? Bye, Mike
Re: Mail relay attempts
Hi Karl. Karl Breitner wrote: What can I say Daniel, except welcome to the harsh reality of a postmaster. Hmm, as I'm to become a postmaster in a few days, too, I would like to learn a bit more about that. Most probably this list is not intended for chat like this, so I would be happy to get some hints on where to get more information about that topic (mailing lists, FAQs, and so on). Welcome to the world of SPAMfighting I guess this means a lot of fun (well, fun at least if you are pervert ;). Our new server has an official IP since last saturday, and no domain name pointing to it yet besides a dyndns-account I abused for testing purpose. Within these three days of operation I had several persons trying to get access to our (non-public) FTP service as well as some probes for the usual IIS-holes that Nimda Co. like to abuse. How will that be if we will be publically online and known through our regular domains? brrr :) Bye, Mike
Re: unsubscribe
I must be really hard for some people to read the footer lines of every mail they receive over this mailinglist... since I subscribed here to this list (4 days or so) every day at least one of those unsubscribe mails have been arriving. Or am I the only subscriber who receives messages with this footer text: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. One question after another... :) Bye, Mike
Re: unsubscribe
Hi Simon. Simon Fuhrmann wrote: [...] Or am I the only subscriber who receives messages with this footer text: [...] I can calm you, I get this footer too ;-) Oh, great *phew* :) Meanwhile the first poster injected a really good idea into my mind... why not filter away those messages? As the list still will send them, I have to do that on my pc. Using procmail this would be easy, but I also read my mails on Win2k with Mozilla. I did not think about the fact that Mozilla features some very nice mail filter possibilities... now those messages won't bug me anymore :)) Bye, Mike
