Hacker veröffentlicht Exploits für MySQL und SSH

News

News

Member
Der berüchtigte Hacker mit dem Pseudonym KingCope hat offenbar seine Altbestände ausgemistet und zum ersten Advent eine ganze Reihe von Exploits veröffentlicht, die zum Teil schon aus dem Jahr 2011 stammen. Primäres Ziel ist die mittlerweile von Oracle übernommene Open-Source-Datenbank MySQL; aber auch die SSH-Server der Firma SSH und FreeSSHd/FreeFTPd sind akut gefährdet.

Kompletter Artikel.
Quelle heise online
 
JaEgErmEistEr said:
Jetzt macht es sich bezahlbar den SSH Dienst komplett deaktiviert zu haben und über VNC zu agieren :cool:
Click to expand...

Es geht nicht um eine Lücke im SSH-Protokoll, was etwa den wohl hier meistens genutzten OpenSSH-Server betrifft. Vielmehr geht es um Implementierungsfehler in den zwei SSH-Servern FreeSSHd und Tectia.
 
Bevor noch jemand einen Herzkasper kriegt: Betroffen ist das (mir fast nur im Windows- und Embedded-Umfeld bekannte) FreeSSH und die Software von SSH Inc., nicht aber das im Linux/BSD-Umfeld fast ausschließlich eingesetzte OpensSSH.
Die MySQL-Lücken setzen Zugriff auf Port 3306 voraus, etwas was man im Server-Umfeld außer Localhost eh niemandem gibt.
 
Whistler said:
Die MySQL-Lücken setzen Zugriff auf Port 3306 voraus, etwas was man im Server-Umfeld außer Localhost eh niemandem gibt.
Click to expand...
Die Bugs sind sowohl per TCP/IP als auch per Socket ausnutzbar und gerade der lokale Angriff ist ein Problem, da dadurch jeder MySQL-Client (insbesondere WebApps) zum Angriff genutzt werden kann.
Es ist also jede ungepatchte MySQL-Installation betroffen.

Nur weil die PoCs TCP/IP nutzen, schliesst das Sockets nicht aus.
 
Einer der "Bugs" ist laut MariaDB-Entwickler gar keiner sondern ein dokumentiertes Verhalten von Mysql:
http://www.gossamer-threads.com/lists/fulldisc/full-disclosure/88375#88375

Die MySQL-Lücken setzen Zugriff auf Port 3306 voraus, etwas was man im Server-Umfeld außer Localhost eh niemandem gibt.
Click to expand...
Im Webspace-Umfeld ist das Erlauben externer Verbindungen mehr oder weniger Standard.
Es gibt Anbieter die das nicht erlauben, geichzeitig gibt es auch Anbieter die bei PHP noch mit dem www-data Problem kämpfen: nicht mehr zeitgemäss
Aber die Joe User schon hinwies; nur weil 3306 zugemauert und verriegelt ist sind die Probleme nicht weg.
Die Probleme kannste nur entweder über einen filternen Mysql-Proxy oder ein Patch (noch nicht für alle Lücken vorhanden) blockieren.
 
MariaDB und Percona haben noch nicht alle Bugs gefixt und Oracle äussert sich bisher gar nicht dazu.

Zu dem dokumentierten Feature: Ja, strenggenommen kein Bug da dokumentiert, aber da dies zumindest in der Windows-Version wohl OOTB aktiviert sein soll, könnte man es auch als Bug deklarieren.
Ist aber egal, denn die anderen Bugs sind schwer genug, so dass Oracle umgehend ein Bugfix-Release einschieben muss.
 
Um an die Accountdaten vom WebApp-User zu kommen benötigen aber alle Exploits ein File Privilege für diesen User, oder?
 
Hallo!

Mal für Leute, die nicht täglich CVE's lesen:
  • Was muss ein Angreifer mit der Web Applikation anstellen, damit die Lücke ausgenutzt werden kann?
  • Muss diese Web Applikation zusätzlich eine Lücke aufweisen, oder lässt sich dies auch im Normalbetrieb ausnutzen?
  • Wie aktiviere ich im MySQL das Feature 1 Benutzer pro Session?
  • In wie weit kann man eventuell die MySQL Benutzer Privilegien weiter einschränken, um die Situation zu entschärfen?
mfG
Thorsten
 
Das "FILE-Privileg" ist nur für einen der Bugs nötig, wobei es sich um das dokumentierte Feature handelt, wodurch es eigentlich kein Bug ist.


Zu http://seclists.org/fulldisclosure/2012/Dec/58

Der Angreifer muss nur die Möglichkeit bekommen, auf einen beliebiges MySQL-Account zuzugreifen.

Da die meisten WebApps Zugangsdaten für einen MySQL-Account in ihrer Konfiguration hinterlegt haben, genügt also der Zugriff auf diese Daten und zusätzlich die Möglichkeit eigene Befehle an MySQL zu übergeben. Letzteres kann zum Beispiel durch Einschleusen/Hochladen eines Scripts in irgendeiner WebApp (diese muss nichtmal Datenbankgesteuert sein) geschehen.

Es kann auch ein Shell-User per mysql-Client den Bug ausnutzen, oder per Crontab (bei vielen Admin-Panels für Kunden aktiv) und dort hinterlegtem Script.

Der angegriffene MySQL-Account benötigt für http://seclists.org/fulldisclosure/2012/Dec/58 das Recht change_user.

Das "ein Benutzer pro Session" bezieht sich darauf, dass MySQL für neu generierte Passworte innerhalb der selben Session immer den gleichen SALT verwendet, wodurch das knacken von weiteren Accounts erheblich vereinfacht wird.
Daher meine Empfehlung für jede Passwortänderung/erstellung eine neue Session zu starten. Es verhindert zwar nicht den erfolgreichen Angriff, verlangsamt ihn aber für den Angreifer spürbar.


Die anderen Bugs sind zwar auch gefährlich, aber obiger ist der für Angreifer interessanteste und am Einfachsten durchzuführende Angriff und es sind hierfür bereits die ersten primitiven Exploits im Umlauf.


Wie immer gilt: Die pösen Buben sind kreativ und die von mir genannten Einfallstore sind nicht alle.
 
Joe User said:
Der Angreifer muss nur die Möglichkeit bekommen, auf einen beliebiges MySQL-Account zuzugreifen.
Click to expand...

Dieses "nur" stellt in der Realität doch eine sehr hohe Hürde dar. Wer sein System sauber und sehr restriktiv konfiguriert hat, dem droht meiner Einschätzung nach keinerlei unmittelbare Gefahr von den aktuellen Exploits.
 
Bei wievielen Wohnzimmerprovidern wird Plesk für die Kunden bereitgestellt und dort Crontabs erlaubt?

Bei wievielen WebApps mit Upload-Möglichkeit ist noch immer das Einbetten von Scripts in Bildern/Videos möglich?

Bei wievielen WebApps existieren noch immer SQL-Injections?

Wieviele Anti-Spam/Anti-Virus-Produkte lassen sich noch immer durch Archive austricksen? Dazu ein dummes Webmailinterface oder sonstiger Zugriff aufs Maildir und fertig.


Mit ein klein wenig Phantasie fallen einem da an die hundert weitere Möglichkeiten ein.

Kombinationen verschiedener (Um)Wege sind gerade das Lustige in der Security.
 
Hallo!

Es würde in einem solchen Fall doch schon reichen, wenn ein Kunde Zugriff auf eine MySQL Datenbank hat, oder?

mfG
Thorsten
 
Hallo!
Package : mysql-5.1
Vulnerability : several
Problem type : remote
Debian-specific: no
CVE ID : CVE-2012-3150 CVE-2012-3158 CVE-2012-3160 CVE-2012-3163
CVE-2012-3166 CVE-2012-3167 CVE-2012-3173 CVE-2012-3177
CVE-2012-3180 CVE-2012-3197 CVE-2012-5611
Debian Bug : 690778 695001
Click to expand...
mfG
Thorsten
 
Joe User said:
Bei wievielen Wohnzimmerprovidern wird Plesk für die Kunden bereitgestellt und dort Crontabs erlaubt?

Bei wievielen WebApps mit Upload-Möglichkeit ist noch immer das Einbetten von Scripts in Bildern/Videos möglich?

Bei wievielen WebApps existieren noch immer SQL-Injections?

Wieviele Anti-Spam/Anti-Virus-Produkte lassen sich noch immer durch Archive austricksen? Dazu ein dummes Webmailinterface oder sonstiger Zugriff aufs Maildir und fertig.
Click to expand...

Ich gehe das ja etwas progressiver an. Genau aus diesem Grund sage ich, dass all dieser "Müll" auf einem ordentlich konfigurierten Server nichts zu suchen hat. Eine Ausnahme stellen Upload-Möglichkeiten dar, aber dafür gibt es Lösungen, die man als sicher bezeichnen kann.

Thorsten said:
Es würde in einem solchen Fall doch schon reichen, wenn ein Kunde Zugriff auf eine MySQL Datenbank hat, oder?
Click to expand...

Eben nicht. Es braucht dazu auch noch gewisse Rechte für diesen User, die du als Admin diesem User explizit gegeben hast. Bei mir hat keiner dieser User diese Rechte.

0-Day-Exploits sind eigentlich die einzige Gefahr, vor der man sich als Admin wirklich sorgen muss, weil effektiver Schutz dagegen nur sehr schwer möglich ist oder sehr viel kostet. Eine ordentliche und vor allem sehr restriktive Systemkonfiguration kann einen aber auch vor solchen Exploits schützen. Also muss man primär hier ansetzen.
 
@Thorsten
Debian hat nur einen dieser Bugs behoben: CVE-2012-5611
Die anderen Bugs sind dort also noch offen.
 
You must log in or register to reply here.
Back
Top