MySQL - Sicherheit/Angriffsszenarien (Präsentation)

Naben miteinander,

und zwar bereite ich gerade eine Präsentation vor, die ich in dem Fach Datenbanken halten muss.
Der Name der Präsentation ist "Allgemeine Verbindungen in MySQL". Ich wollte noch ein paar sicherheitsrelevanten Punkte mit einbringen da das, die "Zuschauer" meistens weckt und den Lehrer etwas staunen lässt... Und ich mich selber dafür interessiere.

Die Gliederung der Präsentation ist folgende:
  • Verbindungen (TCP/IP, Local Socket, TCP/IP over SSH, Erweiterte Verbindungen SSL)
  • Sicherheit bezüglich der Verbindungen
  • (evtl. Angriffsszenarien)

Tia nun, zu dem Punkt Sicherheit und "Angriffsszenarien", gibt es überhaupt eine Möglichkeit die Benutzerdaten durch bsp. einen MITM angriff zu bekommen, oder gibt es andere Möglichkeiten? Ich habe mich jetzt schon etwas länger im Internet umgeschaut, aber es ist nichts interessantes dabei rausgekommen. Die Möglichkeiten die ich gefunden habe wären: social Engineering und MySQL-Injection.
Wenn das so wäre, dann kann ich die zwei letzten punkte getrost in den Müll schmeißen oder :rolleyes:?

Wenn ihr vielleicht noch ein paar Ideen habt, dann wäre es toll mir da einenAnhaltspunkt zu geben.

Viele Grüße und einen schönen Abend
Atrono
 
Wie angreifbar MySQL ist, hängt prinzipiell vom Aufbau des Netzwerks ab und von der Art des Clients. Seit einiger Zeit beherrscht MySQL z.B. verschlüsselte Verbindungen zwischen Server und Client, nur nutzen tun es noch die wenigsten. Ist also z.B. der Client nicht auf dem gleichen Rechner wie der Server, ist MITM durchaus ein denkbares Angriffsszenario. Auch Sicherheitslücken im MySQL-Server selbst können durchaus genutzt werden um z.B. Privilege Escalations u.ä. herbeizuführen. Dass MySQL nicht unbedingt die hammer-sichere Software ist, sieht man z.B. unter CVE - Search Results MySQL Das Jahr ist noch jung und dennoch gab es bereits über ein Dutzend Sicherheitsmeldungen.

Die Frage ist daher: In welchem Umfeld wird das MySQL-System eingesetzt? Gibt es z.B. Replikation oder gar NDB-Cluster in dem Umfeld? Welche Feature der MySQL werden genutzt? Welche Tabellentypen? Wird immer die aktuellste Version eingesetzt? usw.
 
Hey Bitmuncher,

danke für deine Antwort. Ich habe eine Testumgebung, wo eine Client <-> Server Verbindung besteht die mittels TCP/IP hergestellt ist (Benutzeracc & Passwort).

Ich frage mich im endeffekt wie einfach es ist die Benutzerdaten aus so einem Szenario zu bekommen. Wenn es für einen Angehenden CCNA`ler zu schwierig sein sollte, können wir das Thema schließen. Aber wenn es für den "Ottonormalverbaucher" mit etwas einlesen möglich sein sollte so etwas zu tun, dann wäre es toll wenn du mir Anhaltspunkte geben könntest.

Atrono
 
Wenn die TCP-Verbindung nicht verschlüsselt ist, dann lass einfach mal ein Packet-Sniffer auf dem entsprechenden Netzwerk-Device mitlaufen. Aber Vorsicht: Greift man auf eine MySQL über 'localhost' zu, wird immer der lokale Socket verwendet und nichts läuft über TCP. Will man auch auf einer lokalen Testumgebung TCP erzwingen, muss man die IP verwenden, also 127.0.0.1.
 
Guten Morgen,

ich habe nun Wireshark benutzt um an die Pakete von MySQL zu gelangen. Des weiteren habe ich dann folgenden Filter=mysql.passwd angewandt um mir die genauen Pakete anzeigen zu lassen.

Anhang anzeigen 3940

Nun der Login Request des MySQL Protocol's verrät nun schonmal den Benutzer Namen. Aber wie ist nun das Passwort verschlüsselt? Das Passwort lautet "root12", hat vllt. jemand eine Ahnung wie man das Passwort nun entschlüsseln kann? :)

Ich hab das Passwort(d4b9db6ba94d759856856b18090691b8bbc194bf) schon durch einen Hash-Cracker laufen lassen, aber der bringt mir einen Fehler. Ich weis ja noch nichtmal wie das Passwort aufgebaut ist... :(
 
Zuletzt bearbeitet:
Nun der Login Request des MySQL Protocol's verrät nun schonmal den Benutzer Namen. Aber wie ist nun das Passwort verschlüsselt? Das Passwort lautet "root12", hat vllt. jemand eine Ahnung wie man das Passwort nun entschlüsseln kann? :)

Ich hab das Passwort(d4b9db6ba94d759856856b18090691b8bbc194bf) schon durch einen Hash-Cracker laufen lassen, aber der bringt mir einen Fehler. Ich weis ja noch nichtmal wie das Passwort aufgebaut ist... :(

Bei der initialen Verbindung sendet der MySQL Server einen "salt". Der Client "baut" daraus das Passwort, dass er an den Server sendet.

Code:
sha_pass1 = SHA1(password);
sha_pass2 = SHA1(sha_pass1);
sha_pass3 = SHA1(salt + sha_pass2);

l = strlen(sha_pass3);

for (i=0; i<l; i++) {
  pass += raw_string(ord(sha_pass1[i]) ^ ord(sha_pass3[i]));
}
 
dieser authentifizierungs mechanismus wurde mit mysql 4.1 eingeführt

das was du da siehst ist ein challange response mechanismus, der das eigentliche passwort nicht überträgt

es passiert folgendes ...

im ersten paket vom server nach dem tcp handshake wird vom server ein wert an den client übermittelt der die challange beinhaltet ... das ist eine nonce ... ein zufallswert ... ein salt ... intern heißt das ding bei den mysql leuten scramble

nun geht der client hin und berechnet folgendes:

hash_stage1 := sha1('root12')
hash_stage2 := sha1(hash_stage1);
token := sha1(scramble || hash_stage2) XOR hash_stage1

|| steht hier für concatination, und es werden wohlgemerkt bytes concatiniert, keine strings ... sha1 wird auch wenn der parameter hier nicht in '' steht mit bytes und nicht mit strings gefüttert...

diesen token wird nun an den server gesendet, und er ist das, was du im mitgeschnittenen datenstrom siehst

der server kennt den wert für scramble, und den hash_stage2 hat er in der user tabelle in der spalte password stehen

er kann also nun seinerseits berechnen:

challange_candidate = sha1(scramble || hash_stage2) XOR token

challange_candidate2 = sha1(challange_candidate)

wenn nun challange_candidate2 mit dem gespeicherten wert in der passwort spalte überein stimmt, wird das als gültiger login angesehen ...

das system wird angreifbar wenn man als angreifer in den besitz des hash_stage1 gelangt ...

ein weg dahin wäre, den wert hash_stage2 aus der user tabelle in erfahrung zu bringen, und einen challange response login mitzuschneiden ...

man kann dann wie der server hingehen, und aus dem token den hash_stage1 extrahieren ... solange das passwort nicht geändert wird, kann man sich dann damit authentifizieren ...
 
Hey GrafZahl,
Hey bitmuncher,

ich wollte mich noch für eure Beiträge bedanken!
Das ist zwar jetzt schon ein paar Jahre her, aber die eins habe ich mir in der Präsentation gesichert.
Inzwischen bin ich seit knapp 4 Jahren auch im EDV-Bereich tätig.

Gruß
Atrono
 
Zurück
Oben