[EN] LovSAN DDoS against Microsoft

[Assarbad]

Zitat:

Zitat von Russ Cooper (NTBUGTRAQ)

FYI, it is now our opinion that there will likely be no Internet effect as a result of the DDoS component of the LovSAN worm. Here's an analysis from our folks in the labs;

The worm is programmed to execute a 64byte X 50pps SYN flood attack on port 80 directed at "windowsupdate.com." The worm determines the address for that host name by GETHOSTBYNAME, the IP is not hard-coded into the worm as it was in the original Code Red worm. That host is *not* the site used by Windows to check for updates; that site is windowsupdate.MICROSOFT.com.

Mitigations:
User Logons:
ICSA Labs testing indicates a Windows 2000 host logged in as a normal user will not launch a DOS attack, but one with the Admin logged in will launch the attack. Unfortunately, testing also indicates a Windows XP host with any user logged in will launch the attack.

DNS Magic:
Yesterday morning, a DNS lookup for that name yielded two IP addresses in Microsoft's network address block. Later, they lowered the TTL for windowsupdate.com to 10-15 min. and moved the IP's into their own ASN as if they were preparing to stop announcing for it. Now those IP's no longer resolve via GETHOSTBYNAME nor by rDNS.

This direction *appears* to be headed towards causing local DNS to return a NXDOMAIN to the infected client's GETHOSTBYNAME request. Multiple sources indicate worm will not fire if it gets NXDOMAIN response.

In testing strategies which were proposed for mitigating the effect of this worm we noted that infected systems query DNS for "windowsupdate.com" in order to obtain an IP address which will later be used in a flooding attack on that IP address. It is important to note that this query occurs when the malcode first executes and that infected systems *may* have an IP address cached for use in the attack, and that subsequent alterations to DNS as described here will not redirect their attack UNLESS the systems are rebooted or if they happen to be infected after the DNS changes are applied.

Since the worm queries DNS "by name" for the IP address to attack, it is possible to insert 'bogus' master zones into DNS which supply an arbitrary IP address as the destination of the attack. One of the safest IP addresses to use for this is the 'loopback' IP address which is present on every system-- so the system will then flood a local pseudo interface and the flood traffic will not appear on the network. Supplying an external target IP address is also possible, however it is less useful than might be thought as the malcode spoofs source addresses which renders the traffic non-useful for tracking infected systems.

TruSecure has observed from research and privileged sources that a number of mitigations are being employed at the infrastructure level which will reduce the impact of flooding on the greater Internet and the target sites. These protections do not eliminate the impact of infected systems upon enterprise networks and their ISP connections, although the flood traffic will be managed by routing protocols once it reaches ISP infrastructure. The impact of flooding on ISP connections should not be underestimated, in that relatively small number of systems in flooding mode can significantly burden a T1 connection.

Modifying DNS as described below allows an enterprise to provide a harmless address as the target for infected systems in flooding mode. It is important to ensure that the change is made to a DNS which lies between infected systems and the public Internet. It is also critical that *other* DNS systems in the environment are rebooted or flushed in order to eliminate cached IP address records for windowsupdate.com.

In testing TruSecure found that supplying the loopback address prevented the flood attack traffic from occurring on the network, in that it was 'contained' within the infected systems. A later test in which we specified 'none' instead of 'any' in the zone access "allow-query" verb was also effective, in that the DNS server "though authoritiative" refuses to provide the IP address, depriving the malcode of its target.

While it is possible that Microsoft *may* update its DNS to provide loopback as a target, or remove the relevant address records entirely-- we have no definitive information as to whether they will do so. By implementing these controls at the enterprise level, sites can avoid the consumption of local and ISP connectivity bandwidth caused by the flooding. Please note that none of these measures reduce the scan/attack/infect behavior of the worm.

#
# Fake zone entry for the named.conf file to claim authoritative # for
windowsupdate.com # # Be sure to alter the "file" spec to include the actual
path to # the fake windowsupdate.com zone file # # As described, the
allow-query setting may be set to "any" or "none" # depending upon the
effect desired # zone "windowsupdate.com" {
type master;
file "<path.to.fix.db>/fix.db";
allow-query{ any; };
};


;
; Doctored DNS zone to make LovSan nodes flood their own loopback address ;
instead of windowsupdate.com. ; ; An odd side effect is that it spoofs the
source address of some scanning ; traffic as windowsupdate.com... which in
this case is 127.0.0.1 ; so scanned nodes send ICMP UNREACH to themselves..
or ignore as their ; stack/firewall rules dictate. Not entirely a bad
thing. ; ; Be sure to insert REAL nameserver and domain name entries where ;
indicated in < > brackets below ; ; Timeouts may be tuned as desired to suit
the environment ;
; It is preferable to kill and restart BIND after inserting these ; changes
to ensure that the zone is loaded - be sure to verify that ; no errors occur
as the zone is loaded, and to verify that
; nslookup for 'windowsupdate.com' returns the IP 127.0.0.1
;

$TTL 3600

@ IN SOA <realnameserver.com>. root.<realdomainname.com>. (
20030502 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS <realnameserver.realdomain.com>.
* IN A 127.0.0.1
windowsupdate.com. IN A 127.0.0.1

Cheers,
Russ - NTBugtraq Editor

[alcaeus]

Also, ich will bezweifeln dass viele Leute diesen Text verstehen können, und zwar aus zwei Gründen:
1. technisches Englisch ist saumäßig hart, und
2. wer versteht denn so viel von großen Netzwerken etc.?
Trotzdem, der Beitrag ist ganz interessant...good job Assarbad

[Assarbad]

Danke für die Blumen.

Aber mal ehrlich findest du den Text echt so schwer? Hab keinen Bock das jetzt zu übersetzen ;)

[alcaeus]

Nö,so schwer ist der Text eigentlich nicht,trotzdem wird ihn nicht jeder Mensch verstehen, da ja nicht jeder perfektes technisches Englisch kann. Musst nicht übersetzen, *Alcakannjaenglisch*

[negaH]

Naja, in jurz gefasst. Der DoS Angriff durch MSBlast ist zu verhindern. Das Problem ist das MSBlast so gecodet wurde das er per DNS die IP vom MS Server den er angreifen will abfragt. Ok, andererseits was blieb ihm für'n Wahl. Denn selbst wenn er die nicht gemacht hätte so würde der MS Server jede Anfrage auf seinem Server intern an eine Loopback IP weiterleiten. Diese würde zwar die Responsezeiten echter Anfragen verlängern, aber die vielen DoS Anfragen gingen beim Weitertransport zum richtigen Server unter. Sozusagen würde man damit nicht ernstgemeinte Anfragen ausfiltern. Der Trick: du als echter User connectest auf die Loopback IP die im DNS als www.windowsupdate.com eingetragen wurde. Diese Loopback wartet und leitet dich an eine andere IP weiter. Da MSBlast nur versucht zu connecten und dann sofort abbricht ignoriert er den Weiterleitungsresponse per HTML. Der IE würde dann aber die Site mit dem richtigen Inhalt anzeigen. Ein User mit ernstgemeinten Absichten würde also an eine IP weitergeleitet die nicht per DNS erreichbar ist. Alle Anfragen die durch MSBlast gemacht würden würden so nur den Loopback fluten, der natürlich das ein extrem schnelles IP Caching mit schnellem IP Verfallszeiten hätte.
Als zweiter Schutz wird der IP Adressbereich scaliert. D.h. man connected zwar nur zu einer IP per DNS Resolving, diese verteilt aber die Anfragen intern an mehrere Server. Damit wird die Last runterscaliert.

Stimmt doch so in etwa, oder ?

Gruß Hagen

[JoelH]

wie kann ich meine Win2k Partition zur verfügung stellen für die DDOs Attacke ? Da ich jetzt eh bald pennen geh würd ich Linux runterfahren und Win2k extra nochmal hoch fahren um M$ zu kicken, jippeee !

[alcaeus]

Mal ganz gemütlich JoelH, ich wette windowsupdate.com wird ubgesichert sein,aber wenn du willst kannste ja hinauffahren,als Admin anmelden, Internetverbindung herstellen (ohne Firewall od. Proxy) und warten bis du Besuch über Port 135 kriegst...ich kann aber für nix garantieren.

[Assarbad]

@JoelH: ROFL ;)

@Hagen: Jupp, stimmt in etwa. Aber die TTLs sind trotzdem meist 10-15 (also bei Millionen Rechner immer noch viel).
Außerdem scheint www.windowsupdate.com nicht wirklich relevant zu sein, da die echte Updateseite eine Subdomain von microsoft.com ist.

Aber es scheint noch weitere Methoden zu geben. Diverse ISPs haben zB diverse Ports komplett geblockt um die Verbreitung zu verhindern ;)

[negaH]

Aber was lernen wir daraus ?!

Wenn man MSBlast gut coden wollte so müsste man eine echte Verbindung zum Server aufbauen. Dann einen Download beginnen und die IP zum Download speichern. Danach fängt man an diese reale IP zu fluten.
Noch besser wäre wenn man den Angriff vorbereitet. Das heist schon Tage vorher beginnt man mit solchen echten Downloads und merkt sich die IP's. Damit das nicht so auffällig ist sollte man also diese Testphase nicht so oft pro infiziertem Client machen. Z.b. nur zweimal pro Tag.
Am Stichtag werden nun alle diese IP überflutet, also ca. 2-3 mal pro Sekunde und das mehrere Stunden. Der Admin auf MS Server Seite hat dann auf breiterer Front zu kämpfen und muß seine Leute aus'm Wochenende ranpfeifen.

Allerdings, ich bin wahrlich kein Experte für solche Sachen :)

Gruß Hagen

[JoelH]

Zitat:

Zitat von negaH

Aber was lernen wir daraus ?!

Wenn man MSBlast gut coden wollte

Er war IMHO zu gut gecoded,er aht sich wohl zu schnell verbreitet. Der Initiator wollte erst heute die maximal e Ausbreitung haben, dann hätte er gute AntiM$ Chance gehabt, leider waren dei M$ Produkte wohl leichter zu kapern bzw. zahlreicher als er gedacht hat und dadurch wurde der Wurm zu früh entdeckt.

Er war also ZU gut !!

[negaH]

Naja, wenn er richtig gut gewesen wäre dann hätte man ihn auch nicht so leicht entdeckt, so einfach. Die Experten meinen das er doch recht simpel ist. Davon abgesehen bingt sowas nicht viel nur um auf Sicherheitslücken aufmerksam zu machen. Ich will jetzt hier nicht über politische Systeme diskutieren und schon garnicht ob Monopole wie MS gut oder schlecht sind. Aber eines steht fest, das Internet ist eine Sozialpolitische Einrichtung für alle Menschen, und solche Viren stören den "friedlichen Verkehr". Nicht das ich meine das Spammer besser wären.

Gruß Hagen

[JoelH]

da hast du natürlich in allen Punkten recht. Sie haben aber leider wenig mit dem Thema zutun ! Alles was Arbeti macht die Sinnlos ist ist unnötig, das ist normal.

[BungeeBug]

Hi,

jetzt mal ne technische Frage an die "Experten" hier :)
Ich hab keine Ahnung welchen Exploit der Wurm nutzt nur wär es nicht sinnvoll gewesen erst zu checken welches OS läuft bevor ich versuche nen laufenden Process mitna falschen einsprung Adresse zupatchen? Immerhin war ja das das Problem was den Wurm verraten hat. Er hat versucht Win XP Pro mit den einsprung Adressen von Win2k zupatchen!! Oder überschreibt der Wurm den Puffer von ausserhalb, sprich vom I-Net aus?

[negaH]

Korrekt, er schiebt zu viele Bytes rüber, was durch einen Fehler in DCOM den Buffer Overflow bewirkt. D.h. um ein nicht-infiziertes System zu infizieren muß ja das nicht infizierte System veranlasst werden den MSBlast zu downloaded und auszuführen. Der Bufferoverflow lösst einen Fehler im DCOM aus der wiederum dann dazu führt das das Windows Operation System selbständig MSBlast.exe aus dem WEB downloaded und diese EXE unaufgefordert ausführt. Dazu wird der Microsoft Trivial File Transport Protokol Client TFTP.exe benutzt. Wie man sieht das eigentliche Problem ist das OS, das solche Reaktionen zeigt. Böse gesagt, in China furzt einer und bei 100.000 Windows-User weltweit wird durch einen Schalldruckfehler im OS die Festplatte formatiert.
Damit sowas überhaupt möglich ist, muß die fehlerhafte Software unter dem System Benutzerkonto laufen, denn nur dieses hat mehr Rechte als der Administrator selber. Alleine dies ist schon ein Problem aus meiner Sicht, denn ICH und ICH alleine habe zu sagen was MEINE Software auf MEINEM Rechner zu tun und zu unterlassen hat. Aber das IST mit Windows NICHT möglich. Wenn ich also nicht will das irgendwas im OS ohne meine Kenntnis ins Netz geht dann muß das das OS absolut befolgen und verhindern.

Gruß Hagen

[Stanlay Hanks]

Zitat:

Zitat von negaH

Damit sowas überhaupt möglich ist, muß die fehlerhafte Software unter dem System Benutzerkonto laufen, denn nur dieses hat mehr Rechte als der Administrator selber [...] Aber das IST mit Windows NICHT möglich...

Hallo. Ich muss gestehen, ich kenne mich mit diesen "Rechte Geschichten" nicht so gut aus, deshalb mag meine Frage etwas naiv klingen: Es gibt da doch diesen "Trick" bei WinXP Home, dass man im Abgesicherten Modus hochfährt und sich dann mit dem "Administrator" Konto anmeldet. Hat man denn noch nicht mal dann alle Rechte auf dem PC?? :shock:

Danke schon mal,

Man liest sich, Stanlay :hi:

[negaH]

nein, System ist immer privelegierter.

Gruß Hagen

[Assarbad]

SYSTEM "hat" auch nicht alle Rechte, wie Hagen sagte, sondern hat "per default" mehr Rechte aktiviert. Der Administrator hat "per default" weniger Rechte aktiviert, kann sie sich aber selbst geben.

Die meisten der Rechte (zB Zusammenbasteln von Primary-Tokens) brauchst du aber auch nie direkt. Und solange der Admin sich nicht selbst zur TCB zählt, sollte er auch das entsprechende Recht nicht an sich selbst vergeben ;)

@Bungee: Es gibt keine vernünftige Methode mit so kleinem Code auch die OS-Version MIT SP-Level rauszubekommen. Deswegen hat das Würmchen manchmal den falschen Code injeziert und es kommt manchml zum Absturz (habe davon auf XP gehört ... hingegen auf 2000 noch nicht)

@Hagen: *Heul* das stimmt doch nicht!!!! ... System immer privilegierter ... tss tss

[Chewie]

Was ich nicht ganz verstehe: wie funnktioniert das eigentlich mit den Buffer Overflows? Oder besser gesagt: Wie und warum wird dieser Code dann ausgeführt?

[negaH]

Tja, ich wollte nicht auf die Feinheiten eingehen. Es ist aber so daß System als Process die Privilegierung des höchsten Users hat. Bei MSBlast hat der System Process durch den Fehler per TFTP.exe MSBlast.exe gedownloaded. Sogesehen ist es ein Unterschied ob man "System" als Konto betrachtet oder als "System" Prozess. Normalerweise kann man das "System" Konto beschränken, aber dann hagelts von Fehlern durch Programme die dieses Konto mit hoher Privilegierung benötigen. Ich hatte mal bei mir zum Spaß System stark eingeschränkt. Nach einem Neustart war das komplette Win2k vollkommen blockiert und ließ sich nicht mehr reparieren. Es half nur eine Neuinstallation. Aber, so doof muß man erst mal sein. Normalerweise ändert man diese Rechte als DAU nie, und das ist ein Problem der Vorkonfiguration durch Windows.

Gruß Hagen

[Assarbad]

Hagen, nochmal! SYSTEM hat per default die höchsten Privilegien. Aber ein Reboot reicht und ich habe als Admin genauso viele Privilegien!

Verwechsele hier bitte nicht Kernelmode und Usermode! Services und Programme von denen wir reden laufen im Usermode. Da kann jeder alles, insofern er erstmal bestimmte Rechte hat. Denn hat er die, kann er sich weitere verschaffen!

[negaH]

Gut, andere Frage: was passiert wenn man System zu stark einschränkt ?

[Assarbad]

Bei Buffer Overflows wird ein Zustand hervorgerufen, in dem ein Programm an einer anderen (als üblichen) Stelle Code ausführt. Ist nun der Puffer der übergelaufen ist mit Code befüllt und führt das Programm an o.g. Stelle eben diesen Code aus, so kann man das ausnutzen.

[Assarbad]

Da SYSTEM kein echter Account ist, kannst du ihn nicht einschränken. Darum ging es aber nicht. Es ging darum, daß ein beliebiger User vom Admin (inkl Admin selber) jederzeit die gleichen Privs wie der Pseudo-Account SYSTEM bekommen kann.

[alcaeus]

Danke Assarbad, habe mich auch schon immer gefragt was der BufferOverFlow soll, jetzt weiß ichs *mussschnellvirusprogrammierengehen*

[negaH]

@Asserbad: Jetzt bin ich aber verwirrt,

Zitat:

Da SYSTEM kein echter Account ist, kannst du ihn nicht einschränken.
SYSTEM hat per default die höchsten Privilegien.
SYSTEM "hat" auch nicht alle Rechte, wie Hagen sagte.

Deine Aussagen widersprechen sich aber.
Wenn System "per Default" die höchsten Pivilegien hat und man diese Rechte nicht einschränken kann, wie kann dann System weniger Privilegien bekommen und mit höchsten Privilegien nicht alle Rechte besitzen ?

Was ich mit meinem Posting sagen wollte ist das für diese Art der Bufferoverflow Angiffe der injezierte Code unter dem SYSTEM Konto läuft da es das Konto mit den höchsten Privilegien ist.

Gruß Hagen

[Assarbad]

Okay, ich versuchs nochmal ;)

Code:

const
  SYSTEM = 5; // 5 = maximum Privilegien (default)
  Administrator = 4; // Fast maximum (per default)

Admin kann aber sagen:

Code:

Administrator:=5;

Sorry, da ich Pedant bin (manchmal), stimmt deine Aussage entsprechend nicht:

Zitat:

Zitat von Hagen

nein, System ist immer privelegierter.

Aus 5 = 5 schließe ich Äquivalenz ;)

Jetzt verstanden? Deine Aussage war nur zu weit gefaßt.

[negaH]

Au mann bist du ein Krümel....., so gesehen haste Recht wobei jetzt aber der Punkt ins Spiel kommt "Konto SYSTEM = Hardwarelevel SYSTEM", denn soviel wie ich weis hat System Ring 0 Zugriff, was ein normaler User, selbst wenn er höchstprivilegierter Administrator ist, nicht haben kann. Oder gibt es hier wieder Feinheiten zu beachten, die dann in's Tausendste führen :)

Auf jeden Fall bin ich der Meinung das das OS selber die meisten Rechte hat noch mehr als der Bediener selber.

Gruß Hagen

[Assarbad]

Hehe ;)

Also auf Ring0 (i.e. Kernelmode) haben die User und Prozesse aus dem Usermode keine Bedeutung mehr, soweit ich weiß. System kann man natürlich (rein semantisch auch Ring0 zuschreiben, aber dann ist der "User" System eben schizophren ;)) ... aber ich verstehe, was du meinst. Nur eben in den Begriffen der Windows-Security stimmt es nciht ganz ;)

Ansonsten hat ein beliebiger (auch Pseudo-Account) keinen echten Ring0-Zugriff. Aber das SYSTEM zur TCB gehört, kann er natürlich Treiber stoppen etc ... und beliebige IOCTLs werfen ;)

Conclusio: Ein beliebiger User mit entsprechenden Rechten/Privs kann einen Treiber benutzen um etwas für ihn machen zu lassen.

[negaH]

Sehr schön sind wir uns also technisch gesehen einig, nur an unserer Kommunkikation hat es gescheitert, bzw. genauer gesagt war meine Aussage nicht richtig da eben nicht 5 > 5 ist :)

Ich hatte schon wieder mal an meinem hart erarbeiteten Wissen gezweifelt.

Gruß Hagen

[Assarbad]

*grins* du bist einer der wenigen Profis im Sinne des Wortes hier im Forum ;) ... dich zweifelt niemand an. Ist wahrscheinlich wie bei "Threadsafe" im Portscanner-Beitrag ... da haben wir auch erst was zum Synchronisieren unserer Begriffe gebraucht ;)

[Luckie]

Zitat:

Zitat von Chewie

Was ich nicht ganz verstehe: wie funnktioniert das eigentlich mit den Buffer Overflows? Oder besser gesagt: Wie und warum wird dieser Code dann ausgeführt?

Hier ein Heise-Text zum Thema Buffer-Overflow: http://www.heise.de/ct/01/23/216/

[flomei]

Zitat:

Zitat von Luckie

Hier ein Heise-Text

Ja bist du denn des Wahnsinns hier einen Link nach Heise zu posten?! Das kannst du doch nicht machen :roll:

Zitat:

Zitat von Daniel B

Mann, mann, mann, muss man denn jetzt jeden Tag Heise-Links hier posten?

;)

MfG Florian :hi: