Slammer-worm wellicht oorspronkelijk uit Nederland

Volgens antivirusbedrijf Kaspersky Labs is de Slammer-worm, die de afgelopen dagen behoorlijk wat problemen op internet heeft veroorzaakt, wellicht afkomstig uit ons eigen kleine kikkerlandje. Dit schrijft WebWereld. Eerder dacht het bedrijf nog dat de uitbraak was begonnen in de Verenigde Staten, maar uit nader onderzoek bleek dat de eerste versies van het virus op 20 januari reeds op Nederlandse servers circuleerden. Dit zou mogelijk kunnen leiden tot een nieuwe Nederlandse virus-rechtszaak, zoals de zaak in 2001 tegen de maker van het Kournikova-virus.

ViruswaarschuwingDe Zuid-Koreaanse politie beweert echter dat een Chinese hackersgroep mogelijk de dader is van de virus-uitbraak, schrijft Reuters. Zuid-Korea was één van de zwaarst getroffen landen, toen zaterdag de worm uitbrak en het internetverkeer gedeeltelijk platlegde. Volgens de autoriteiten hebben de betreffende Chinezen eerder al melding gemaakt van een bug in Microsoft SQL Server. De worm van zaterdag maakt misbruik van een lek wat daar sterk op lijkt.

Er is echter één ding waar alle partijen het over eens zijn: de effecten van de worm duren nog altijd voort. Wereldwijd zouden meer dan 150.000 systemen zijn besmet. Sommige serverbeheerders hebben hun servers nog altijd niet gepatcht, stelt Network Associates. Daarnaast draaien sommige mkb-bedrijven de SQL-server zonder het te weten. Network Associates vreest verder dat andere virusmakers geïnspireerd worden door de worm: SQL-Slammer installeert zich niet in het 'file allocated memory' maar in een gedeelte van het geheugen dat door virusscanners niet gescand wordt.

Door Kevin Levie

Nieuwsposter

28-01-2003 • 13:02

47

Submitter: kodak

Bron: WebWereld

Reacties (47)

47
47
32
11
1
2
Wijzig sortering
Daarnaast draaien sommige mkb-bedrijven de SQL-server zonder het te weten.
Kan ik me goed voorstellen.
De nieuwe Exact bijvoorbeeld installeert MSSQL als je het op een workstation installeert.
Oftewel het zal op een hele hoop bedrijfsworkstations draaien.
Nu is het wel zo dat dergelijke machines via een firewall vaak met het internet verbonden zijn, maar dan moet je maar een capabele systeembeheerder hebben die de boel voor je dicht gooit, als dat al mogelijk/wenselijk is. Heel veel accountants zullen namelijk vanaf buiten met de Exact DB moeten kunnen werken.
Uit een bugtraq mail:
MSDE is integrated with these Microsoft applications:

Microsoft Visio 2000 Enterprise Edition AutoDiscovery & Layout (AD&L)
solution
AD&L solution from Microsoft Visio Enterprise Network Tools 2002
Microsoft SharePoint Team Services (a Microsoft FrontPage Server
Extensions 2002 companion product)
Microsoft Project Central (a Microsoft Project 2000 companion product)
Microsoft Application Center

The following products ship MSDE on their product CD and can use MSDE as a
database:

Microsoft Access
Microsoft Office 2000
Microsoft Visual Studio 6.0
Daar denk je ook niet in de eerste plaats aan als je op zoek gaat naar machines om te patchen...
Microsoft Visual Studio 6.0

Uhhh :?
JA:
MSDE is integrated with these Microsoft applications:
wat ik ook wel komisch vond wat ik net op fok! las:
De SQL worm, die eerder deze week voor veel problemen zorgde, heeft ook de servers van Microsoft zelf te pakken gehad.

Microsoft was vergeten om hun eigen reparatiesoftware te installeren op hun servers, waarna het bedrijf ook zelf een slachtoffer van het virus werd. Een woordvoerder van Microsoft liet weten dat de schuld wordt gelegd bij nalatige systeembeheerders.
toch een beetje slordig? ;)
www.webwereld.nl/nieuws/13927.phtml
[edit]
brrr, wat doet deze post hier? zeker fout geklikt :P
Op de site van Kaspersky staat anders iets heel anders, hoe komen zie hier nou weer bij

http://www.kaspersky.com/news.html?id=970395
Anoniem: 58180 @tiguan28 januari 2003 14:57
Idd.. hoger modden dan 4 kan helaas niet maar dit is een gold tip. Het virus is allereerst gevonden bij een US isp.. Deze hebben het waarschijnlijk niet gemaakt (duh). Dezelfde dag iets later, werd het in nederland gevonden.... |:(

Webwereld:
"Aanvankelijk dachten we dat het in de Verenigde Staten was begonnen. Na een analyse blijkt echter dat de worm uit Nederland komt", aldus Denis Zenkin, woordvoerder van Kaspersky.
Kunnen zij ook niet lezen of is dit mondeling overgebracht?
Op het moment dat webwerld het bericht schreef stond het artikel waar je naar verwijst nog niet op de website van kaspwersky.com . De kans is dus aanwezig dat webwereld het verhaal gebaseerd heeft op eerdere uitspraken van kaspersky.com die dag en het uiteindelijke verhaal nog is aangepast met nieuwere informatie voordat het op www.kaspersky.com werd geplaatst.
Het valt overigens op dat verschillende onderzoekers allemaal met verschillende (voorlopige) conclussies komen en dus nog lang niet met volle zekerheid gezegd kan worden uit welk(e) land(en) het wormpje afkomstig is.
Network Associates vreest verder dat andere virusmakers geïnspireerd worden door de worm: SQL-Slammer installeert zich niet in het 'file allocated memory' maar in een gedeelte van het geheugen dat door virusscanners niet gescand wordt.
het word dus de hoogste tijd dat ze daar maar wat aan gaan doen.
dit zal vast niet het eerste virus zijn die zich daar gaat verstoppen.
Dat het virus voor het eerst vanaf een server in Nederland opgemerkt is zegt weinig over de dader(s). Op mijn werk hadden we op 11 januari ook de eerste aanval op UDP poort 1434. Toevallig (?) ook vanuit een colocated machine in het Nederlandse deel van het netwerk van een amerikaanse provider.

Daar kun je een hoop conclusies uit trekken, maar juist ook weer niet. De machine in kwestie, die nog steeds bereikbaar heeft namelijk zoveel (bekende) poorten open staan dat deze best wel eens gehacked zou kunnen zijn. En die hacker kan een Taiwaneers zijn, maar ook een Chinees, een Nederlander enz. enz. Als ik een Chineze hacker was zou ik de worm ook niet starten op mijn eigen machine..

Zonder deze 'first hitters' machine (forensisch) te onderzoeken kun je weinig zinnigs zeggen, helaas.
Anoniem: 30107 28 januari 2003 15:03
Waarom maken ze gewoon niet eens een soort van virus die dan ook alles patcht. Da's makkelijk voor al die luie systeembeheerders. :+

Beetje slecht voor de privacy eigenlijk maar zou opzich niet slecht zijn vind ik :)
Tja en dat zit er een bug in de patch.... Wordt het toch stiekum weer een virus. Leuk als daar bedrijfskritische systemen op draaien. Eerst testen is wel aardig...
Anoniem: 74926 28 januari 2003 16:24
Net gezien in de pricewatch

Ms Worms 2003 Sql version E 154,00
Anoniem: 17912 28 januari 2003 18:01
niet alleen de motivatie, maar ook de inspiratie dient te worden weggenomen.

Maar ik als iemand die het liefst MS van haar troon ziet vallen en de UXes zie klimmen op de ladder, heb wel gedacht "heheh kijk dit krijg je ervan als de vrienden van MS als marktleider en monopolist alleen hun software of de bakken willen en de wereld nog immer hierop wil werken"

niet dat ik het aanmoedig, maar kan je alwel vertellen, dat er zodra die sourcecode in een ander bezit komt, dat er geheid weer iets los gelaten word om het hele of andere MS produkten (software) plat te gooien.

Nogmaals, ik moedig dit soort dingen helemaal niet aan. meer een waste of precious browsing time, want een aantal van mijn veel bezochte site lagen eruit.

en het feit dat oa zuid korea zo hard getroffen is, ligt alleen aan het feit dat men daar servers alleen incl de MS software kan aanschaffen (iets wat men in China aan het bevechten is)
Waarom zou een virus checker een bepaald stuk geheugen niet controleren?

Daarbij is er toch altijd een process en dat moet je toch altijd kunnen zien.

Waar het virus trouwens vandaan komt is toch niet relevant?
Anoniem: 11479 @it028 januari 2003 13:35
Waarom zou een virus checker een bepaald stuk geheugen niet controleren?
Daarbij is er toch altijd een process en dat moet je toch altijd kunnen zien.
Zoals bij Kaspersky te lezen is:
"Helkern" (= = Slammer) belongs to the "fileless" worms category. This type of malicious programs performs all operations (including infection and spreading) exclusively in the computer's operating memory without using any permanent or temporary files.

... is Slammer geen progje wat het nodig vindt zich ergens op de harde schijf neer te zetten, voor de scanner bestaat het dus eigenlijk niet.
Nog steeds geen antwoord op mijn vraag

Virusscanners scannen het geheugen for virussen. Dus waarom wordt dit dan niet gedetecteerd?

En dan nog is er altijd een proces en dat kan je niet verbergen tenzij je in de kernel gaat vroeten..
Virusscanners scannen het geheugen for virussen. Dus waarom wordt dit dan niet gedetecteerd?
Het moet duidelijk zijn dat het technisch wel mogelijk is, alleen is in bovenstaande samenvatting de formulering nog iets onduidelijker dan de oorspronkelijke:
Normaliter scant een virusscanner het zogenoemde 'file allocated memory', waarbij er een koppeling is tussen het geheugen en een bestand op de harde schijf. Doordat Slammer zich niet in dit gedeelte van het geheugen nestelt, wordt de worm ook niet opgemerkt door de virussoftware.
Wat nu precies met file allocated memory bedoeld wordt is onduidelijk, is het kernel space i.p.v. user space, paging/VM/resource tracking gerelateerd, low level file access zodat er geen sporen in de directory structuur overblijven of gewoon dat er geen files worden gebruikt maar puur alleen geheugen, geen idee. Ze hadden net zo goed kunnen zeggen dat huidige scanners gewoon dit type nog niet kunnen vinden, of misschien dat een netwerk scanner die remote alleen HD checkt en niet geheugen het niet vindt.
Anoniem: 11479 @it028 januari 2003 17:20
Als ik het goed begrepen heb kunnen virusscanners (nog) niets tegen dit soort virussen doen omdat in tegenstelling tot de 'normale' virussen, Slammer (en Code Red for that matter) zich kunnen verspreiden zonder dat ze een bestand nodig hebben. Ze bestaan slechts als datapakketjes, met een stukje foute code eraan, die gebruik maken van de buffer-overrun bug die in ongepatchte SQL-servers zit.
Daarom zijn die ook als enige kwetsbaar.
Omdat het virus geen gebruik maakt van bepaalde file-operations kunnen virusscanners er niets mee beginnen. Of zoals in een ander Kaspersky bericht stond:
Monitors and scanners are only able to establish the fact that malicious code is present in a computer's system memory, but are powerless to remove it; and even if they could, Code Red would simply repeat the attack, once again infecting the computer.
Dus, yep, virusscanners zijn als het ware nog te dom voor het vullen van security-gaten in andere programma's. ;)

[edit: reactie op typhon]
Wat het aanricht is heel simpel: overbelaste servers. Omdat het op een enorm agressieve manier zichzelf aan het verspreiden is genereert 't in zeer korte tijd zoveel random calls dat er dingen gebeuren als afgelopen weekend... De harde schijf laat ie, zoals je zelf al zei, met rust
[/edit]
Het is dus gewoon een stukje onbekende data wat als niets kwaads wordt gezien en ook geen verdere rommel met files achterlaat.

Alleen dan begrijp ik niet hoe dit virus ter werk gaat :? Het moet toch uitgevoerd worden en dan gebreurt er toch wel iets met de harddisk....(wat richt het virus eigenlijk aan)
Anoniem: 76106 @it028 januari 2003 22:21
De meeste virusscanners houden een paar zaken in de gaten, zoals de mail poorten en het filesysteem. De meeste virussen komen namelijk via de mail binnen of via een disk (netwerk,floppy,...).

De moeilijkheid van een virus is niet zozeer het virus in het geheugen van de computer te krijgen, maar om het vervolgens opgestart te krijgen. De eerste slimmeriken bedachten een mail met een attachment met de naam "www.party.com" (gewoon een COM-file, dus executable). Veel mensen klikken daarop en dan wordt het virus gestart. Niet erg geavanceerd dus. De meeste viruscheckers onderscheppen dit ook wel, omdat de file onder water naar schijf geschreven wordt. Op dat moment grijpt de viruschecker in. Deze methode wordt nog steeds gebruikt ("Look at my screensaver for you" e.d.).

De truc is dus om een virus op de computer te krijgen en deze vervolgens automatisch te laten starten. De zogenaamde "buffer overrun" is hier een goede methode voor. Gegeven de volgende situatie:

De programmeur van een mail-server reserveert 100 bytes voor het subject, maar controleert niet of het subject niet langer is. Stel nu dat iemand een mail met een subject van 1000 bytes stuurt. Er worden dan 900 bytes overschreven. Door dit slim te doen kun je in een dergelijk geval soms je eigen code in die 1000 bytes starten. Op zich is het niet eens zo heel erg moeilijk voor een goede programmeur met wat assembler en stack kennis. Het moeilijkste is om dergelijke zwakheden in een programma te vinden en te zorgen dat je de data op die plek krijgt.

In het geval van SQL Server kun je dus door bepaalde data naar die poort te sturen waarschijnlijk ook zo'n "buffer overrun" opwekken. De data gaat dus direct naar het SQL Server proces waar het in geheugen wordt geplaatst. Kort daarna wordt de code opgestart en gaat zelf lekker rond staan scannen.

De data komt dus niet via een bekende poort binnen en al helemaal niet op het filesysteem. De enige mogelijkheid voor een virusscanner zou zijn om alle binnenkomende data op alle poorten te scannen. Dat is natuurlijk nogal heftig voor een zwaar server systeem. Database servers moeten behoorlijk performance leveren en dan ben je niet blij met dit soort constructies die tijd kosten.

Overigens zijn er ook andere oplossingen mogelijk. Zorg dat je data ASCII is en strip bij de binnenkomende data direct het hoogste bitje eraf. Voor het normale protocol is dit geen probleem (is toch ASCII), maar binaire data zal verminkt worden. Programmacode kan dus niet overkomen. Ook de "nieuwe" Microsoft Visual C++ .NET compiler kent speciale opties om run-time te controleren op buffer overruns. Kost wel iets performance, maar dekt wel dit soort fouten af.
Omdat dit stukje proces gebruik maakt van M$FT SQL Server. En virusscanners herkennen SQL Server (helaas) niet als virus.
Waar het virus trouwens vandaan komt is toch niet relevant?
Dat is met name relevant als je de maker "op zijn lazer" wilt geven.
Anoniem: 31421 28 januari 2003 13:07
Wedden dat het een GoT-member was die de worm schreef ;) ?

Vond het al raar dat er geen bericht achtergelaten was met "Tweakers rules" ofzo :D
Misschien een DBA die een baan zoekt bij de gemeente Sneek. De burgemeester daar heeft de schrijver van het Kournikova virus ook een baan aangeboden |:(
Maar da was alleen omdat die jongen in Snits woonde. Deze woont misschien wel in Borkum of Abcoude!
was je het zelf niet? :z
Weet niet hoor, maar zou je echt wel zo willen reageren?

Je zou nu een gerespecteerde internet community kunnen beschuldigen....
Het was een grapje! (met referentie tot sluiting HK ;) ) Uiteraard zou niemand hierom kunnen lachen.
Berichten als 'Tweakers rules' op andere sites resulteren in een onmiddellijke ban hier en alle medewerking aan het achterhalen van de daders. Dat zou je inmiddels moeten weten, er is namelijk niks grappigs aan :{.

De kans dat een dergelijke worm door een T.net/GoT-ter geschreven is bestaat, maar als ik hier om me heen kijk denk ik dat de mensen die het zouden willen het niet kunnen, en de mensen die het kunnen te slim zijn om het ook echt te doen.
Anoniem: 43734 28 januari 2003 16:21
Ken je toch weer eens goed zien hoe belangrijk het is om een critical-patch toch DUIDELIJK aan het volk te melden ...
Als zelfs Microsoft de patch niet heeft doorgevoerd :? " en dus " niet beschikbaar is via WindowsUpdate of OfficeUpdate.
Ken je inderdaad een hele f*cking lange tijd zoeken voor je zoiets gevonden heb op de FServers van MS.

Dit is duidelijk een softwarematige onderlaag die niet interressant is voor de eind-gebruikers, deze zal dus nooit naar namen als SQL gaan zoeken, voor database afhankelijke/freaks zal dit al doorgevoerd zijn toen de patch er was ... jaja een half jaar geleden.

Eerlijk gezegd vind ik dit eigenlijk grappig:
-Er wordt een probleem gevonden in SQL
-Microsoft krijgt hier melding van
-Status is Critical en er wordt een patch gemaakt
-Patch staat vermeld op een TechNet (ofzoiets) pagina
...
-SQL-virus in omloop
-Microsoft heeft vergeten eigen SQL te patchen
(laat staan dit op WindowsUpdate te gooien)

Op dit item kan niet meer gereageerd worden.