Unbefugter Zugriff auf die Datenbank

A

Atranox

New Member
Hallo,

ich habe ein Problem.
Jemand hat von außen Zugriff auf meine Datenbank.
Leider weiss ich nicht genau wie. Aus diesem Grund habe ich einfach das Dedizierte Server Forum gewählt.

Folgendes:
Es fing vor ein paar Tagen damit an, das ein Benutzer in der Datenbank für sich bestimmte Werte geändert hat. Ich bin erst von einer MySQLi ausgegangen. Diese schließe ich aber aus (dazu gleich mehr).

Ich habe daraufhin (weil es mal eine MySQLi Lücke gab), den Datenbank namen und den Benutzer, sowie das Passwort geändert.

Heute sah ich folgendes in der Log:
Code: 
                28089359 Connect        ****@localhost on
                28089359 Query  select @@version_comment limit 1
                28089359 Query  drop database ****

Ein bisschen dumm, das der Benutzer **** Rechte zum droppen einer Tabelle hat, aber das Spiel jetzt auch keine Rolle mehr.
Es handelt sich auch nicht um den Benutzer root!
Brutforce kann ich auch ausschließen.

Ich habe einen Server mit Nginx laufen und habe die Access Log Datei geprüft.
Eigentlich fällt einem ja dann sowas ins Auge wie:

Code: 
http://domain.tld/bla.php?id='SELECT ***
Wenn es sich um eine MySQLi handelt.
Leider ist zu genau der Uhrzeit, von der der MySQL Eintrag stammt, nichts verzeichnet. Auch die error.log liefert mir nichts.

Was mich auch wundert ist, dass das Query direkt ausgeführt wurde, ohne das etwas anderes davor ausgeführt wurde.

1. Verbindung aufgebaut
2. Version abgefragt?!
3. Datenbank gelöscht.

Hätte der Benutzer sich über phpmyadmin eingeloggt, müsste man auch etwas in der art finden oder?

Könnte es einen Grund für die Versionsabfrage geben?
Vielleicht gibt es ein Tool, was genau dies macht? So das ich wüsste, wo der Benutzer angegriffen hat?
Meine Querys erzeugen das alle nicht und ich habe sonst keinen vergleichbaren Eintrag dazu gefunden!

Hat jemand einen Tipp, was ich noch versuchen könnte raus zu finden?
 
Last edited by a moderator:
Vielleicht hat da jemand auf einem dritten Wege eine Remote-Shell auf deinem Server installiert und kann sich einfach einloggen und loslegen?
 
hab ich auch schon überlegt, aber dann hätte er doch das Passwort und den Benutzer namen haben müssen.

Habe schon geguckt ob irgendwo eine auffällige datei ist.
Aber selbst ein Datenupload habe ich nicht aktiv.

Mich wundert wie gesagt, das es ein einzelner Befehl war ohne irgend ein query mit drin, was von meinen Scripten kommen könnte.

Hab sogar schon nach aktuellen exploits geschaut.
 
Atranox said:
aber dann hätte er doch das Passwort und den Benutzer namen haben müssen.
Click to expand...

Für eine Remote-Shell? Nein. Die läuft mindestens mit den Rechten des Prozesses, über den sie eingeschleußt wurde. Und das Passwort für die Datenbank steht sicher irgendwo in der Config deiner Web-Applikation.
 
ein Remote-Shell müsste aber irgendwie auf den Server kommen.
Und selbst dann hätte er mehr gemacht als nur deine Datenbank gelöscht.
Es existieren noch viel mehr auf dem Server!
 
Was läuft den alles an Diensten auf dem Server? Vielleicht ist ja irgendwas dabei wodrüber man eine Remote-Shell aufbauen kann.
 
ispconfig als standard installation und sonst eigentlich nichts weiter.
gibt es eine Möglichkeit, in Debian nach neu erstellten Dateien zu suchen?
 
Bin schon gespannt, wann Jemand die jüngsten Sicherheitslücken in MySQL erwähnt und nach den entsprechenden Updates fragt. Auf Grund der Fragestellungen des OP hätte ich das schon früher erwartet, aber gut, ich übe mich mal weiter in Geduld und warte auf den Glückstreffer des Glaskugel-Lotto.

Wer Ironie entdeckt, darf sie erwiedern...
 
Hat eigentlich auch schon mal einer an was naheliegendes gedacht: Eine SQL-Injection-Lücke in einem Script, welches auf dem Server läuft (z.B. CMS, Forum oder Gästebuch, um nur mal ein paar Möglichkeiten zu nennen). Das muß ja nicht unbedingt in den Apache-Logs zu sehen sein, wenn die Lücke per POST ausnutzbar ist.
 
Was soll RKhunter denn dazu auch sagen? Der sucht maximal nach bekannter Malware was zu zwei Problemen führt:

1) Scannt man von einem infizierten System aus, ist die Wahrscheinlichkeit hoch, dass RKhunter nur noch das zu sehen bekommt, was er sehen soll.

2) Das war eine Injection über eine Sicherheitslücke in einer der Webanwendungen. Das hat mit RKhunter dann gar nichts mehr zu tun, da es kein Scanner für bekannte Sicherheitslücken in Webanwendungen ist.
 
Marentis said:
2) Das war eine Injection über eine Sicherheitslücke in einer der Webanwendungen. Das hat mit RKhunter dann gar nichts mehr zu tun, da es kein Scanner für bekannte Sicherheitslücken in Webanwendungen ist.
Click to expand...

Und wie würde man der nun am besten auf die Spur kommen?
Ich habe jetzt statt Nginx wieder Apache mit modsecure laufen und hoffe,
das ich was aus den Log Dateien lesen kann wenn es noch mal passiert.
 
Und wie würde man der nun am besten auf die Spur kommen?
Click to expand...
Bekannte Dateien kannst du mit cxs + clamAv suchen, aber aufgrund der dynamischen Natur von PHP-Skripten kann er nicht zuverlässig alles erkennen.

Ich habe jetzt statt Nginx wieder Apache mit modsecure
Click to expand...
Ich nehme an du meinst mod_security
Dieses kann nur gegen Angriffe funktionieren die in der regex-Datenbank des Modules bekannt sind - sprich wenn der Angreifer es schafft eine Datei hoch zu laden und aus zu führen (zB über nicht validierte Avatar-Uploads) wird es nicht aktiv.

Was du nicht erwähnt hast, aber wichtig zu wissen wäre; kennst du diesen Mysql-Benutzer und hat er die Berechtigung zum droppen von dir?
Du solltest davon ausgehen dass dein PHP-Skript oder der Server infiziert sind.

Ein grep über den Datenbank-Benutzer KÖNNTE etwas zutage führen, aber vermutlich eher nicht.
 
alle dateien mit originalen überschreiben, backup ziehen, server formatieren. Server, nginx, software, php, mysql etc updaten.
mod_sec installieren
suhosin patch
anti sqli, xss, rfi/lfi php script installieren (ctxtra)
 
loreen said:
ctxtra
Click to expand...
Verteilt der [censored] sein Snakeoil etwa immernoch? Bitte von Allem wo CBACK draufsteht die Finger lassen, er hat keine Ahnung von dem was er da zusammenfrickelt.

Nein, ich werde nicht in die Details gehen, das haben neben mir etliche Andere schon vor Jahren ausreichend getan.
 
Statische Skripte wie Crackertracker und Ableger brauchen nur viel Leistung ohne wirklich nennenswert zu helfen. Dies ist ein Katz-und-Maus Spiel; wenn eine Seite die Latte erhöht muss die andere sie auch erhöhen.
Ein lokales Skript kann hier gar nicht ausreichend schützen, zumal nicht wenn es so simpel aufgebaut ist.
Selbst ausgefeilte Bayes-Filter in Spamassassin kann ohne viel Datentraning kaum Spam von Ham erkennen.

Was Angriffe angeht so ist definitiv Atomicorp's mod_security Regelliste zu empfehlen, diese funktioniert zuverlässig(er)
 
Das ctxtra war ja auch nur als Zusatz von mir gedacht. Alleine hilft es da nicht viel, das stimmt.
Falls die hacker richtige profis sind und über server/remote mysql, ftpd etc exploits verfügen, dann kann
da ein reverse proxy helfen, das ebenfalls abgesichert wurde.
Einzelne Prozesse sollten sich in einem jail befinden.
 
Last edited by a moderator:
Falls die hacker richtige profis sind und über server/remote mysql, ftpd etc exploits verfügen, dann kann
da ein reverse proxy helfen, das ebenfalls abgesichert wurde.
Click to expand...
Tools wie Metasploit decken die Funktionen ab. Wissen braucht man dazu nicht.

Einzelne Prozesse sollten sich in einem jail befinden.
Click to expand...
Viele Prozesse brauchen root-Rechte im Betrieb (zB zum SUID). Root kann aus einem Chroot ausbrechen.
 
You must log in or register to reply here.
Back
Top