Ist programmieren mit PHP gefährlich?

radarin

radarin

Angesehenes Mitglied
Hallo Liste.
Seit ich mit meiner Domain zu 'Hostpoint' gewechselt bin, und die Programmierung von CFML auf PHP geändert habe, bin ich immer wieder erfolgreichen Hackeratacken ausgesetzt. Bis anhin beschränkten sich diese darauf mir die Index.php zu überschreiben und so einen anderen Inhalt zu zeigen. Gestern Abend aber um 17:30 hat jemand den Server dazu missbraucht einen anderen Server massiv mit Anfragen zu attakieren. Dies hat beim Provider wohl Alarm ausgelöst, worauf dieser kurzerhand meine Domain vom Netz genommen hat...

Das hat nun zur Folge, dass meine Kunden Ihre Daten nicht mehr publizieren können uns keine eMails mehr bekommen. Besucher bekommen eine geschäftsschädigende Blindseite zu sehen, worauf im Wesentlichen Eigenwerbung für Hostpoint zu lesen ist. Und für den Eigentümer der Hinweis, er möge bei Hostpoint anrufen. Dort lässt der AB dann wissen, bitte erst am Montag wieder.

Hostpoint ist der Meinung, dass es nicht an ihrer Firewall liegen kann, ich müsse wohl fahrlässig und gefährlich programmiert haben. Was soll ich dazu sagen? Ich bekomme einfach den Eindruck als soll da der schwarze Peter weitergereicht werden. Man hat mir zugesagt, man würde sich den Code ansehen und mir mitteilen was ich falsch gemacht hätte, aber diesbezüglich ist das zugesicherte Mail ausgeblieben. Offenbar doch nocht ein eindeutiger Programmierfehler meinerseits..?

Worauf man mich hingewiesen hat, der behutsame Umgang mit include(). Wenn ich den Dateinamen 1:1 in eine URL-Variable schreibe könne da mit etwas Wissen viel Schabernack getrieben werden. Deshalb habe ich das soweit angepasst, dass es nur mit Seiten funktioniert, die ich in einem Array aufgelistet habe, und somit für erlaubt definiere. Wird die URL manipuliert kommt eine Fehlermeldung. Ich weiss nicht, vielleicht reicht dies auch nicht aus, aber auf die include() Funktion will ich dann doch nicht verzichten. Sonst verwende ich im esentlichen einfach verschiedene Variablen und SQL-Abfragen, also nichts das nicht im PHP-Manual steht.

Meine Domain ist jetzt einfach tot, obwohl ich dringend daran arbeiten sollte...
 
Das ist in etwas so wie wenn du den Arzt anrufst und ihm sagst das du dich gestern und heute übergeben hast müssen und gerne eine Diagnose am Telefon hättest.

Man kann in jeder Programmiersprache Fehler machen die eine Sicherheitslücke darstellen.
Es gibt aber noch andere Gefahrenquellen, als Beispiel sei hier mal ein FTP-Zugang genannt.
 
Der Hoster behauptet natürlich der FTP sei in Ordnung, deshalb hat er mir die Domain ja blockiert, weil er behaupter es müsse am PHP-Code liegen, auf diesen hat er ja Zugriff, kann (oder will) sich nicht dazu äussern was angeblich nicht gut sein soll...

Seite ist jetzt offline, der Provider nicht erreichbar. Muss wohl zu einem anderen Hoster zügeln und meinen Anwalt einschalten. Wenns dann passt ist eindeutig der Fehler bei Hostpoint, wenns weiterhin erfolgreiche Attacken gibt könnte der Fehler auch bei mir liegen, ich wüsste aber nicht wo...
 
sichere dich doch mit .htaccess ab.
Schau dir die logins via ftp mal an und frag mal deinen provider über welche IP die änderungen erfolgt sind.

Hast du ein web-FTP ???
wenn ja würde ich den auch mal prüfen.

Ändere alle passwörter und sorge dafür das die passwörter für die Datenbank (fals vorhanden) nicht frei einsehbar sind.
biggrin.gif
 
Die Passwürter und dergelichen habe ich in einer .inc Datei abgelegt, die solten wohl nicht einsehbar sein.

ich habe keinen Schimmer was in in die .htacces reinschreiben soll, da sind jetzt einfach nur die ErrorDocument drinn. Hostpoint sagt mir, es sei für sie nicht nachvollziehbar wie der Hacker den Server unter seine Kontrolle gebracht hat, deshalb könne der Fehler nur bei mir liegen. Sagen was ich aber angeblich gefährlich programmiert haben soll, das kann oder will mir keiner sagen.

Hostpoint hat den Server soweit blockiert, dass ich nicht mal mehr Zugriff über das Controllpannel habe, also nicht mal mehr meine DB's sichern kann. Der FTP ist ebenfalls blockiert, ich kann also auch keine Logfiles mehr auswerten.

Web-FTP? Nicht dass ich wüsste, verwende selber SmartFTP. Für MySQLFront ist allerdings ein Access offen, weiss nicht ob der ein Problem darstellen könnte.

Hostpoint muss natürlich seine Infrastruktur schützen, das kann ich ja verstehen, aber sich dumm stellen und mir die Schuld zuweisen, ohne das konkret zu begründen, finde ich schon etwas unverschämt. Seit über 24 h ist weder per email noch telefonisch jemand erreichbar. Mir rennen die Kunden die Bude ein weil nichts mehr geht.
Wahrscheinlich haben sie sich in ihren ABG soweit abgesichert dass ich für diesen Ausfall nur Schwer Regressansprüche stellen kann.

Muss ich eine Strafanzeige gegen unbekannt (also den Hacker) erstatten, damit der Provider gezwungen wird sich konkret darum zu kümmern wie der Server geknackt werden konnte..?

Mir sind derzeit die Hände gebunden. Könnte einzig den Hoster wechseln, nur falls mein Code wirklich ein Problem in sich hat, wäre das keine längerfristige lösung...
 
Ich würde es erstmal ohne anwälte versuchen da dadurch unnötige kosten entstehen.

Ich kenne den anbieter leider nicht aber das vorgehen ist schon recht krass.

Die sollen mal in ihren logs schaun woher die änderungen kommen (ein guter provider hat normal solche logs)

Somit hättest du ne möglichkeit den Hacker ausfindig zu machen.
(die meisten script-kidies schützen sich gegen rückverfolgung nur schwach oder garnicht).

Du solltest mal schaun ob du irgendwelche lücken in deinem quelltext findest.
(erlaubte Datei-uploads, zugriff auf datenbanken, usw.)

Schreib den provider mal an er soll dir wenigstens die logs zukommen lassen.

Hast du die Seite selbst geprogt???

Nimm dir eine alternative domain und lade deine seite da mal hoch und weise deinen provider an wenigstens eine umleitung einzurichten damit dein geschäft weiter läuft.

Viel glück
 
Da kann ich den Hoster anweisen soviel ich will, wenn dem übers Wochenende seine Kunden offenbar egal sind. Und solange ich die DB nicht dumpen kann, nützt das ganze verschieben nix, ausserdem habe ich im Code einige absolute http Verweise drinn, nein das ist nicht die Lösung.

Die Seite habe ich selber programmiert, den Code kenne ich und da ist mir nichts bewusst das Probleme bieten könnte.

Im Hauptverzeichnis habe ich für DB's nur Abfragen drinn für die Ausgabe der Daten. Die Update und Unsert Funktionen sind im Adminbereich. Der ist eigentlich geschützt durch einen DB-Login und eine Session Variable. Dass dort ein User erstellt oder ein bestehender benutzt wird, konnte ich nicht feststellen, da ich derzeit so ziemlich der Einzige bin der den Bereich nutzt. Im Adminbereich kann man in ein Verzeichnis Daten hochladen, theoretisch auch Anderes ausser Bilder. Die Abfrage auf JPG oder GIF muss ich da wohl noch integrieren. Ob es in dem Verzeichnis unerlaubte Dateien hat kann ich leider nicht feststellen, da mir ja auch der FTP-Zugang gesperrt wurde.

Was die Serverfunktionen angehen habe ich nicht viel Ahnung, interessiert mich auch nicht, bin ja kein Hacker, will ja nur Webseiten programmieren, aber mit PHP..?
 
naja dacht das wäre ne notlösung aber wenn die sich garnicht melden ist das echt schei..

Ich hoffe du findest noch eine lösung mit dennen.

Sorry das ich dir auch nicht weiterhelfen konnte.
sad.gif
 
der einzig fremde Code ist derzeit phpBB, und das wäre wohl kaum so verbreitet wenn dessen Code nicht in Ordnung wäre.

Ich publiziere jetzt einen Hinweis auf meiner HP, damit die Kunden die dort nachsehen wenigstens informiert sind, bekomme schon genug Reklamationen deswegen...
 
mhhh irgendwas kann da nicht ganz stimmen.
Hast du einen server?
oder nur ein 'Webspace-paket' ?

hier ist die rede von 'server unter kontrolle zu bringen' .
hast du ein webspace paket, ist der pvider dafür zuständig, wenn der server unter kontrolle anderer gerät, hat der provider meiner meinung nach erst einmal ein problem.

Eine andere sache.... hat deine seite viele zugriffe?
Hast du möglicherweise viel traffic?
kenne hostpoint nicht, kenne aber sehr ähnliche fälle, bei anderen providern, die oftmals zu solchen mitteln greifen, um usern mit viel traffic einfach nahe zu legen, den provider zu wechseln.



 
wird wahrscheinlich ein virtueller server sein, habe rund 200 Besucher am Tag. Mehr kann ich nicht sagen, bekomme ja keinerlei Auskunft und kann auch nicht nachsehen was auf dem Server rumliegt was da nicht hingehört...

vor zwei Tagen hat einer einfach die Index.php überschrieben, mit dieser Zeile drinn:

owned by w00pie.nl - w00pie / 00pz / sirh0t / gunes
 
Es hilft dir wahrscheinlich nicht direkt weiter aber:
-.inc files für Passwörter sind dann eine Sicherheitslücke wenn die Files einfach aufgerufen werden können. Da die nicht geparst werden, werden die dann einfach angezeigt!

-FTP überträgt soweit ich weiß unverschlüsselt, ist also per se unsicher.

Ansonsten:
Secure Programing in PHP durchlesen:
http://www.zend.com/zend/art/art-oertli.php
 
QUOTE -FTP überträgt soweit ich weiß unverschlüsselt, ist also per se unsicher.


Man kann FTP auch verschlüsselt realisieren, aber das bietet nicht jeder Provider an.

Die Frage nach Sicherheit bringt hier nicht wirklich weiter.
Wenn hier der wunde Punkt ist, dann wäre eine Wörterbuchattacke auf den Login am wahrscheinlichtsten. Und da ist Verschlüsselung unerheblich.

@radarin
Du solltest dir unbedingt die Logfiles vornehmen und so lange suchen, bis du Informationen zum Hack gefunden hast.
Informationen über die Aktionen des Hackers zu erlangen ist ein Muss.
Wenn du hier kein Durchhaltevermögen hast, wirst du nicht weiterkommen und keine Gegenmaßnahmen treffen können.

Eine simple Google-Suche nach "w00pie.nl" bringt übrigens weitere wertvolle Infos.
Bei den Betreibern von www.pferde.ch dürfte man weitere Informationen zur Sache bekommen.
 
QUOTE (radarin @ Sa 4.12.2004, 22:15)vor zwei Tagen hat einer einfach die Index.php überschrieben, mit dieser Zeile drinn:
owned by w00pie.nl - w00pie / 00pz / sirh0t / gunes

Google mal nach diesem "w00pie.nl" - und achtung, die Suchresultate nicht blind anklicken, einige von denen könnten infiziert sein ;-)

Mindestens die Site mit den Pferden - falls das nicht Deine ist - hat also anscheinend dasselbe Problem wie Du, und es ist auch aktuell - und bei Hostpoint...
Könnte evtl. ein neuer Wurm oder sowas sein, für dens noch keine weiteren Infos gibt.

Der Hinweis bei chip.de betrifft zwar nicht ganz dasselbe, aber vielleicht hats ja doch mit dem RBot.qz Wurm zu tun.

In der Richtung könntest Du vielleicht rausfinden, wie und womit der Server gehackt wurde, und mit Removal Tools säubern, damit es so bald wie möglich wieder läuft. Ausserdem wüsstest Du dann hoffentlich, ob da wirklich ein "Loch" in Deinem Code ausgenützt wurde oder ob der Angriff auf eine ganz andere Weise durchkam.

Jedenfalls solltest Du vorsichtig sein mit dem Webkopieren der Site zu einem neuen Provider - falls verseuchte Files drin sind, tritt das Problem dort gleich wieder auf.

Griessli
Irene

Edit: @Ansgar, warst schneller ;-)
 
Habe mittlerweile Antwort vom Provider erhalten:

QUOTE Ja PHP ist unsicher, sofern mann es nicht absolut sicher programmiert. Die Hacker können
allow_url_fopen zum Beispiel missbrauchen. Die haben wir standardmässig deaktiviert. Haben Sie
diese mit .htaccess oder einer php.ini wieder aktiviert?


allow_url_fopen, was ist denn das? Ich bin mir nicht bewusst dies aktiviert zu haben


QUOTE Da haben Sie mich falsch verstanden. Klar wurde Ihre Webseite gehackt und Sie hat einen sehr
grossen Schaden angerichtet. Im schlimmsten Fall könnte so eine ganze Hosting Firma lahmgelegt
werden. Bei unseren Sicherheitsvorkehrungen betrifft dies nur den entsprechenden Server (auch nicht
gut). Ebenfalls verbrennen Sie ca. 80 bis 100 MBit. 1 MBit kostet ca. 100 SFr. im Monat.


Offensichtlich sind Hacker ein Problem. Hoffe doch, die vielen Mbit kommen nicht vom normalen Betrieb, sondern vom Hacker, ausserdem steht in meinem Vertrag 'unbeschränkt' aber sowas bringt natürlich die Mischrechnung durcheinander.


QUOTE In Ihrem Fall wird es wohl die index.php Datei sein, welche unsicher programmiert ist. Bitte ersetzten
Sie diese umgehend. Ich habe Sie nun ausnahmsweise wieder freigeschaltet. Falls Sie gleich wieder
gehackt werden müssen wir die Seite jedoch wieder vom Netz nehmen. Einer unser Entwickler wird
sich am Montag bei Ihnen melden.

Bitte beachten Sie, dass wir immer im Interesse aller Kunden handeln. Was würden Sie sagen, wenn
Ihre Seite Down wäre weil ein anderer unsicher programmiert hat und wir das einfach ignorieren
würden.


Das Vorgehen des Providers ist in den Grundzügen ja nachvollziehbar, und ich könnte in seinem Fall ja auch nicht anders handeln, aber die Aussage 'es wird wohl' hilft mir da auch nicht ganz weiter.
Und wie soll ich an meinen Seiten korrekturen vornehmen, wenn der FTP nicht funktioniert? Seite ist zwas wieder Online, aber arbeiten kann ich trotzdem nicht...

Im Folgenden mal der Code der blind als gefährlich beschimpft wird:


CODE
<?php
// index.php
// Gültigkeit der Seite
define('x_CH', true);
// Root Pfad
$x_root_path = './';
// Dateiendung einlesen
include($x_root_path . 'extension.inc');
// URL Variable prüfen und ggf. setzen
if(isset($HTTP_GET_VARS['page'])){
$page = $HTTP_GET_VARS['page'];
}else{
$page = "home";
}
// Seiten für Include Validieren
include($x_root_path . 'validation.inc');

// index.php muss geladen sein
define("INDEX_IS_LOADED",1);
?>

<?php
// Modus erfassen, normaler Betrieb der Wartung
include($x_root_path . 'admin.inc');

if ($admin == '0')
{
include($x_root_path . 'wartung.'.$phpEx); // Wartung
}
else if ($admin == '1')
{
include($x_root_path . 'ci.'.$phpEx); // normale Darstellung
}


?>




CODE
<?php
// validation.inc

$valid_params = array
(
'home',
'hgj',
'ghjgv',
'hgghf',
'forum',
'gggt',
'ehjk',
'hjjui',
'error'
);


$valid = trim($page);

if(! in_array($valid, $valid_params))
{
echo "<META HTTP-EQUIV=\"Refresh\" CONTENT=\"0; URL=http://www.x.ch/index.php?page=error&view=validation\">";
die ('');
}


?>





CODE
<!-- ci.php -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>www.x.ch</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel=stylesheet type="text/css" href="style.css">
<meta http-equiv="Page-Exit" content="blendTrans(Duration=0.6)">
<meta http-equiv="Page-Enter" content="blendTrans(Duration=0.6)">
</head>

<body><a name="top"></a>

<DIV align="center">
<table width="95%" border="0" cellpadding="2" cellspacing="0"><tr><td>
<!-- Logo/Banner -->
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td align="left" valign="top"><!-- Logo --><img src="img/ci/logo.jpg" width="201" height="129" border="0"></td>
<td align="right" valign="top"><?php include("banner.php"); ?></td>
</tr>
</table>



</td></tr><tr><td>
<!-- Navigation -->
<?php
// Navigation
include($x_root_path . 'nav.'.$phpEx);
?>
</td></tr><tr><td>
<!-- Innere Zelle -->
<table width="100%" border="0" cellpadding="1" cellspacing="0" bgcolor="#6E4914"><tr><td>
<table width="100%" border="0" cellpadding="10" cellspacing="0" bgcolor="#FFF2D2"><tr><td>
<?php
// Seiteninhalt
include($x_root_path.$page.".".$phpEx);
?>



</td></tr></table>
</td></tr></table>
<!-- -->
<?php
// Fussteil
include($x_root_path . 'feet.'.$phpEx);
?>
</td></tr></table>

</DIV>
</body>
</html>



include($x_root_path.$page.".".$phpEx); liest nun die jeweilige Seite, php oder htm z.b. ein. Dies ist natürlich so gelöst, damit ich die ganze Darstellung drum herum nur 1 Mal machen muss.

Stellt sich hier die Frage, ist das include() hier wirklich ein Problem? Habe ich zu wenig abgeblockt? Es ist theoretisch ja nur die URL-Variable 'page' die dann einen include() steuert die u.U. beeinflusst werden kann. Würde es das Problem ev. lösen an stelle von index.php?page=home.php - index.php?page=1 zu verwenden, und im Hintergrund die Nummern in einen Seitennamen zu verwandeln? Reicht da einfach eine if/elseif, oder muss ich da nochmals anders vorgehen um den Code zu schützen..?



 
das angesprochene mail vom provider war gestern kurz vor mitternacht gekommen, das folgende habe ich soeben erhalten:

QUOTE
Ihre Webseite hatte uns heute Morgen erneut aus dem Bett geholt:

last pid: 16487; load averages: 496.39, 496.51, 483.58 up 2+11:15:01 08:31:47
648 processes: 498 running, 147 sleeping, 3 zombie
CPU states: 32.9% user, 0.0% nice, 65.2% system, 1.9% interrupt, 0.0% idle
Mem: 639M Active, 2351M Inact, 442M Wired, 178M Cache, 199M Buf, 287M Free
Swap: 4096M Total, 40K Used, 4096M Free

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
91478 pferdec 64 0 2644K 2112K RUN 2 134:27 93.31% 93.31% perl
35736 pferdec 64 0 3832K 3316K CPU0 0 300:52 91.60% 91.60% perl
16474 root 35 0 2724K 1960K CPU2 2 0:00 7.50% 1.66% top
16475 mailnull 2 0 5620K 4020K sbwait 2 0:00 0.66% 0.15% exim-4.41-0
16466 mailnull 2 0 5620K 4020K sbwait 0 0:00 0.30% 0.10% exim-4.41-0
466 clamav 2 0 29448K 28580K poll 0 22:28 0.00% 0.00% clamd
341 root 10 20 18412K 16384K wait 2 20:02 0.00% 0.00% perl
592 root 2 0 36168K 32184K select 0 5:46 0.00% 0.00% httpd
353 root 2 0 5332K 3540K select 2 4:56 0.00% 0.00% cppop
526 mysql 2 11 190M 49240K poll 0 2:08 0.00% 0.00% mysqld
523 mysql 2 11 190M 49240K select 2 1:27 0.00% 0.00% mysqld
691 root 10 0 6540K 5148K nanslp 0 1:20 0.00% 0.00% perl
206 root 2 0 1000K 636K select 2 1:08 0.00% 0.00% syslogd
439 cpanel 2 0 5132K 2664K poll 2 1:00 0.00% 0.00% stunnel-4.04
576 mysql 2 14 190M 49240K select 0 0:51 0.00% 0.00% mysqld
578 mysql 18 14 190M 49240K pause 0 0:50 0.00% 0.00% mysqld


Dadurch waren sämtliche Webseiten sehr langsam auf derm System und der mySQL Diest war
nicht mehr erreichbar.




das sind alles viele schöne zeichen, sehen vielleicht beeindruckend aus, hilft mir aber so nicht weiter, denn mir sagt das alles nichts...
 
QUOTE Ebenfalls verbrennen Sie ca. 80 bis 100 MBit. 1 MBit kostet ca. 100 SFr. im Monat.


Was meinen die den mit 1 MBit .... Ich kenne MBit als Abkürzung von MegaBit -> 8 MegaBit = 1 MegaByte .... Und wenn die unendlich Traffic anbieten, dann ist das denen ihr Risiko, daß da ach mal Poweruser auftreten. Wenn die sich nicht gegen Poweruser in der AGB abgesichert haben, würde ich nichts nachzahlen .... wenn die Ärger machen, dann einfach wechseln ... Hoster gibt es bald mehr wie Sand am Meer.



QUOTE das sind alles viele schöne zeichen, sehen vielleicht beeindruckend aus, hilft mir aber so nicht weiter, denn mir sagt das alles nichts...


Zu deinem Hackproblem kann ich dir wenig helfen. Den Inhalt dieser Mail verstehe ich auch nicht.
 
hallo

QUOTE PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
91478 pferdec 64 0 2644K 2112K RUN 2 134:27 93.31% 93.31% perl
35736 pferdec 64 0 3832K 3316K CPU0 0 300:52 91.60% 91.60% perl
sagt aus, dass der users pferdec das System sinnlos auslastet. Wenn das nicht dein Prozess ist, dann bist du schon wieder gehackt worden.

Versetz ich doch mal in das Hirn einen Skippt-Kiddies: Es kann nur bereits veröffentlichte Exploids ausnutzen. Selber findest es in der Regel nichts. Also wird deine Index.php kaum das Problem sein, sondern eher die TOTAL VERALTETE Version von phpbb. Guck doch mal das an: http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=240513

Diesen Fix solltest du sofort einspielen.

Gruss
Roger
 
Was steht in der nav.php? Die wird ja offenbar bei admin=1 mit eingebunden? (und "script.php?admin=1" dürfte ungefähr der erste Versuch jedes Hackers sein)

Der Rest des Codes scheint mir sicher zu sein, der includepfad wird explizit gesetzt, die erlaubten $page werden validiert.

@Rainer: Ich glaube es geht um die Bandbreite. Der Provider rechnet 100 SFr pro MBit/s

Gruß, SloMo
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben