PDA

Bekijk Volledige Versie : PHPinfo posten een potentieel gevaar?



Jamai
30/08/04, 16:41
Stel dat ik een hostingbedrijf heb, dan is het natuurlijk nuttig voor je (potentiële) klanten om te weten welke modules je geinstalleerd hebt e.d., en wat de PHP-instellingen zijn (m.b.t. safe_mode e.d.).
Je zou daarvoor een phpinfo(); kunnen posten en linken vanaf de website.

Ik heb hier al een beetje over zitten filosoferen. Zou dit een potentieel gevaar zijn? Je moet niet "hackers" natuurlijk niet nog wijzer maken dan ze al zijn, maar is de info wel interessant voor ze of zijn ze er niet echt mee geholpen?

Triloxigen
30/08/04, 16:52
Interesant is het op zich wel,
weten welek versie het draait en daarvoor exploits zoeken.
Maar daar zijn ook andere maniren voor om daar achter te komen.

Cybafish
30/08/04, 17:03
Vertrouwen hebben in je eigen beveiliging blijft belangrijk... en ook zorgen dat je daar een reden voor hebt! Een PHPinfo laat zulke basale info zien, dat zou eigenlijk geen gevaar moeten vormen. Doet het dit (voor jouw gevoel) wel dan zul je bij jezelf moeten raadslagen of je beveiliging wel up to date is.

Nova
30/08/04, 17:06
netcraft.com =) en je weet in een muisklik welke phpversie ^^

als je het systeem goed uptodate houd zou er geen probleem moeten zijn

Jamai
30/08/04, 18:03
Nou ik heb nog geen draaide webserver hoor, daar niet van, dus beveiliging (of gebrek eraan ;)) is nog geen sprake van. Maar bedankt voor alle antwoorden, ik ben weer een klein stapje wijzer geworden. Met Netcraft vind ik eigenlijk alle informatie waar ik over twijfelde of het nuttig zou zijn voor hackers, dus ik denk dat ik er later maar gewoon een phpinfo op zet.

V. Kleijnendorst
30/08/04, 18:16
Netcraft kijkt toch alleen maar naar de headers die je webserver geeft?
Kun je dus ook uitztten.

PHPinfo geeft aardig wat informatie, kan voor een cracker handig zijn om een path uit te vogelen van een klant van je die slechte PHP scripts schrijft. Met zulke informatie kun je niet spaarzaam genoeg zijn vind ik.

Je kunt altijd nog de phpinfo op aanvraag tonen.

Beyonder
30/08/04, 18:23
Gewoon phpinfo achter een passwoord beveiligde directory zetten die alleen toegankelijk is voor klanten.

Hackers meer laten weten dan ze al eenvoudig uit kunnen zoeken is inderdaad een domme zet.

Cybafish
30/08/04, 18:32
Wat is het nut van een phpinfo achter een beveiligde dir voor klanten? Die klanten kunnen dan gewoon een phpinfo generaten op hun eigen account. Het gaat juist om het informeren aan potentiële klanten, lijkt mij.

Jamai
30/08/04, 19:52
Ik kan natuurlijk ook even het bestandje (= de output) opslaan en tonen op aanvraag. Lijkt me dan toch wel een stukkie veiliger, dan weet je tenminste nog wie het onder ogen gehad hebben...

Dennis
30/08/04, 19:57
Origineel geplaatst door Jamai
Ik kan natuurlijk ook even het bestandje (= de output) opslaan en tonen op aanvraag. Lijkt me dan toch wel een stukkie veiliger, dan weet je tenminste nog wie het onder ogen gehad hebben... Maar klanten kunnen zelf ook een phpinfo.php aanmaken en aan anderen laten zien.

@Beyonder:
Wanneer kan een hacker iets hebben aan de gegevens uit een phpinfo.php bestand dan?

Triloxigen
30/08/04, 20:02
Origineel geplaatst door DennisCitus
@Beyonder:
Wanneer kan een hacker iets hebben aan de gegevens uit een phpinfo.php bestand dan?

PHP veris weten en eventueel een aantal modules, en daar exploits bij zoeken.. :)

Dennis
30/08/04, 20:05
Indien een hacker zelf geen php-exploits en php-scripts kan uploaden, is dit toch niet gevaarlijk?

V. Kleijnendorst
30/08/04, 20:18
Origineel geplaatst door DennisCitus
Indien een hacker zelf geen php-exploits en php-scripts kan uploaden, is dit toch niet gevaarlijk?

Maar dit hangt ook weer van je klanten af; een brak upload scriptje doet wonderen.

Daarnaast zijn er nog altijd scripters die een bestand includen aan de hand van een $_GET[] var. Via PHPinfo is dan makkelijker uit te zoeken wat een geschikt path is naar leuke bestanden.

Je kunt je klanten in ieder geval adviseren om niet zomaar phpinfo in een open dir te zetten. Door het bijvoorbeeld op te nemen in je control panel verleen je klanten een eenvoudige service en zullen klanten het zelf niet zo snel aanmaken.

Triloxigen
30/08/04, 20:34
Origineel geplaatst door DennisCitus
Indien een hacker zelf geen php-exploits en php-scripts kan uploaden, is dit toch niet gevaarlijk?

Wel :)

_arno_
30/08/04, 20:45
Origineel geplaatst door Triloxigen


Wel :)

Kunt u dit argumenteren , ben wel geintereseert in

Triloxigen
30/08/04, 20:47
Origineel geplaatst door _arno_


Kunt u dit argumenteren , ben wel geintereseert in

Er zijn ontzettend veel foute dingen gescript in PHP, dus je kunt veel via de URL uithalen.
Maar ook zonder die fouten zijn er dingen die via een URL gedaan kunnen worden.

_arno_
30/08/04, 20:50
Dus met bepaalde dingen mee geven in de url zou dus een exploit kunnen worden misbruikt.
Maar als jij je php script goed heb gebouwt moet dit toch niet mogelijk zijn lijkt mij

McRox
30/08/04, 21:29
Origineel geplaatst door Cybafish
Vertrouwen hebben in je eigen beveiliging blijft belangrijk... en ook zorgen dat je daar een reden voor hebt! Een PHPinfo laat zulke basale info zien, dat zou eigenlijk geen gevaar moeten vormen. Doet het dit (voor jouw gevoel) wel dan zul je bij jezelf moeten raadslagen of je beveiliging wel up to date is.

Heel toevallig kom ik een phpinfo tegen op jullie website, waarvan ik toch een tip moet geven, upgrade je kernel!! RedHat 9 biedt al heel lang geen updates/patches. Je huidige kernel heeft sowieso 1 crash exploit en een root privilege exploit.


Origineel geplaatst door _arno_


Kunt u dit argumenteren , ben wel geintereseert in

Zou jij graag misbruikers de mogelijkheid geven om allerlei dos/irc/rootkits/spam scripts kan uploaden en draaien dankzij een onveilige phpnuke?

Cybafish
30/08/04, 21:31
Weet ik, maar wij hebben zo onze maatregelen genomen, afgezien van de (laatste officiële door redhat uitgegeven) kernel versie :)

Carl<n-media>
30/08/04, 21:32
Origineel geplaatst door _arno_


Kunt u dit argumenteren , ben wel geintereseert in
Let er in ieder geval op dat je je /tmp folder beveiligd. Hier worden nog steeds veel fouten in gemaakt.

mihosnet
30/08/04, 22:24
Origineel geplaatst door Carl&lt;n-media&gt;

Let er in ieder geval op dat je je /tmp folder beveiligd. Hier worden nog steeds veel fouten in gemaakt.

Een noexec alleen lost niet alles op, als je dat bedoelt.

iRick
30/08/04, 22:34
Er is altijd de mogelijkheid dat er een attack op de server word uitgevoerd, maar als je gewoon alles up to date houd (dus ook php!) dan hoef je je in veel gevallen niet veel zorgen te maken.

Jamai
30/08/04, 22:48
Als ik gebruik maak van Debian packages uit http://www.debian.org/distrib/packages zijn ze natuurlijk altijd wel ietsje verouderd, maar is het gevaarlijk oud of is het wel te doen?

The MAzTER
30/08/04, 22:51
Origineel geplaatst door Jamai
Als ik gebruik maak van Debian packages uit http://www.debian.org/distrib/packages zijn ze natuurlijk altijd wel ietsje verouderd, maar is het gevaarlijk oud of is het wel te doen?

je bedoelt php?

je moet sowieso naar php 4.3.8 upgraden omdat alles wat daar onder zit secu bugs hebben.

Carl<n-media>
30/08/04, 22:55
Origineel geplaatst door mihosnet


Een noexec alleen lost niet alles op, als je dat bedoelt.
Niet alles, maar toch veel.

McRox
30/08/04, 23:01
Origineel geplaatst door Carl&lt;n-media&gt;

Niet alles, maar toch veel.

noexec is makkelijk te omzeilen. Tegenwoordig is een dagelijkse controle op de /tmp, /var/tmp, /dev/shm etc. net zo belangrijk als het controleren van logs en op rootkits..

Wido
30/08/04, 23:37
allow_url_fopen uit is ook een goede optie.

Als je dan nog even compiled net --disable-posix dan is het helemaal goed.

De URL fopen zet je dan gewoon alleen aan voor de klanten die het willen.

_arno_
31/08/04, 00:29
Origineel geplaatst door McRox

Zou jij graag misbruikers de mogelijkheid geven om allerlei dos/irc/rootkits/spam scripts kan uploaden en draaien dankzij een onveilige phpnuke?

Ik wist niet dat het mogelijk was om via de url te hacken, vandaar de vraag.
Natuurlijk wel die specefieke site , maar niet een gehele server

sander
31/08/04, 10:55
phpnuke etc worden veel gebruikt om allerlei vunzige tools op je server te zetten ik zie vaak bij klanten dat hun hele /tmp vol zit met rare tools.

Beyonder
31/08/04, 11:04
PHP script bevatten veel mogelijke exploits en zoals eerder aangegeven is er nog geen 100% afdoende beveiliging hiervoor te vinden _zonder_ een hele hoop functionaliteit uit te schakelen.

"security by obscurity" is wellicht niet de juiste methode, maar domweg PHP info scripts posten op je website is naar mijn inzien een zeer slecht idee.

Een vals gevoel van veiligheid is nog veel erger dan niet zeker weten of je goed beveiligd bent.

Quotes:

"Origineel geplaatst door Cybafish
Vertrouwen hebben in je eigen beveiliging blijft belangrijk... en ook zorgen dat je daar een reden voor hebt! "

"Weet ik, maar wij hebben zo onze maatregelen genomen, afgezien van de (laatste officiële door redhat uitgegeven) kernel versie"

fusehost
31/08/04, 11:12
Origineel geplaatst door The MAzTER


je bedoelt php?

je moet sowieso naar php 4.3.8 upgraden omdat alles wat daar onder zit secu bugs hebben.

Euh, niet correct :)

De debian pakketten uit Stable zijn wel degelijk secure (op voorwaarde dat je de security updates van debian zelf regelmatig installeert), en dat is momenteel versie 4.1.2...

Jamai
31/08/04, 11:53
Ik heb inderdaad ook al meegemaakt dat een server gehacked werd door een installatie van een phpBB/PostNuke/PHPNuke-installatie van een klant. Erg slecht :(

fusehost
31/08/04, 11:57
Ja, maar dat zijn fouten in phpbb/nuke/..., niet in php. Als je iemand phpinfo() geeft, weet die absoluut niet of die phpbb versies fouten bevatten.

Triloxigen
31/08/04, 12:01
Veel mensen vergeten op de server open_basedir aan te zetten :)

Jamai
31/08/04, 20:00
Origineel geplaatst door fusehost


Euh, niet correct :)

De debian pakketten uit Stable zijn wel degelijk secure (op voorwaarde dat je de security updates van debian zelf regelmatig installeert), en dat is momenteel versie 4.1.2...
Ik heb vanuit Debian Packages geinstalleerd naar PHP 4.3.4, dus vrij recent wel.

open_basedir is natuurlijk ook iets om niet te vergeten :)