Re: Apache+php Proof of Concept Exploit

older
suse 7.3 security patches - where...

phil

6 Mar 2002 6 Mar '02

03:17

Greetings, I was testing out the source code on http://online.securityfocus.com/archive/82/259542 on my box and I have the following installed (to the best of my knowledge) using rpm -q <target name> mod_php4-core-4.0.6-147 phplib-7.2c-45 phpdoc-4.0.3-38 mod_php4-4.0.6-147 apache-1.3.19-48 And according to " <? phpinfo() ?> " PHP Version 4.0.6 Apache/1.3.19 IP Location used for test: http://192.168.0.2/time.php Hostname: lead.box.yankee (although in THIS test in THIS msg I used IP num) Port: 80 ---- time.php 's source code is ---- <center> <H1> <? echo "Connect!" ?><br> </H1> <? print(date("l dS of F Y h:i:s A")); ?><br><br> <? phpinfo() ?><br> </Center> <HR> ---- time.php 's source code is ---- after compiling apache_php.c and running these commands phil@lead > ./a.out 192.168.0.2 80 /time.php phil@lead > ./a.out 192.168.0.2 80 ./time.php phil@lead > ./a.out 192.168.0.2 80 "/time.php" phil@lead > ./a.out 192.168.0.2 80 "./time.php" phil@lead > ./a.out 192.168.0.2 80 "/time.php/" phil@lead > ./a.out 192.168.0.2 80 "./time.php/" phil@lead > ./a.out 192.168.0.2 80 ./time.php/ I get /var/log/httpd/error_log [Tue Mar 5 17:13:29 2002] [error] [client 192.168.0.2] Invalid URI in request POST ./time.php HTTP/1.0 [Tue Mar 5 17:14:08 2002] [error] [client 192.168.0.2] Invalid URI in request POST ./time.php HTTP/1.0 [Tue Mar 5 17:14:20 2002] [error] [client 192.168.0.2] Invalid URI in request POST ./time.php/ HTTP/1.0 [Tue Mar 5 17:14:25 2002] [error] [client 192.168.0.2] Invalid URI in request POST ./time.php/ HTTP/1.0 I'd also note that with 7 command line attempts above only 4 log entries were written. Three log entries are "missing" ;o) /var/log/httpd/access_log (note: they are now showing) 192.168.0.2 - - [05/Mar/2002:17:13:08 -0800] "POST /time.php HTTP/1.0" 200 7865 192.168.0.2 - - [05/Mar/2002:17:13:29 -0800] "POST ./time.php HTTP/1.0" 400 338 192.168.0.2 - - [05/Mar/2002:17:14:02 -0800] "POST /time.php HTTP/1.0" 200 7865 192.168.0.2 - - [05/Mar/2002:17:14:08 -0800] "POST ./time.php HTTP/1.0" 400 338 192.168.0.2 - - [05/Mar/2002:17:14:16 -0800] "POST /time.php/ HTTP/1.0" 200 7865 192.168.0.2 - - [05/Mar/2002:17:14:20 -0800] "POST ./time.php/ HTTP/1.0" 400 339 192.168.0.2 - - [05/Mar/2002:17:14:25 -0800] "POST ./time.php/ HTTP/1.0" 400 339 I know apache is still up cause I have several exploitable versions of php software (php-nuke, phorum) that I had been testing for exploits. (which I did find.) The question is SuSE immune to this "Proof of Concept Exploit" I have SuSE 7.2 only to test on, the guy that wrote this has, RedHat 7.0 with apache 1.3.22 I don't have any other boxes I can test on except win boxes (which doesn't matter for this particular question) -- Linux 2.4.7-4GB #1 Thu Oct 25 17:53:12 GMT 2001 i586

Show replies by date

Boris Lorenz

6 Mar 6 Mar

10:19

New subject: [suse-security] Re: Apache+php Proof of Concept Exploit

Yuppa, phil wrote:

...

Greetings,

I was testing out the source code on http://online.securityfocus.com/archive/82/259542

this version of the exploit contains an error, the author has posted a corrected version in his next post: http://online.securityfocus.com/cgi-bin/archive.pl?id=82&start=2002-03-03&end=2002-03-09&mid=259574&threads=0 This is an exploit for the vulns in php4.0.6 et al, published a few days ago. Looks nice... :) I will also give it a try and re-post. Boris Lorenz ---

phil

10:45

New subject: [suse-security] Re: Apache+php Proof of Concept Exploit

Greetings, Yes, I was aware that he reposted it. I have also tried the new version. It still isn't crashing on my box though. Thanks a lot for your input. On Wednesday 06 March 2002 02:19, you wrote:

...

Yuppa,

phil wrote:

...
Greetings,

I was testing out the source code on http://online.securityfocus.com/archive/82/259542

this version of the exploit contains an error, the author has posted a corrected version in his next post:

http://online.securityfocus.com/cgi-bin/archive.pl?id=82&start=2002-03-03&e nd=2002-03-09&mid=259574&threads=0

This is an exploit for the vulns in php4.0.6 et al, published a few days ago. Looks nice... :)

I will also give it a try and re-post.

Boris Lorenz ---

-- Linux 2.4.7-4GB #1 Thu Oct 25 17:53:12 GMT 2001 i586

phil

11:14

New subject: [suse-security] Re: Apache+php Proof of Concept Exploit

Greetings, I just had someone test this in IRC and it crashed his apache. However, I have file_uploads = Off in my /etc/php.ini so, I think this may be why. thanks for the help . On Wednesday 06 March 2002 02:19, you wrote:

...

Yuppa,

phil wrote:

...
Greetings,

I was testing out the source code on http://online.securityfocus.com/archive/82/259542

this version of the exploit contains an error, the author has posted a corrected version in his next post:

http://online.securityfocus.com/cgi-bin/archive.pl?id=82&start=2002-03-03&e nd=2002-03-09&mid=259574&threads=0

This is an exploit for the vulns in php4.0.6 et al, published a few days ago. Looks nice... :)

I will also give it a try and re-post.

Boris Lorenz ---

-- Linux 2.4.7-4GB #1 Thu Oct 25 17:53:12 GMT 2001 i586

phil

11:45

New subject: [suse-security] Re: Apache+php Proof of Concept Exploit

A couple more folks tested and we have come to the conclusion that if you had applied the patches on http://www.suse.com/en/support/download/updates/72_i386.html you would get some error like: "[error] [client xxx.xxx.xxx.xxx] Invalid URI in request POST index.php HTTP/1.0" but if you didn't patch it, you would get the Seg Fault error. I turned file_uploads = Off to On and rcapache restart and tested and it didn't make any difference. So I was wrong on that. Hope this explains. I plan to leave file_uploads = Off, and I'd suggest other folks make sure it's patched up. thanks. On Wednesday 06 March 2002 03:14, you wrote:

...

Greetings,

I just had someone test this in IRC and it crashed his apache. However, I have file_uploads = Off in my /etc/php.ini so, I think this may be why.

thanks for the help .

On Wednesday 06 March 2002 02:19, you wrote:

...
Yuppa,

phil wrote:

...
Greetings,

I was testing out the source code on http://online.securityfocus.com/archive/82/259542

this version of the exploit contains an error, the author has posted a corrected version in his next post:

http://online.securityfocus.com/cgi-bin/archive.pl?id=82&start=2002-03-03 &e nd=2002-03-09&mid=259574&threads=0

This is an exploit for the vulns in php4.0.6 et al, published a few days ago. Looks nice... :)

I will also give it a try and re-post.

Boris Lorenz ---

-- Linux 2.4.7-4GB #1 Thu Oct 25 17:53:12 GMT 2001 i586

Mirzoni

11:39

New subject: Apache version

Hello , i would like to ask maybe old-new question and this is : Is posibile to turn of showing version of apache and modules instaled when i telnet on web server to port 80 and type get HTTP/1.1 somefile.htm and then i get this what i dont want to be shown , for example telnet somehost 80 Trying somehost... Connected to somehost. Escape character is '^]'. get HTTP/1.1 somefile.htm HTTP/1.1 400 Bad Request Date: day, date ti:me GMT Server: Apache/1.3.23 (Unix) PHP/4.1.2 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>400 Bad Request</TITLE> </HEAD><BODY> <H1>Bad Request</H1> Your browser sent a request that this server could not understand.<P> Invalid URI in request get HTTP/1.1 somefile.htm<P> <EN> <ADDRESS>Apache/1.3.23 Server at www.mywebserver.domain Port 80</ADDRESS> </BODY></HTML> Connection closed by foreign host. Sorry but i did not can find any useful request in mail list archives Thanks in advance

Yarrel

11:44

New subject: [suse-security] Apache version

...

-----Original Message----- From: Mirzoni [mailto:mirzoni@gmx.net] Sent: Wednesday, March 06, 2002 12:39 PM To: suse-security@suse.com Subject: [suse-security] Apache version

Hello , i would like to ask maybe old-new question and this is : Is posibile to turn of showing version of apache and modules [snipped headers]

Why ? Security through obscurity doesn´t work. Most of the the activity in your logs, including hack/exploit attempt are from scriptkiddies who couldn't care less what version your running. The just throw their cookbooks at your IP/firewall regardless. I believe there´s other ways of getting Apache to reveal it´s version too, so this wont work. Hope this helps /Yarrel

...

Sorry but i did not can find any useful request in mail list archives

Thanks in advance

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here

Michael Appeldorn

12:07

New subject: [suse-security] Apache version

...

Security through obscurity doesn´t work.

It just works IMHO - maybe only 4 specific purposes, but it works.

...

Most of the the activity in your logs, including hack/exploit attempt are from scriptkiddies who couldn't care less what version your running. The just throw their cookbooks at your IP/firewall regardless.

e.g. you give false/faked or none replys to such telnet request, will give all, not only the kiddies, a false first impression and maybe they fail or will never find what they're searching for, cauze it's there but with a mask.

...

I believe there´s other ways of getting Apache to reveal it´s version too, so this wont work.

Then modify the f***ing version string before compile, often in version.c and give your attacker a nice wrong intention of his counterpart, e.g IIS profile. Just my point of view Michael Appeldorn

Yarrel

12:25

New subject: [suse-security] Apache version

...

-----Original Message----- From: Michael Appeldorn [mailto:appeldorn@codixx.de] Sent: Wednesday, March 06, 2002 1:07 PM To: suse-security@suse.com; Yarrel Subject: Re: RE: [suse-security] Apache version

...
Security through obscurity doesn´t work.

It just works IMHO - maybe only 4 specific purposes, but it works.

This is false sense of security. It doesn´t work for security purposes.

...

...
Most of the the activity in your logs, including hack/exploit attempt are from scriptkiddies who couldn't care less what version your running. The just throw their cookbooks at your IP/firewall regardless.

e.g. you give false/faked or none replys to such telnet request, will give all, not only the kiddies, a false first impression and maybe they fail or will never find what they're searching for, cauze it's there but with a mask.

Like I said. Scriptkiddies throw everything and the kitchemsink at your box. They don´t give a damn what version your running. Check your software. Is it vulnerable ? upgrade or patch. Set appropriate permissions, enforce active/strong security ploicy for users etc. This works! Masquarading a vulnerable or potentially vulnerable machine with forged headers is IMHO ridiculous, and a waste of time. Patch and configure properly instead. /Yarrel

Michael Appeldorn

12:48

New subject: [suse-security] Apache version

...

Check your software. Is it vulnerable ? upgrade or patch. Set appropriate permissions, enforce active/strong security ploicy for users etc. This works! Masquarading a vulnerable or potentially vulnerable machine with forged headers is IMHO ridiculous, and a waste of time. Patch and configure properly instead.

That's all true. And to do at first.

...

Most of the the activity in your logs, including hack/exploit attempt are from scriptkiddies who couldn't care less what version your running. The just throw their cookbooks at your IP/firewall regardless.

So what about their scripts. Dont they ask the server 4 version to check certain vuln and will they fail ever if the get the wrong one. But anyway, just a point of view and it'snt necessary to convince me. Yours Michael Appeldorn

Yarrel

12:54

New subject: [suse-security] Apache version

...

-----Original Message----- From: Michael Appeldorn [mailto:appeldorn@codixx.de] Sent: Wednesday, March 06, 2002 1:49 PM To: suse-security@suse.com; Yarrel Subject: Re: RE: RE: [suse-security] Apache version

[snipped]

...

...
Most of the the activity in your logs, including hack/exploit attempt are from scriptkiddies who couldn't care less what version your running. The just throw their cookbooks at your IP/firewall regardless.

So what about their scripts. Dont they ask the server 4 version to check certain vuln and will they fail ever if the get the wrong one.

If the server´s vulnerable, the script should theoretically work, forged header or not. If one were to fire script upon script at a server, one is bound to succeed in the end IMHO.

...

But anyway, just a point of view and it'snt necessary to convince me.

I know :o)

...

Yours Michael Appeldorn

Yarrel

Ralf Ronneburger

12:30

New subject: [suse-security] Apache version

Hi, so it's security through obscurity again... Lets assume there would be an exploit for apache. What would skript kiddies do, telnet apache first or just run the exploit against the all servers and see what happens? I'd guess for the second option (time-saving) and that's why I'd advice you to save your time compiling apache to hide the version and os, this information can almost always be gained in another way. Rather use that time to find out, how you can make your apache more secure (by en/disabiling modules, configuration etc.). Just my 2 cent, Ralf Ronneburger

...

...
Security through obscurity doesn´t work.

It just works IMHO - maybe only 4 specific purposes, but it works.

...
Most of the the activity in your logs, including hack/exploit attempt are

from scriptkiddies who couldn't care less what version your running.

...
The just throw their cookbooks at your IP/firewall regardless.

e.g. you give false/faked or none replys to such telnet request, will give all, not only the kiddies, a false first impression and maybe they fail or will never find what they're searching for, cauze it's there but with a mask.

...
I believe there´s other ways of getting Apache to reveal it´s version too, so this wont work.

Then modify the f***ing version string before compile, often in version.c and give your attacker a nice wrong intention of his counterpart, e.g IIS profile.

Just my point of view

Michael Appeldorn

Boris Lorenz

13:06

New subject: [suse-security] Apache version

Hi, Ralf Ronneburger wrote:

...

Hi,

so it's security through obscurity again...

Lets assume there would be an exploit for apache. What would skript kiddies do, telnet apache first or just run the exploit against the all servers and see what happens? I'd guess for the second option (time-saving) and that's why I'd advice you to save your time compiling apache to hide the version and os, this information can almost always be gained in another way. Rather use that time to find out, how you can make your apache more secure (by en/disabiling modules, configuration etc.).

some pretty valid points there. Security through obscurity is never a good solution, and I agree with you that most script kiddies won't spend their time with version-/banner probes; if a system is inherently insecure, banner phogging would be futile in the first place. However, like I already tried to point out in my reply to Yarrel, there are more types of aggressors against IT infrastructure, and some (most?) of them *do* conduct extensive banner probes, mostly supported by some nifty shell scripts. According to my experiences, these types of attackers don't want to loose time as well and primarily go for a worthy prey (i. e. against a system with a more obvious information leakage). Lastly, I don't think that changing two lines in an Apache include before compiling the package is a very time-consuming task ;)

...

Just my 2 cent, dito.

...

Ralf Ronneburger

Boris Lorenz ---

Ralf Ronneburger

13:20

New subject: [suse-security] Apache version

Hi, so let's sumarize: Secure your box first as good as you can, then hide your version using httpd.conf and then take care of all the other information that your apache spreads (headers, error-pages). But be asured that all the camouflage will almost certainly not hide you 100%, because there always more evidence (tcp-fingerprints (I've not yet seen an unix clone running IIS), php vs. asp pages (I know, there ist php for IIS, too, but....), etc.). Best regards, Ralf Ronneburger Boris Lorenz wrote:

...

Hi,

Ralf Ronneburger wrote:

...
Hi,

so it's security through obscurity again...

Lets assume there would be an exploit for apache. What would skript kiddies do, telnet apache first or just run the exploit against the all servers and see what happens? I'd guess for the second option (time-saving) and that's why I'd advice you to save your time compiling apache to hide the version and os, this information can almost always be gained in another way. Rather use that time to find out, how you can make your apache more secure (by en/disabiling modules, configuration etc.).

some pretty valid points there. Security through obscurity is never a good solution, and I agree with you that most script kiddies won't spend their time with version-/banner probes; if a system is inherently insecure, banner phogging would be futile in the first place.

However, like I already tried to point out in my reply to Yarrel, there are more types of aggressors against IT infrastructure, and some (most?) of them *do* conduct extensive banner probes, mostly supported by some nifty shell scripts. According to my experiences, these types of attackers don't want to loose time as well and primarily go for a worthy prey (i. e. against a system with a more obvious information leakage).

Lastly, I don't think that changing two lines in an Apache include before compiling the package is a very time-consuming task ;)

...
Just my 2 cent,

dito.

...
Ralf Ronneburger

Boris Lorenz ---

Michael Appeldorn

13:34

New subject: [suse-security] Apache version

...

Hi,

so let's sumarize: Secure your box first as good as you can, then hide your version using httpd.conf and then take care of all the other information that your apache spreads (headers, error-pages).

...

But be asured that all the camouflage will almost certainly not hide you 100%, because there always more evidence (tcp-fingerprints (I've not yet seen an unix clone running IIS), php vs. asp pages (I know, there ist php for IIS, too, but....), etc.).

You're right. Only as a comment. Hide tcp-fingerprints with www.grsecurity.net. (But is'nt it security by o......... as well [wont start new flame] - so why they do? ............Me's looking backward - nothing said) Michael Appeldorn

Boris Lorenz

14:34

New subject: [suse-security] Apache version

Yay, Ralf Ronneburger wrote:

...

Hi,

so let's sumarize: Secure your box first as good as you can, then hide your version using httpd.conf and then take care of all the other information that your apache spreads (headers, error-pages).

First of all, getting rid of banners for me is a normal part of my agenda of essential security precautions while conceiving and installing 'net-connected servers/workstations. Next, if you change Apache's product informations in httpd.h and use the ServerTokens directive, *no* document whatsoever displays *any* version/demon infos anymore; we're talking about an include here, not mods of the source code itself (which indeed would be zany to say the least). Btw., there are many security scanners (SATAN, SAINT, and specially NESSUS) which negatively report existing banners of demons, for good reasons.

...

But be asured that all the camouflage will almost certainly not hide you 100%, because there always more evidence (tcp-fingerprints (I've not yet seen an unix clone running IIS), php vs. asp pages (I know, there ist php for IIS, too, but....), etc.).

We all know that there are no 100% solutions. Let's put it this way, I do what I can (and what can be done *economically*) to make it harder for *any* type of attacker to alter/disrupt/DoS/crack my systems. If only one of my proposed "foes" gets distracted by the nonexistence of a banner, I rate this as a success. If this can be accomplished by changing a couple of lines in an include (takes 1 minute) and altering a config file (takes another minute), I'll do it. Plain and simple. Don't get me wrong, I don't recommend the deletion of banners as a stand-alone security precaution, IMO it should/could be part of a wide-scope security assessment of a server/client.

...

Best regards,

Ralf Ronneburger

Boris Lorenz ---

Boris Lorenz

12:39

New subject: [suse-security] Apache version

Yarrel wrote:

...

...
-----Original Message----- From: Mirzoni [mailto:mirzoni@gmx.net] Sent: Wednesday, March 06, 2002 12:39 PM To: suse-security@suse.com Subject: [suse-security] Apache version

Hello , i would like to ask maybe old-new question and this is : Is posibile to turn of showing version of apache and modules [snipped headers]

Why ?

Security through obscurity doesn´t work.

Agreed. But it's a common and recommended security practise to hide banners of demons. This is not security through obscurity, but essential.

...

Most of the the activity in your logs, including hack/exploit attempt are from scriptkiddies who couldn't care less what version your running.

NACK. It's highly important, even for some script kiddies, which versions of demons you're running. Most of the cracker lore deals with version informations and whatnot, because most exploits are designed for distinct versions of the programs they're targeted at. There are more types of attackers "out there" than script kiddies.

...

The just throw their cookbooks at your IP/firewall regardless.

Yes, they do. And of course it would be silly to hide behind a non-disclosed banner of a vulnerable demon version, but it's perfectly okay to hide versions and demon names of properly installed and sec-hardened servers.

...

I believe there´s other ways of getting Apache to reveal it´s version too, so this wont work.

That's true, but this isn't as easy as it seems, and commonly is way beyond the scope of an average script abuser. Boris Lorenz ---

Yarrel

12:32

New subject: [suse-security] Apache version

...

-----Original Message----- From: bolo@lupa.de [mailto:bolo@lupa.de] Sent: Wednesday, March 06, 2002 1:40 PM To: suse-security@suse.com Subject: Re: [suse-security] Apache version

[snipped]

...

Agreed. But it's a common and recommended security practise to hide banners of demons. This is not security through obscurity, but essential.

...
Most of the the activity in your logs, including hack/exploit attempt are from scriptkiddies who couldn't care less what version your running.

NACK. It's highly important, even for some script kiddies, which versions of demons you're running. Most of the cracker lore deals with version informations and whatnot, because most exploits are designed for distinct versions of the programs they're targeted at. There are more types of attackers "out there" than script kiddies.

I agree! Hence my expression: "everything AND the kitchensink" :o) I´m of course aware of the other types as well. I was merely pointing out that tha majority are scriptkiddies who knows nothing about about comp. security.

...

...
The just throw their cookbooks at your IP/firewall regardless.

Yes, they do. And of course it would be silly to hide behind a non-disclosed banner of a vulnerable demon version, but it's perfectly okay to hide versions and demon names of properly installed and sec-hardened servers.

Sure it is. But necessary ? I don´t believe so. Exploits will work regardsless, if the servers vulnerable.

...

...
I believe there´s other ways of getting Apache to reveal it´s version too, so this wont work.

That's true, but this isn't as easy as it seems, and commonly is way beyond the scope of an average script abuser.

Agreed /Yarrel

Mirzoni

12:49

New subject: [suse-security] Apache version

Ok everything is fine , security tips but even server is corectly configured , with maximum security which i have to set up and permisions to dir s , specialy for example on deamon directories such is bin conf log cgi-bin and so on dirs ok everything is ok but i dont need to show wrong version i dont need to show any version any banner in this case nothing just for example when somebody try to do this then he or she :) will get " connection closed by remote host " without any banners .. Is it anyway posibile if not ok i just asking and please don't be ungry , Thank's again ----- Original Message ----- From: "Yarrel" To: Sent: Wednesday, March 06, 2002 1:32 PM Subject: RE: [suse-security] Apache version

...

...
-----Original Message----- From: bolo@lupa.de [mailto:bolo@lupa.de] Sent: Wednesday, March 06, 2002 1:40 PM To: suse-security@suse.com Subject: Re: [suse-security] Apache version

[snipped]

...
Agreed. But it's a common and recommended security practise to hide banners of demons. This is not security through obscurity, but essential.

...
Most of the the activity in your logs, including hack/exploit attempt are from scriptkiddies who couldn't care less what version your running.

NACK. It's highly important, even for some script kiddies, which versions of demons you're running. Most of the cracker lore deals with version informations and whatnot, because most exploits are designed for distinct versions of the programs they're targeted at. There are more types of attackers "out there" than script kiddies.

I agree! Hence my expression: "everything AND the kitchensink" :o) I´m of course aware of the other types as well. I was merely pointing out that tha majority are scriptkiddies who knows nothing about about comp. security.

...
...
The just throw their cookbooks at your IP/firewall regardless.

Yes, they do. And of course it would be silly to hide behind a non-disclosed banner of a vulnerable demon version, but it's perfectly okay to hide versions and demon names of properly installed and sec-hardened servers.

Sure it is. But necessary ? I don´t believe so. Exploits will work regardsless, if the servers vulnerable.

...
...
I believe there´s other ways of getting Apache to reveal it´s version too, so this wont work.

That's true, but this isn't as easy as it seems, and commonly is way beyond the scope of an average script abuser.

Agreed

/Yarrel

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here

Host Master

20:29

New subject: [suse-security] Apache version

...

...
Hello , i would like to ask maybe old-new question and this is : Is posibile to turn of showing version of apache and modules [snipped headers]

Yes.... taken from http://linux.oreillynet.com/pub/a/linux/2001/09/18/insecurities.html also http://www.google.com/search?hl=en&q=apache+hiding+server+version This behavior can be modified in Apache using the ServerTokens directive in the httpd.conf file. ServerTokens takes the following parameters: Minimal, ProductOnly, OS, and Full. The ServerTokens directive defaults to Full, which sends the version of Apache, the operating system, and loaded modules. Minimal will only return the version of Apache. Product will only send that it is Apache. OS will send the version of Apache and the operating system that it is running on. Otherwise I guess you could compile in the desired strings from source.

...

Why ?

Thats a bit like asking an army why they camoflague their tanks if practice shows the enemy will blanket bomb an area using an aerial attack.

...

Security through obscurity doesn´t work. Most of the the activity in your logs, including hack/exploit attempt are from scriptkiddies who couldn't care less what version your running.

The just throw their cookbooks at your IP/firewall regardless.

Script kiddies when they get in tend to just deface your site and say hi to their mates. Serious attacks come from those planning to steal corporate information who wont announce their exploits, and they typically carefully plan their attacks by carefully assessing their enemy and what they are up against. Camoflauge, while not adding security per se, is a useful tool against these. More useful would be to miss lead them by setting the headers to say somthing credible like.... HTTP/1.1 400 Bad Request Server: Microsoft-IIS/5.0 Date: Wed, 06 Mar 2002 12:11:52 GMT Content-Type: text/html Content-Length: 87 just remember to implement the IIS 404 pages!

...

I believe there´s other ways of getting Apache to reveal it´s version too, so this wont work.

should probably read: "...so this wont work all the time". The camoflague will work all the time.

...

Hope this helps

Me too.

Yarrel

12:48

New subject: [suse-security] Apache version

...

-----Original Message----- From: Host Master [mailto:tech@codefoundry.com] Sent: Wednesday, March 06, 2002 9:29 PM To: suse-security@suse.com Subject: Re: [suse-security] Apache version

[snipped]

...

...
Why ?

Thats a bit like asking an army why they camoflague their tanks if practice shows the enemy will blanket bomb an area using an aerial attack.

Funny analogy. If your troops were dug in deep enough, you wouldn´t need the camouflage.

...

Script kiddies when they get in tend to just deface your site and say hi to their mates. Serious attacks come from those planning to steal corporate information who wont announce their exploits, and they typically carefully plan their attacks by carefully assessing their enemy and what they are up against. Camoflauge, while not adding security per se, is a useful tool against these. More useful would be to miss lead them by setting the headers to say somthing credible like....

[snipped MS header] Sure. However, the task of enumerating a system, header forged or not are trivial. The patient and skilled attacker will see through this imediately.

...

...
I believe there´s other ways of getting Apache to reveal it´s version too, so this wont work.

should probably read: "...so this wont work all the time". The camoflague will work all the time.

True /Yarrel

Boris Lorenz

12:31

New subject: [suse-security] Apache version

Hi, Mirzoni wrote:

...

Hello , i would like to ask maybe old-new question and this is : Is posibile to turn of showing version of apache and modules instaled when i telnet on web server to port 80 and type get HTTP/1.1 somefile.htm and then i get this what i dont want to be shown , for example

[...] for a start, try Apache's ServerTokens directive: http://httpd.apache.org/docs/mod/core.html#servertokens If you also want to hide the product itself (Apache), you will have to apply some minor modifications to the include file httpd.h (about line-# 433) in <your-apache-dir>/src/include. Boris Lorenz ---

Juan Carlos S.C

7 Mar 7 Mar

11:16

New subject: [suse-security] Apache version

Mirzoni wrote:

...

Hello , i would like to ask maybe old-new question and this is : Is posibile to turn of showing version of apache and modules instaled when i telnet on web server to port 80 and type get HTTP/1.1 somefile.htm and then i get this what i dont want to be shown , for example

telnet somehost 80 Trying somehost... Connected to somehost. Escape character is '^]'. get HTTP/1.1 somefile.htm

HTTP/1.1 400 Bad Request Date: day, date ti:me GMT Server: Apache/1.3.23 (Unix) PHP/4.1.2 Connection: close Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>400 Bad Request</TITLE> </HEAD><BODY> <H1>Bad Request</H1> Your browser sent a request that this server could not understand.<P> Invalid URI in request get HTTP/1.1 somefile.htm<P> <EN> <ADDRESS>Apache/1.3.23 Server at www.mywebserver.domain Port 80</ADDRESS> </BODY></HTML> Connection closed by foreign host.

Sorry but i did not can find any useful request in mail list archives

Thanks in advance

Try this apache directive: ServerTokens. http://httpd.apache.org/docs/mod/core.html#servertokens

8092

Age (days ago)

8093

Last active (days ago)

List overview

Download

22 comments

8 participants

participants (8)

Boris Lorenz
Host Master
Juan Carlos S.C
Michael Appeldorn
Mirzoni
phil
Ralf Ronneburger
Yarrel