Server wird gehackt

[gooof]

Hallo,

ich brauche dringend Hilfe von Speziallisten.

Auf 2 meiner Server werden geziehlt angegriffen. Und das auch noch mit Erfolg.

Eben wurde eine Datei 404.php hochgeladen und aufgerufen, welche mir kurzzeitig den Apache lahmgelegt hat.
Auf den neueren Server wird andauert eine Datei auf dem Server umgeschrieben bzw. etwas angehängt was zu Fehlern führt.

Register_globals ist auf ON und Safemode auf OFF.

Kann man da so einfach eine Datei hochladen oder online ändern, wenn der Server nichtmal FTP Zugang hat?

Auf beiden läuft Debian Etch 4, auf einem aber PHP4 und auf dem anderen PHP5 (was aber keinen Uunterschied bei den Angriffen macht).
Also nochmal, es werden Dateien verändert, bzw. in Verzeichnise hochgeladen wo es auf der Seite überhaupt keine Möglichkeit zu gibt. :roll:

Ich bin am Ende... :oops:

[EdRoxter]

Dass du die Kiste neu aufsetzen musst, ist klar.

Boote ins Rescue-System, sichere alle Logfiles und schau, ob sich da nicht jemand durch ein Loch in einer PHP-Applikation (alte Versionen von Joomla, Forensoftware, Typo3, whatever) Zugang verschafft hat.

[gooof]

Aber wie können diese Hacker Dateien auf dem Server ändern oder hochladen?

Sie haben keinen Root Zugang, sie ändern nur alles aus dem Internet und nur auf einer bestimmten Seite auf dem Server.
Das geht nun schon eine Woche so, anfangs haben sie nur weiterleitungen zu der Seite eingebaut, aber jetzt wirds richtig schlimm.

Kann ich irgendwie die Rechte für die Seite so ändern das dort nichts mehr geändert werden kann was einmal so ist?

Ich brauche einen Lösungs Vorschlag.
Nur neu installieren wird da nichts bringen.

[Roger Wilco]

Aber wie können diese Hacker Dateien auf dem Server ändern oder hochladen?

Stichwort Remote Command Execution/Remote File Inclusion. Die Einstellung register_globals=on zusammen mit anderen Einstellungen in deiner php.ini bieten dafür schonmal gute Voraussetzungen. Dazu noch alte und/oder anfällige Skripte und schon ist es gar kein Problem mehr, deine Kiste zu kompromittieren.

Ich brauche einen Lösungs Vorschlag.

`/etc/init.d/apache2 stop`.

Ansonsten vllt. zur Linderung der Symptome mod_security und Suhosin. Die Ursache (unsichere Skripte) solltest du aber primär beheben.

[daemotron]

Darüber hinaus - ja, Webanwendungen sind zur Zeit der häufigste Angriffspfad. Aber dass die Webseiten verändert wurden, muss ja nicht heißen, dass der Angreifer auch da reingekommen ist. Angriffe über andere Dienste wie sshd sind zwar selten (und vor allem selten erfolgreich), aber selten bedeutet halt nicht "nie".

Dass die Website die augenfälligsten Veränderungen zeigt, deutet aber stark darauf hin, dass der oder die Bösewichte da auch reingekommen sind und (bis jetzt) vielleicht "nur" über eine Remote Shell verfügen, die im Benutzerkontext des Webservers läuft. Aber weiß der Himmel was die mittlerweile sonst noch verändert haben...

Btw. hab grade beim Googlen was brauchbares gefunden. Findest Du bei Dir irgendwo eine Datei "log.php", die Du nicht dort abgelegt hast, wo sie jetzt liegt? Diese könnte eine c99-Shell enthalten (dann entspräche der Angriff auf Dein System einem Muster, das auch hier beschrieben wird)

[gooof]

nicht log.php aber 404.php.

mod_security kann ich leider auf Etch nicht finden, ich mache folgendes aber es kommt dieser Fehler:

Code: Select all

dpkg -i mod-security2-common_2.1.1-0_all.deb
Selecting previously deselected package mod-security2-common.
(Reading database ... 21878 files and directories currently installed.)
Unpacking mod-security2-common (from mod-security2-common_2.1.1-0_all.deb) ...
dpkg: dependency problems prevent configuration of mod-security2-common:
 mod-security2-common depends on libapache-mod-security2 (>= 2.1.1-0) | libapache2-mod-security2 (>= 2.1.1-0); however:
  Package libapache-mod-security2 is not installed.
  Package libapache2-mod-security2 is not configured yet.
dpkg: error processing mod-security2-common (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 mod-security2-common

Genau das gleiche Problem in dem Forum dort habe ich auch, es ist komplett gleich, evtl. auch der gleiche Hacker.
Aber leider steht dort keinerlei Lösung, bitte helft mir, auch gerne per PN oder gegen Geld. :oops:

Also muss register_globals auf OFF? Unbedingt oder hat das damit nichts zu tun?
Ob SafeMode auf OFF oder ON ist aber glaube ich egal bei sowas oder?

[sledge0303]

Lies doch mal die Beiträge genau durch. Die Lücke befindet sich in anfälligen PHP Skripten oder ungepatchter Forensoftware.
Kiste im Rescue hoch, alle Logs sichern und diese analysieren - sofern der Angreifer diese nicht schon verändert hat. Kiste neu installieren.
Danach deine gesamten Skripte auf Sicherheitslücken prüfen, nachsehen ob es für deine verwendete Forensoftware ein neues Sicherheitspatch gibt, dieses ggf einspielen und danach erst wieder online gehen. Sonst hast das Problem in ein paar Tagen wieder.

register_globals auf on, darüber zeigt sich der Angreifer meist erfreut.

[gooof]

Die Software / Scripte sind alle auf dem neusten Stand.

Aber wonach muss ich suchen?
Also worüber könnte jemand eine PHP Datei auf den Server laden? Das einzige was zugelassen wird sind GIF, JPG und PNG Bilder. Und es wird auch geprüft ob es Bilder sind oder nicht.

Ich habe nun per php.ini das lesen von Verzeichnissen verboten.
Das schreiben kann ich leider nicht verhindern, da für neue User ein Ordner erstellt werden muss und auch eine Datei.

Gibt es evtl. eine Möglichkeit wie ich einer bestimmten Datei erlauben darf Dateien zu bearbeiten und allen anderen das nicht erlauben?
Natürlich irgendwie per php.ini.

[timeless2]

über das Änderungsdatum der Datei und deinen Logfiles kannst versuchen herauszufinden, über welchen Dienst bzw. welches Skript diese Änderung verursacht wurde.

[niko86]

Ob SafeMode auf OFF oder ON ist aber glaube ich egal bei sowas oder?

Wenn safe_mode aktiviert ist, überprüft PHP, ob der Eigentümer des laufenden Skriptes dem Eigentümer der Datei entspricht, an der mit Hilfe der Dateifunktionen gearbeitet werden soll. Beispiel:

http://de.php.net/features.safe-mode

schonmal ein schritt in die richtige richtung, sofern auf die dateiberechtigungen und eigentümer geachtet wurde.

[gooof]

über das Änderungsdatum der Datei und deinen Logfiles kannst versuchen herauszufinden, über welchen Dienst bzw. welches Skript diese Änderung verursacht wurde.

Logfiles ja, Änderungsdatum nein.
Denn die eine Datei war vom 2.7.07 aber da war noch kein Angriff und auch diese Datei nicht da.

Ich habe jetzt in der php.ini fast alle wichtigen Funktionen deaktiviert, jetzt geht der Adminbereich nicht mehr und die Anmeldung. Das kann aber nicht so bleiben.

Es ist jetzt auch erstmal ruhe... jetzt kommen gerade die dDos Attacken was die Server aber noch schaffen.

Jetzt also meine WICHTIGSTE Frage, kann ich einzelnen Dateien Funktionen wie "fwrite" und "readdir" jetzt für eine ganz bestimmte Datei freigeben?

[daemotron]

Das kannst Du für den Kontext eines virtuellen Hosts machen, aber nicht für eine einzelne Datei. Bei mod_php sind es die php_admin_value-Direktiven in der Apache-Konfiguration, bei FastCGI kannst Du im Wrapper einen Kontext-Pfad angeben, in dem die zu verwendende php.ini gesucht wird.

//EDIT//
Du solltest gelegentlich vielleicht mal Dein WordPress 1.5.2 auf einen aktuelleren Stand bringen - als Legacy branch wird nur noch 2.0.x mit Security Fixes versorgt. Und wie viele WP davon ständig nötig hat, ist ja ein offenes Geheimnis...

[gooof]

Nein es geht nicht um gooof.de
Eher um phpbb6.de mit phpbb 2.0.22 + Cracker Tracker!

Kann ich vielleicht mit .htaccess irgendwie einem Verzeichnis bestimmte Funktionen verweigern?

Ich brauche unbedingt das fwrite und readdir, aber das Shell Script arbeitet auch mit diesen, daher will ich gleich das z.B. alle Upload Verzeichnisse diese Funktionen deaktiviert haben.

Entweder per .htaccess oder eben der Apache Config. Da ich sowas noch nie hatte bin ich gerade etwas überfordert.
Das mit dem php_admin_value mache ich gleich (es sind dort nur 2 Seiten drauf, auf der einen können diese ruhig aktiviert sein), aber ich brauche ja die Funktionen...
kann ich das nicht irgendwie hinkriegen selbst wenn ich jeder Datei irgendwo hinschreiben muss mit den bestimmten Rechten?

FastCGI mag ich nicht so gern.
zum Safe_Mode: safe_mode ist etwas an, also es ist OFF aber viele Funktionen die dort deaktiviert sind, sind auch bei mir deaktviert, wie z.B. exec, system usw.
Ob er nun prüft wem die Datei gehört oder nicht ist ja egal, wenn er schon eine PHP Datei hochladen kann sind die Gruppen Rechte ja das kleinste Problem.

DANKE schonmal, wirklich gute Hilfe hier!

[rootsvr]

So wie die phpbb Module in der Vergangenheit gepflegt wurden machen Aussagen wie "200 mods" eher Angst.

Auch wenn es nicht um gooof.de geht.. 1.52 als wordpress Version solltest Du auch da beheben, sonst hast Du nachher zwei gehackte Server.

Ich glaube bei Dir herrscht das Sicherheit vs. Komfort Dilemma. Manchmal muß man existierende Funktionen neu planen um sie in sein Sicherheitskonzept zu packen, was Du jetzt genau haben willst ist mir aber eh noch nicht ganz klar.

FastCGI mah ich nicht ist als Aussage nicht wirklich sinnvoll, wobei ich mir bei deiner Seite eh nicht vorstellen kann wie man dort sinnvoll fastcgi nutzen kann. ggf kannst Du mit Modsecurity oder suhosin die Sicherheit verbessern, aber "sicher" wird das in deinem gewünschten Setup wohl eh nicht gehen..

[gooof]

Da alle Mods immer auf dem aktuellen Stand sind und eigentlich alles gefiltert wird finde ich das nicht.

Wenn ich jetzt irgendwie diese beiden Funktionen rausnehmen kann (und dann noch einige mehr), ist es auf jeden Fall sehr viel sicherer als vorher.
das ganze dient dazu, falls es doch noch mal jemand schaffen sollte eine Shell Datei hochzuladen, dann kann er so nichts mehr ändern und auch keine Verzeichnise auslesen bzw. Dateien überhaupt angucken oder sonstiges weil von PHP alles geblockt wird.

[rootsvr]

Die meisten (?) Angriffe passieren/werden möglich durch register_globals und dann remote file inclusion, das hat ne Zeitlang jede Menge phpbb mods und joomla plugins gegeben, ob die anderen Sicher sind oder nur niemand geschaut hat weiß ich nicht.

Ob Du jetzt mit deinem zwei Funktionen sicher oder unsicher bist kommt immer darauf an wie Du die benutzt. Auch eigene Software kann ganz schnell unsicher sein (hab ich selbst erlebt *schäm*) wenn man nicht aufpasst.

[Joe User]

Eher um phpbb6.de mit phpbb 2.0.22 + Cracker Tracker!

Schmeiss den "Cracker Tracker" weg, das Ding ist löchrig wie ein Schweizer Käse. Desweiteren schmeisst Du alle nicht zwingend benötigte und alle nicht unter http://www.phpbb.com/community/viewforum.php?f=15 verfügbaren phpBB2-Mods weg. Die restlichen Mods bringst Du auf den aktuellen Stand, danach sehen wir weiter...

[gooof]

ok :(
Aber ist es nicht so das Dateien nur über Upload Felder kommen können?

Ich kann mir nämlich nicht vorstellen das es jemanden gelingt über dieses Schreibfeld eine Datei auf den Server zu laden.
Wenn das so wäre brauche ich nur alle Upload Mods zu entfernen oder umzuprogrammieren.

Ich hab es jetzt erstmal so gemacht das fast alle Dateien den Benutzer root haben, so können Dateien nicht mehr geändert werden.
Wie es aussieht kann ich aber Funktionen wie readdir oder fwrite nicht einzelnen Dateien zur Verfügung stellen. (das wäre eine super Idee für eine neue PHP Version, da man so viel sicherer bei großen Projekten fährt, auch wenn es sehr umständlich ist da dann alles einzustellen)

Den Cracker Tracker habe ich jetzt so erweitert das sowas eigentlich nicht nochmal passieren kann. Dieser sichert ja sozusagen alle Mods ab die installiert sind. Ob der jetzt selbst Löcher hat oder nicht naja alles hat irgendwo ein Loch. :lol:

Ich kenne mich noch nicht so mit Angriffen aus, ich würde aber gerne wissen worüber man so was hinkriegt kann und z.B. eine Datei auf den Server laden kann wenn man weiß in welches Verzeichnis. Denn nur so kann ich richtigen Schutz aufbauen.

Register_Globals auf OFF ist unmöglich, ich hatte das vorgestern getestet. Trotzdem wurde einiges jetzt umgeändert sodass nun mehr geprüft wird ob z.B. Sonderzeichen in der Variable verwendet werden die ausgelesen wird. Meint ihr das reicht erstmal alles?
Bis jetzt hab ich nämlich noch keinen weiteren Angriff gehabt. Und der Cracker Tracker blockt auch viel mehr als vorher.

[duergner]

Register_Globals auf OFF ist unmöglich, ich hatte das vorgestern getestet.

Als ernstgemeinter guter Rat: Software die immer noch register_globals = on braucht will man sicherlich nicht mehr verwenden, da der Entwickler entweder die Problematik nicht verstanden hat, und dann wuerde ich ich der Software die er entwickelt sicherlich nicht vertrauen in Punkto Sicherheit, oder er hat das Problem zwar verstanden, ist aber zu faul/unfaehig/was auch immer, seine Software entsprechend umzuschreiben und auch dann will man seine Software nichtverweden aus genau dem gleichen Grund.

Trotzdem wurde einiges jetzt umgeändert sodass nun mehr geprüft wird ob z.B. Sonderzeichen in der Variable verwendet werden die ausgelesen wird. Meint ihr das reicht erstmal alles?

Wenn du noch nicht verstanden hast, wie diese Angriffe aussehen, wie willst du dann entsprechenden Gegenmassnahmen vornehmen koennen?

[Joe User]

Den Cracker Tracker habe ich jetzt so erweitert das sowas eigentlich nicht nochmal passieren kann.

Nicht nur mir sind seit ~2 Jahren mindestens drei Möglichkeiten bekannt den Cracker Tracker zu umgehen. Aber der Möchtegern-Programmierer ignoriert diese Lücken bis heute, obwohl ihm mehrere Patche für diese Lücken von unterschiedlichen Personen zugegangen sind. Egal, wenn Du dieser trügerischen Sicherheit weiterhin vertrauen willst, dann mache das, ich habe genug zu diesem Thema geschrieben.

Dieser sichert ja sozusagen alle Mods ab die installiert sind.

Genau das tut er nämlich nicht...

[gooof]

hmm... naja ich bin kein guter Hacker. :)

Habt ihr evtl. Links die mir helfen können die Lücken zu finden (auch gerne per PN)?

Und jedes Feld in dem man etwas schreiben kann ist gefährlich?
Egal was dieses macht?
Oder so wieso jede Datei wenn register_globals ON ist?
:roll:

also register_globals stelle ich heute Nacht auf off und prüfe jede Datei, ist denn wenigstens der Posting Bereich von phpBB sicher?

[Joe User]

phpBB2-2.0.22 ohne Mods ist momentan sicher, viele Mods allerdings nicht.

Was register_globals angeht: Dies betrifft nicht nur formularverarbeitende PHP-Dateien...

[apr]

Und jedes Feld in dem man etwas schreiben kann ist gefährlich?
Egal was dieses macht?
Oder so wieso jede Datei wenn register_globals ON ist?
:roll:

Du weißt was register_globals macht?

Nicht jede Datei ist zwangsläufig gefährdet, weil register_global an ist. Kritisch ist das letztlich nur bei einigen Server und, noch wichtiger, Session Variablen. Da mit register_global nicht mehr bekannt ist, woher der Inhalt kommt. Ein kurzer Bsp.:

Code: Select all

// mit super globals
if (isset ($_SESSION['logged_in']) && $_SESSION['logged_in']) {
  echo "some really secret data ...";
}

Code: Select all

// ohne super globals
if (isset ($logged_in) && $logged_in) {
  echo "some really secret data ...";
}

Siehst du das Problem jetzt? Im ersten wird meinetwegen das Passwort in einer anderen Datei überprüft und dann in einer Session gespeichert, dass der Benutzer angemeldet ist. Jetzt ist im zweiten Beispiel nicht bekannt vorher die Infos kommen, sprich es könnte auch einfach per http://www.server.tld/script.php?logged_in=true aufgerufen werden und der Schutz wäre ausgehebelt. Das dürfte zwar so konkret bei dir nicht der Fall sein, aber es zeigt hoffentlich warum, man es nicht benutzen sollte. Bei dir dürfte eher sowas im Quelltext stehen (wieder nur Beispiele ;-)):

Code: Select all

// ...
eval ('echo "blub bla" . ($_GET['var']) . " noch mehr text";');
include ('includes/page_' . $_GET['page_num'] . '.inc.php');
exec ('imagemagick ...' . $_GET['file_name']);
// ...

Was ich damit sagen will ist eigentlich nur, dass potenziell alle Scripte die Eingabedaten von Benutzer bekommen evtl. missbraucht werden könnten. Es hat nicht so sehr mit den Feldern zu tun, mehr mit den Scripten die das dann entgegen nehmen (und das dürften wohl die meisten sein.). In denen kommt es maßgeblich darauf an, dass der Programmierer da keinen Mist produziert. Zwar kann man gewisserweiße Gegensteuern, aber Hauptverantwortung liegt da mehr beim Programmierer.

[Joe User]

Das dürfte zwar so konkret bei dir nicht der Fall sein,

Zumindest nicht bei phpBB2-Vanilla, Auszug common.php:

Code: Select all

// The following code (unsetting globals)
// Thanks to Matt Kavanagh and Stefan Esser for providing feedback as well as patch files

// PHP5 with register_long_arrays off?
if (@phpversion() >= '5.0.0' && (!@ini_get('register_long_arrays') || @ini_get('register_long_arrays') == '0' || strtolower(@ini_get('register_long_arrays')) == 'off'))
{
  $HTTP_POST_VARS = $_POST;
  $HTTP_GET_VARS = $_GET;
  $HTTP_SERVER_VARS = $_SERVER;
  $HTTP_COOKIE_VARS = $_COOKIE;
  $HTTP_ENV_VARS = $_ENV;
  $HTTP_POST_FILES = $_FILES;

  // _SESSION is the only superglobal which is conditionally set
  if (isset($_SESSION))
  {
    $HTTP_SESSION_VARS = $_SESSION;
  }
}

// Protect against GLOBALS tricks
if (isset($HTTP_POST_VARS['GLOBALS']) || isset($HTTP_POST_FILES['GLOBALS']) || isset($HTTP_GET_VARS['GLOBALS']) || isset($HTTP_COOKIE_VARS['GLOBALS']))
{
  die("Hacking attempt");
}

// Protect against HTTP_SESSION_VARS tricks
if (isset($HTTP_SESSION_VARS) && !is_array($HTTP_SESSION_VARS))
{
  die("Hacking attempt");
}

if (@ini_get('register_globals') == '1' || strtolower(@ini_get('register_globals')) == 'on')
{
  // PHP4+ path
  $not_unset = array('HTTP_GET_VARS', 'HTTP_POST_VARS', 'HTTP_COOKIE_VARS', 'HTTP_SERVER_VARS', 'HTTP_SESSION_VARS', 'HTTP_ENV_VARS', 'HTTP_POST_FILES', 'phpEx', 'phpbb_root_path');

  // Not only will array_merge give a warning if a parameter
  // is not an array, it will actually fail. So we check if
  // HTTP_SESSION_VARS has been initialised.
  if (!isset($HTTP_SESSION_VARS) || !is_array($HTTP_SESSION_VARS))
  {
    $HTTP_SESSION_VARS = array();
  }

  // Merge all into one extremely huge array; unset
  // this later
  $input = array_merge($HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_COOKIE_VARS, $HTTP_SERVER_VARS, $HTTP_SESSION_VARS, $HTTP_ENV_VARS, $HTTP_POST_FILES);

  unset($input['input']);
  unset($input['not_unset']);

  while (list($var,) = @each($input))
  {
    if (in_array($var, $not_unset))
    {
      die('Hacking attempt!');
    }
    unset($$var);
  }

  unset($input);
}

//
// addslashes to vars if magic_quotes_gpc is off
// this is a security precaution to prevent someone
// trying to break out of a SQL statement.
//
if( !get_magic_quotes_gpc() )
{
  if( is_array($HTTP_GET_VARS) )
  {
    while( list($k, $v) = each($HTTP_GET_VARS) )
    {
      if( is_array($HTTP_GET_VARS[$k]) )
      {
        while( list($k2, $v2) = each($HTTP_GET_VARS[$k]) )
        {
          $HTTP_GET_VARS[$k][$k2] = addslashes($v2);
        }
        @reset($HTTP_GET_VARS[$k]);
      }
      else
      {
        $HTTP_GET_VARS[$k] = addslashes($v);
      }
    }
    @reset($HTTP_GET_VARS);
  }

  if( is_array($HTTP_POST_VARS) )
  {
    while( list($k, $v) = each($HTTP_POST_VARS) )
    {
      if( is_array($HTTP_POST_VARS[$k]) )
      {
        while( list($k2, $v2) = each($HTTP_POST_VARS[$k]) )
        {
          $HTTP_POST_VARS[$k][$k2] = addslashes($v2);
        }
        @reset($HTTP_POST_VARS[$k]);
      }
      else
      {
        $HTTP_POST_VARS[$k] = addslashes($v);
      }
    }
    @reset($HTTP_POST_VARS);
  }

  if( is_array($HTTP_COOKIE_VARS) )
  {
    while( list($k, $v) = each($HTTP_COOKIE_VARS) )
    {
      if( is_array($HTTP_COOKIE_VARS[$k]) )
      {
        while( list($k2, $v2) = each($HTTP_COOKIE_VARS[$k]) )
        {
          $HTTP_COOKIE_VARS[$k][$k2] = addslashes($v2);
        }
        @reset($HTTP_COOKIE_VARS[$k]);
      }
      else
      {
        $HTTP_COOKIE_VARS[$k] = addslashes($v);
      }
    }
    @reset($HTTP_COOKIE_VARS);
  }
}

Ein paar Mods schaffen es aber diese Funktionen auszuhebeln :(

[gooof]

Ah ja, naja gut, ich versuche alles ohne register_globals hinzukriegen wird aber viel Arbeit. (ich hatte da anfangs vor 2 Jahren nicht dran gedacht)

Klar ist auf jeden Fall das auf der Seite fast nichts wichtiges über GET oder POST übergegeben wird. Erst recht keine exec oder Mysql Daten. (aber das muss es ja auch nicht wenn register_globals aktiv ist, so könnte man ja alles bearbeiten wenn es nicht im Script nachträglich überschrieben wird... also das muss wohl OFF)

Die Mods wurden auch einzeln eingebaut also keine dieser fertig Dinger, daher sind alle bis auf ca. 2 auf der derzeit aktuellen Version.

Aber wie ist es denn jetzt möglich (also mit welcher PHP Funktion) eine PHP-Shell Datei hochzuladen wenn nur Bilder zugelassen werden?
Mit einem normalen Input Feld kann es ja schlecht gehen...
Ich denke da stark an fwrite... oder liege ich da wieder falsch? (dann würde ich nämlich direkt danach suchen)

Und an das normale Hacken in der URL also mit register_globals hab ich eigentlich immer gedacht. So schlau war ich dann doch... :twisted: