----- Advisory RFP9907 German Translation ----------- rfp.labs ----------- (translated by ThinkTank) Du, Deine Server, RDS und tausende Moechtegern-Angreifer ... wie bleibt die Web Site intakt... (Schutz vor RDS Angriffen) --------------------------------- rain forest puppy / rfp@wiretrip.net --- Inhaltsverzeichnis: - 1. Problem - 2. Loesungen - 3. Situationen - 4. msadc.pl detektieren - 5. Schlussfolgerungen - 6. Quellen -------------------------------------------------------------------------- Keine Zeit dies alles zu lesen ? Dann musst Du nur die folgende Datei loeschen: ?:\Programme\Gemeinsame Dateien\System\Msadc\msadcs.dll Schnelle und brutale RDS Deaktivierung. (Falls Du RDS benoetigst, siehe unten) -------------------------------------------------------------------------- ----[ 1. Problem .gov, .mil und sogar microsoft.com sind kuerzlich in die Haende von Website Blamierern gefallen. Wie sich herausstellt, allein basierend auf RDS. Zwar ist IIS sicherlich schon in der Standardinstallation ziemlich exponiert, aber Microsoft hat nicht nur einen, auch nicht zwei, sonderen *drei" verschiedene Patches herausgebracht, und zudem dieselben Ratschlaege mehrmals veroeffentlicht. Dennoch ist RDS problematisch. Daher ist ein wenig Training notwendig, zumal es ziemlich viele Geruechte und Spekulationen darueber gibt, was, wie gesichert werden kann. Da ich RDS untersucht und einige Schwachstellen beschrieben habe, moechte ich meine Resultate gerne bekanntmachen, um die RDS Problematik zu loesen. Das Hauptproblem ist, dass Jet 3.5 Aufrufe der VBA shell() Funktion erlaubt, so dass shell Befehle (dokumentiert in RFP9901: NT ODBC remote vulnerabilities, verfuegbar unter: http://www.wiretrip.net/rfp/p/doc.asp?id=3&iface=2 ) ausgefuehrt werden koennen. In der IIS-Standardinstallation wird MDAC 1.5 gleich mitinstalliert. Dies beinhaltet RDS, so dass WWW-Zugriffe auf ODBC-Komponenten moeglich werden. Speziell basiert dies auf der .DLL Datei im Verzeichnis /msdac/msadc.dll (dokumentiert in RFP9902: RDS/IIS vulnerability and exploit, verfuegbar unter: http://www.wiretrip.net/rfp/p/doc.asp?id=1&iface=2 ). Es ist also ein zweiteiliges Problem. Desweiteren enthalten die verschiedenen Beispielseiten verschiedener RDS SDK Installationen eine Beispielkomponente namens VbBusObj, mittels derer die von Microsoft empfohlenen Problemloesungen umgangen werden koennen (ebenfalls in RFP9902 dokumentiert). Wir werden alle diese Elemente addressieren. ----[ 2. Loesungen Das eigentliche Prolem ist, dass es zu viele Loesungen und zuviele verschiedene Anwendungsfaelle gibt. Ich werde versuchen, so viele wie moeglich zu beschreiben. Zur Vereinfachung habe ich alle wichtigen Programmdateien fuer i386 Systeme auf meine Webseite gespiegelt, falls www.microsoft.com haengt, etc... -Loesung #1: cmd.exe verschieben (ULG empfohlene Loesung) http://www.aviary-mag.com/News/Powerful_Exploit/ULG_Fix/ulg_fix.html Ich danke ULG fuer die Hilfe, aber diese Loesung hat ein Problem. Zwar ist die Verwendung von cmd.exe bzw. command.com in mdac.pl hart kodiert, aber ich moechte daraufhinweisen, dass CMD.EXE nicht Voraussetzung fuer diesen Angriff ist. Ich habe es rein aus Kompatibilitaetsgruenden verwenden. Falls Du mir nicht glaubst, kannst Du es gerne selbst versuchen. Editiere mdac.pl, so dass es nicht den 'cmd /c' String verwendet. Es ist immer noch moeglich jeden anderen ausfuehrbaren Befehlsnamen zu verwenden (z.B. 'rdisk'). Die einzige Einschraenkung ist, dass Befehle wie 'copy' und Funktionen wie Datei Umleitungen (' > datei.out') nicht mehr eingesetzt werden koennen, da diese lediglich durch cmd.exe zur Verfuegung gestellt werden. Zudem kommt das Verschieben von cmd.exe/command.com lediglich einem "Sicherheit durch Verdunkelung" Denken gleich. Falls der Hacker die neue Position herausfindet, kann es es immer noch einsetzen. Eine Anpassung der Zugriffsberechtigungen, so dass System keinen Zugriff mehr hat, fuehrt eider auch nicht zum Ziel, da auch andere Programme negativ beeinflusst werden koennen. Ich wuerde diese Loesung daher nur mit extremer Vorsicht einsetzen, zumal es andere Patches gibt. -Loesung #2: Upgrade von MDAC 1.5 nach 2.0 MDAC 2.0 ersetzt Jet 3.5 durch Jet 3.52. Diese Version ist jedoch immer noch angreifbar per VBA shell() Angriff (essentieller Bestandteil des Angriffs auf die RDS Schwachstelle) und RDS ist standardmaessig aktiv ! Ich nehme sogar an, dass RDS nach einer vorherigen Deinstallation nun wieder reinstalliert wird. Einige wichtige Dinge sind: * Standard Jet Engine wird zu Version 3.52 (immer noch angreifbar) * erlaubt "custom handler" Unterstuetzung (verhindert anonymen Zugriff auf RDS) * erstellt Microsoft.Jet.OLEDB.3.51* Anbieter Also ist diese Loesung in ihrer Standardform nicht optimal. Es ist zumindestens notwendig, die sog. "custom handler" Unterstuetzung zu aktivieren. Dabei handelt es sich einfach um einen Schluessel in der Systemdatenbank (Registry) im Zweig: HKEY_LOCAL_MACHINE\Software\Microsoft\DataFactory\HandlerInfo\ Schluesselname: HandlerRequired Wert: DWORD:1 (sicher) or 0 (unsicher) Es ist ratsam, den Wert auf 1 zu setzen. Dies wird auch durch "handsafe.exe/.reg" von Microsoft produziert. Das Programm ist ueber meine Website verfuegbar: http://www.wiretrip.net/rfp/bins/msadc/handsafe.exe Bei Ausfuehrung erstellt die Programm eine weiter Datei mit dem Namen handsafe.rem. Umbenennung in handsafe.reg und anschliessender Doppel- Klick importiert die Einstellungen in die Systemdatenbank. Waehrend dies vor einem RDS-Fernangriff schuetzt, ist das System immer noch nicht sicher vor anderen Formen eines ODBC-Angriffs, inkl. trojanischen Excel, Word und Access Dateien und anderen versteckten Angriffen. Daher ist diese Loesung nicht hinreichend sicher. Die Erstellung der Microsoft.Jet.OLEDB.3.51* Anbieter ist jedoch wichtig und ich werde spaeter noch darauf zurueckkommen. -Loesung #3: Upgrade von MDAC 1.5 zu (irgendeiner) 2.1 Variante MDAC 2.1 ersetzt Jet 3.5 durch die Jet 4.0 Einheit, die keine Schwachstelle aufweist. Allerdings treten hier, bedingt durch die Unterschiede zwischen 3.5 und 4.0, Kompatibilitaetsprobleme auf. Daher haben viele es vorgezogen kein Upgrade durchzufuehren. Ganz zu schweigen von den Stabilitaetsproblemen der fruehen 2.1 Varianten. Nota bene: * Standard Jet Einheit veraendert zu Version 4.0 (sicher vor Angriffen) * erlaubt "custom handler" Unterstuetzung (verhindert anonymen Zugriff auf RDS) Aber, "custom handler" ist standardmaessig deaktiviert, d.h. der oben beschriebene Wert des Systemdatenbank (Registry) Schluessels muss auf 1 gesetzt werden, entweder manuell via regedit/regedt32 oder per Programm (handsafe.exe/.reg). -Loesung #4: Upgrade von MDAC 1.5 zu 2.0 zu 2.1 Nun, als guter Administrator solltest Du Dein System auf dem neuesten Stand gehalten haben. Falls ja, dann hast Du die volle Upgrade-Route durchlaufen. Dieselben Probleme existieren wie wenn Du ein direktes Upgrade auf V 2.1 (s.o.) durchgefuehrt haettest - Du musst also immer noch den "HandlerRequired" Schluessel setzen. Zwar verwendet 2.1 standardmaessig die Jet 4.0 Einheit, die sicher vor diesem Angriff ist, da Du jedoch zuvor Version 2.0 installiert hast sind die Microsoft.Jet.OLEDB.3.51 Anbieter ebenfalls praesent. Dies bedeutet, dass alle Anwendungen (inkl. RDS) eine Zugriffsmoeglichkeit auf die alte (angreifbare) Jet 3.51 Einheit haben !! Daher sollten diese alten Anbieter entfernt werden. Eine Moeglichkeit, dies zu tun ist die folgenden Systemdatenbank-Eintraege zu entfernen: HKEY_CLASSES_ROOT\Microsoft.Jet.OLEDB.3.51 HKEY_CLASSES_ROOT\Microsoft.Jet.OLEDB.3.51Errors Aber Du bist dann immer noch mit den Kompatibilitaetsproblemen der 4.0 Einheit konfrontiert, also ist dies nicht die beste Loesung. -Loesung #5: Installiere JetCopkg.exe (MS99-030) JetCopkg.exe ist eine modifizierte Jet 3.5 Einheit, in der verschiedene Sicherheitsein- stellungen aktiv sind, was auch als "Sandkasten" Modus bezeichnet wird. Diese werden durch den folgenden Systemdatenbankschluessel kontrolliert. HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\3.5\engines\SandboxMode Folgende Werte sind moeglich: 0 deaktiviert 1 aktiviert fuer Access, deaktiviert fuer alles anderen 2 deaktiviert fuer Access, aktiviert fuer alles andere (Standard) 3 aktiviert fuer alles (Anm. 1: 'xxx fuer Access' ist bezogen auf das Microsoft Access Programm) (Anm. 2: Dies ist auch alles hier beschrieben: http://support.microsoft.com/support/kb/articles/q239/1/04.asp) Ein Wert von 2 oder 3 schuetzt vor diesem Angriff. Daher, IMHO IST DIES DIE EMPFOHLENE LOESUNG Da es sich immer noch um dieselbe 3.5 Einheit handelt, sollten keine Kompatibilitaetsprobleme auftreten. Allerdings ist RDS immer noch ungeschuetzt, waehrend also der Schwachstellenangriff nun nicht mehr moeglich ist, hat ein Angreifer immer noch anonymen Zugriff auf Deine Datenquellen. Dies bedeutet, er kann immer noch Deine Daten veraendern, was natuerlich nicht gut ist. Also, muss etwas getan werden. Ich schlage vor, RDS entweder zu deaktivieren (s.u.) oder ein Upgrade auf MDAC 2.0 vorzu- nehmen (allerdings in der Reihenfolge: 1. MDAC 2.0, dann 2. JetCopkg). Mit dem MDAC 2.0 Upgrade erhaeltst Du die "custom handler" Kontrolle, so dass ein anonymer Zugriff verhindert werden kann. -Loesung #6: Entfernen/Deaktivieren der RDS Unterstuetzung Dies ist die beste Moeglichkeit in Kombination mit JetCopkg (s.o.) falls Systemveraenderungen nicht moeglich sein sollten, z.B. bedingt durch J2K-Regelungen, so koennen doch zumindestens die Angriffsmoeg- lichkeiten durch Deaktivierung von RDS beschnitten werden. Dies laesst sich relativ einfach, wenn auch sehr holpering, bewerkstelligen, indem diese Datei geloescht wird: ?:\Program Files\Common Files\System\Msadc\msadcs.dll oder auf deutschen Systemen ?:\Programme\Gemeinsame Dateien\System\Msadc\msadcs.dll Dies ist die .DLL, die das RDS Interface bereitstellt. Allerdings, empfehle ich, sich etwas mehr Zeit zu nehmen und die Deaktivierung folgendermassen durchzufuehren: * Entfernen des Virtuellen Verzeichnisses /msadc aus IIS: Oeffnen der Microsoft Management Konsole/Internet Service Manager, dann: * Gehe zu 'Internet Information Server' * Auswahl des betreffenden Systems * Auswahl 'Default Web Site' /Standard Web Site' * Auswahl 'msadc' * 'Entf'-Taste druecken oder auf 'Del'/Entf- Icon klicken * 'Sind Sie sicher' Ja * Entfernen des folgenden Registry Schluessels: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC \Parameters\ADCLaunch (NB: Diese Zeile ist umgebrochen) * Entfernen aller Dateien und Unterverzeichnisse in ?:\Program Files\Common Files\System\Msadc oder auf deutschen Systemen ?:\Programme\Gemeinsame Dateien\System\Msadc ----[ 3. Situationen -Situation #1: Ich benoetige RDS ! Hmm, tut mir leid das zu hoeren. Aber ok, es ist machbar. Minimum ist ein Upgrade auf MDAC 2.0. Sollte es Probleme mit der Abwaertskompatibilitaet geben, dann sollte MDAC 2.0 zusammen mit JetCopkg die Loesung darstellen, falls nicht, ist ein Upgrade auf MDAC 2.1 notwendig. Stelle sicher, dass der 'HandlerRequired' Registry Schluessel aktiviert ist (s.o.) Zudem sollten die RDS Beispiele entfernt werden (s.u.) Microsoft empfiehlt zudem, den Anonymen Zugriff auf das /msadc Verzeichnis in IIS zu deaktivieren. Schliesslich muessen die "Custom Handler" implementiert werden. Genauere Informationen sind verfuegbar unter: http://www.microsoft.com/Data/ado/rds/custhand.htm -Situation #2: Alles abgesichert, bis auf die Beispiel-Skripte SEHR WICHTIG Die Verwendung von "Custom Handlers" ist die einzige Moeglichkeit anonymen RDS Zugriff vollstaendig zu deaktiviren. Aber, falls die RDS Beispiele installiert sind (im Verzeichnis: ?:\Program Files\Common Files\System\Msadc\Samples oder auf Deutschen Systemen ?:\Programme\Gemeinsame Dateien\System\Msadc\Beispiele ) dann kann ein Objekt, das in den Beispieldateien enthalten ist, verwendet werden, um die "Custom Handlers" zu umgehen (VbBusObj) !!! Tatsache ist, es gibt keinen Grund weshalb dieses auf einem Produktionsserver sein sollte und es sollte daher entfernt werden. Dabei handelt es sich um einen 2-Stufen-Prozess: * Loeschen des folgenden Unterverzeichnisses (ALLES im Verzeichnis): ?:\Progam Files\Common Files\System\Msadc\Samples oder auf Deutschen Systemen ?:\Programme\Gemeinsame Dateien\System\Msadc\Beispiele * Ennfernen des folgenden Registry Schluessels: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC \Parameters\ADCLaunch\VbBus \Parameters\ADCLaunch\VbBusObj.VbBusObjCls Dies entfernt das VbBusObj Objekt und hindert Angreifer an der Umgehung der definierten "Custom Handler". ----[ 4. msadc.pl detektieren msadc.pl Aktivitaeten der Versionen 1 und 2 zu detektieren, ist eigentlich nicht sehr schwer. Aber ich spreche hier nur von derzeitigen Versionen und gehe davon aus, dass Veraenderungen moeglich sind, die die Detektion sehr viel schwerer machen. Ich werde mich daher hier nur auf die derzeitigen Versionen beziehen. Zuerst fuehrt das Skript eine GET Anfrage auf /msadc/msadcs.dll des Zielservers durch. Falls die Datei existiert, faehrt das Skript fort, ansonsten beendet es sich und gibt es Fehlermeldung aus. Diese anfaengliche GET Anfrage sollte gewoehnlich im WebServer Log auftauchen. NB: erfahrene Nutzer koennten diese Anfrage zu einer HEAD oder POST Anfrage abaendern und koennten zudem eine Verwirrungs-Technik auf den URL anwenden, wie z.B. Hex-Kodierung. Aber, die Anfrage wird protokolliert. Der Punkt ist, das msadcs.dll ohne Parameter auf- gerufen wird, dies bedeutet, jemand untersucht die Datei, macht aber noch nichts mit ihr. Soweit es RDS angeht, sollte niemand die Datei einfach so "untersuchen". Berechtigte Nutzer verwenden sie direkt. Daher sollte ein msadcs.dll Aufruf ohne Parameter als verdaechtig angesehen werden. Falls msadcs.dll existiert (festgestellt anhand der zurueckgesendeten Antwort), dann fragt sie den Nutzer welcher Befehl ausgefuehrt werden soll. Standardmaessig setzt msadc.pl 'cmd /c' oder 'command /c' ein.D.h. es ist abhaengig von cmd.exe bzw. command.com. Trotzdem, wie bereits gesagt, ein 'erfahrener Nutzer' kann das Skript so modifizieren, dass es keinen dieser beiden Befehle benoetigt. Danach beginnt das Skript mit RDS Anfragen, indem es POST Anfragen an eine der folgenden URLs macht: Normale Anfrage: /msadc/msadcs.dll/ActiveDataFactory.Query VbBusObj um "custom handlers" zu umgehen: /msadc/msadcs.dll/VbBusObj.VbBusObjCls.GetRecordset VbBusObj nach dem NetBIOS Namen fragen: /msadc/msadcs.dll/VbBusObj.VbBusObjCls.GetMachineName Falls RDS fuer legitime Aktivitaeten verwendet wird, dann ist die ActiveDataFactory.Query URL normal. Aber: niemdand sollte VbBusObj verwenden, d.h. die beiden anderen URLs sollten als Angriff angesehen werden ! Wichtig ist, dass ein Durchsuchen der Log-Dateien auf 'VbBusObj' hin, nicht hinreichend ist -- 'erfahrene Nutzer' koennen den URL hex-kodieren, so dass er z.B. so aussehen koennte: /%6Dsadc/%6Dsadcs.dll/V%62BusO%62j.V%62BusO%62jCls.GetRecordset (Das ist nur ein Beispiel) Wie man sehen kann, ist der String stark veraendert, so dass er von 'grep' nicht gefunden wuerde. An dieser Stelle moechte ich noch auf zwei weitere Details hinweisen: * Das Standard msadc.pl Skript verwendet 'ACTIVEDATA' als User-Agent. Dies kann als Hinweis verwendet werden, allerdings verwendet RDS dies normalerweise auch, so dass eine Unterscheidung von regulaeren Anfragen eventuell nicht moeglich ist. * Das Standard msadc.pl Skript verwendet '!ADM!ROX!YOUR!WORLD!' als MIME Separator String. Zwar wird dies nicht protokolliert, es wird allerdings von einigen IDS-Systemen verwendet, z.B. Dragon; www.securitywizards.com Standardmaessig versucht das Skript lokale .MDB Dateien des Servers zu verwenden. Findet es eine, dann erstellt es eine Tabelle namens 'AZZ' in dieser. Diese Tabelle wird spaeter nicht entfernt, so dass die vorhandenen .MDB Dateien auf diese Tabellen hin untersucht werden koennen. Allerdings ist es in Version 2 von msadc.pl moeglich, andere Anfragetypen zu verwenden, so dass evt. keine 'AZZ' Tabelle erstellt wird oder gar keine lokalen .MDB Dateien verwendet werden (UNC Unterstuetzung). ----[ 5. Schlussfolgerung Ok, noch eine weitere Nacht, in der ich aufbleibe, um eine Empfehlung niederzuschreiben. Ich sollte wirklich damit aufhoeren. Diese Dinge tue ich fuer Euch Leute ;) Der beste Hinweis darauf, dass Dein System "gehackt" worden ist, ist das auf der Web Site sinngemaess das gleiche steht, wie auf meiner Homepage: http://www.wiretrip.net/rfp/ Es ist nicht schwer. Minimum ist die Loeschung einer Datei und die Seite ist sicher. Dann kannst Du darauf vertrauen, dass Du nicht der Naechste auf der WebSite von Attrition bist: http://www.attrition.org Auf geht's, reparieren, .rain.forest.puppy. ----[ 6. Quellen - Office 97/Jet 3.5 update binary (i386) http://www.wiretrip.net/rfp/bins/msadc/jetcopkg.exe http://officeupdate.microsoft.com/isapi/gooffupd.asp ?TARGET=/downloaditems/JetCopkg.exe - Microsoft Universal Data Access homepage http://www.microsoft.com/data/ - MDAC 2.1.2.4202.3 (GA) (aka MDAC 2.1 sp2) update (i386) http://www.wiretrip.net/rfp/bins/msadc/mdac_typ.exe http://www.microsoft.com/data/download_21242023.htm - MDAC 2.1.1.3711.11 (GA) (aka MDAC 2.1 sp1) hotfix http://www.microsoft.com/data/download/jetODBC.exe - MDAC 2.1 release manifest http://www.microsoft.com/data/MDAC21info/MDAC21sp2manifest.htm - MDAC 2.1 installation FAQ http://www.microsoft.com/data/MDAC21info/MDACinstQ.htm - Security Implications of RDS 1.5, IIS 3.0 or 4.0, and ODBC http://support.microsoft.com/support/kb/articles/q184/3/75.asp - Unauthorized ODBC Data Access with IIS and RDS (MS99-004) http://www.microsoft.com/security/bulletins/ms98-004.asp - Re-release of MS99-004 (MS99-025) http://www.microsoft.com/security/bulletins/ms99-025.asp - MS99-025 FAQ (best explanation of problem by Microsoft) http://www.microsoft.com/security/bulletins/MS99-025faq.asp - MS99-30: Patch available for Office ODBC Vulnerabilities http://www.microsoft.com/security/bulletins/ms99-030.asp - Jet Expression Can Execute Unsafe VBA Functions http://support.microsoft.com/support/kb/articles/q239/1/04.asp - Implementing Custom Handlers in RDS 2.0 http://www.microsoft.com/Data/ado/rds/custhand.htm - Handsafe registry patch (enables handlers) http://www.wiretrip.net/rfp/bins/msadc/handsafe.exe http://www.microsoft.com/security/bulletins/handsafe.exe - RFP9901: NT ODBC remote compromise http://www.wiretrip.net/rfp/p/doc.asp?id=3&iface=2 - RFP9902: RDS/IIS 4.0 vulnerability and exploit http://www.wiretrip.net/rfp/p/doc.asp?id=1&iface=2 - RDS exploit (msadc.pl v1 and v2) http://www.wiretrip.net/rfp/p/doc.asp?id=16&iface=2 - ULG recommended fix on OSALL http://www.aviary-mag.com/News/Powerful_Exploit/ULG_Fix/ulg_fix.html - CERT blurb http://www.cert.org/current/current_activity.html#0 - Attrition mirror of defaced websites (patch or you'll be on it!) http://www.attrition.org/mirror/attrition/ --- rain forest puppy / rfp@wiretrip.net --------- ADM / wiretrip --- Patch your system before flipper and fuqnut get to you... --- Advisory RFP9907 --------------------------- rfp.labs ----------- (translated by ThinkTank)