Nieuws
image

Nieuwe SQL worm veroorzaakt veel problemen

zaterdag 25 januari 2003, 10:14 door Redactie, 37 reacties

Sinds zaterdagochtend vroeg lijkt een nieuwe SQL worm die zich richt op MSSQL servers op Windows2000 veel schade aan te richten. Op diverse 'operator' mailinglists wordt melding gemaakt van enorme hoeveelheden verkeer die een besmette machine het net op stuurt. De Amsterdam Internet Exchange lijkt een kleine hickup te hebben gehad rond 8:00. Ook in Amerika slaan veel beheerders alarm.

Oplossing lijkt vooralsnog te zijn om port 1434/udp te blokkeren op gateways en routers. Zodra meer bekend is hoe de worm te stoppen is op Windows2000 machines laten we dit hier weten.

Update 11:35: Het lek waar de worm waarschijnlijk gebruik van maakt is in juli 2002 gemeld door NGSSoftware. Microsoft heeft hierop Security Bulletin MS02-039 uitgebracht en een patch ter beschikking gesteld. Vooralsnog lijkt het erop dat het installeren van de patch en het rebooten van de server de 'besmetting' wegneemt.

Update 13:55: de verkeersstorm lijkt nog niet af te nemen, hoewel een aantal grote providers inmiddels filters heeft geplaatst om de worm af te remmen. Omdat de worm gebruik maakt van het ("connection-less") UDP protocol is de snelheid van de verspreiding en besmetting veel hoger dan bij eerdere wormen het geval is geweest. De worm is in staat vanaf 1 server tientallen megabits aan verkeer op te leveren. Security.nl heeft inmiddels een aantal pakketten ontleed en de systeemcode die de worm uitvoert zichtbaar gemaakt. Tevens is de worm nu beschikbaar in C code voor debug doeleinden (gebruik op eigen risico!).

Reacties (37)
25-01-2003, 10:26 door Anoniem
heeft iemand links naar die operator mailinglists ?
25-01-2003, 10:36 door Anoniem
Originally posted by Unregistered
heeft iemand links naar die operator mailinglists ?

http://www.nanog.org
25-01-2003, 10:55 door Anoniem
Het is mij de laatste paar uur opgevallen, dat poort 1434 vaak (automatisch) wordt geblokt door m'n Firewall. Ik raad daarom iedereen aan die een Firewall gebruikt om, indien nodig, desnoods handmatig poort 1434 voor alle verkeer te blokkeren.
25-01-2003, 11:11 door Anoniem
Originally posted by Unregistered
Het is mij de laatste paar uur opgevallen, dat poort 1434 vaak (automatisch) wordt geblokt door m'n Firewall. Ik raad daarom iedereen aan die een Firewall gebruikt om, indien nodig, desnoods handmatig poort 1434 voor alle verkeer te blokkeren.

Ik zie geen toename in 1434 maar wel in poort 1433 kan dit dezelfde worm zijn?
25-01-2003, 11:19 door Anoniem
Mijn firewall logs en intrusion analyzer lopen over van aanvragen om poort 1434 te mogen openen. In een half uur tijd werd mijn hele beeldscherm opgevuld met slechts 1 logbestand.

Wie weet of er al virusdefinities bestaan om deze worm te detecteren?
25-01-2003, 11:33 door Anoniem
231 sinds 10 AM, zien er zo uit:

----snippage----
UDP: ----- UDP Header -----
UDP:
UDP: Source port = 2375
UDP: Destination port = 1434
UDP: Length = 384
UDP: Checksum = E022 (correct)
UDP: [376 byte(s) of data]
UDP:
CL/DCE RPC: Continuation of missing frame
CL/DCE RPC: ----- Connectionless MS DCE/RPC Header -----
CL/DCE RPC:
CL/DCE RPC: RPC Version = 4
CL/DCE RPC: PDU Type = 1 (Ping)
CL/DCE RPC: flags1 = 01
CL/DCE RPC: 0... .... = Reserved
CL/DCE RPC: .0.. .... = NOT Broadcast Request
CL/DCE RPC: ..0. .... = NOT Idempotent Request
CL/DCE RPC: ...0 .... = NOT Maybe Request
CL/DCE RPC: .... 0... = FACK required
CL/DCE RPC: .... .0.. = PDU is NOT fragment
CL/DCE RPC: .... ..0. = PDU is NOT last fragment
CL/DCE RPC: .... ...1 = Reserved
CL/DCE RPC: flags2 = 01
CL/DCE RPC: 0... .... = Reserved
CL/DCE RPC: .0.. .... = Reserved
CL/DCE RPC: ..0. .... = Reserved
CL/DCE RPC: ...0 .... = Reserved
CL/DCE RPC: .... 0... = Reserved
CL/DCE RPC: .... .0.. = Reserved
CL/DCE RPC: .... ..0. = Cancel not Pending at the call end
CL/DCE RPC: .... ...1 = Reserved
CL/DCE RPC: Data Representation Format Label = 010101
CL/DCE RPC: Serial Number (High Byte) = 1
CL/DCE RPC: OID = 01010101-0101-0101-0101-010101010101
CL/DCE RPC: IID = 01010101-0101-0101-0101-010101010101
CL/DCE RPC: AID = 01010101-0101-0101-0101-010101010101
CL/DCE RPC: Server Boot Time = 16843009
CL/DCE RPC: I/F Version = 16843009
CL/DCE RPC: Sequence number = 16843009
CL/DCE RPC: Operation Number (Method) = 257
CL/DCE RPC: Interface hint = 257
CL/DCE RPC: Activity hint = 257
CL/DCE RPC: Packet Body Length = 257
CL/DCE RPC: Fragment Number = 257
CL/DCE RPC: Authentication protocol ID = 1
CL/DCE RPC: Serial Number (Low Byte) = 1
CL/DCE RPC:
CL/DCE RPC: [296 bytes of continuation data]
CL/DCE RPC:
-----------end snip----------
25-01-2003, 11:56 door Anoniem
Het is dus een gezellig spelletje ping pong tussen SQL servers en de snelste server wint en legt de ander plat.

Hier in het log is het begonnen om 6:29 uur.

frans egberink
25-01-2003, 12:09 door Anoniem
Logbestand van deze morgen.
=====================
ZoneAlarm Logging Client v3.1.291
Windows 98-4.10.2222- A -SP
type,date,time,source,destination,transport


FWIN,2003/01/25,10:40:20 +1:00 GMT,216.205.118.2:2515,212.115.195.245:1434,UDP
FWIN,2003/01/25,10:42:28 +1:00 GMT,152.30.22.50:1970,212.115.195.245:1434,UDP
FWIN,2003/01/25,10:42:32 +1:00 GMT,211.170.189.202:1032,212.115.195.245:137,UDP
FWIN,2003/01/25,10:44:26 +1:00 GMT,195.97.145.170:4247,212.115.195.245:1434,UDP
FWIN,2003/01/25,10:48:50 +1:00 GMT,128.2.193.169:1198,212.115.195.245:1434,UDP
FWIN,2003/01/25,10:49:00 +1:00 GMT,198.64.149.132:2459,212.115.195.245:1434,UDP
FWIN,2003/01/25,10:50:10 +1:00 GMT,213.29.70.105:1027,212.115.195.245:137,UDP
FWIN,2003/01/25,10:55:14 +1:00 GMT,130.85.5.92:2153,212.115.195.245:1434,UDP
FWIN,2003/01/25,10:55:26 +1:00 GMT,212.113.161.162:4305,212.115.195.245:1434,UDP
FWIN,2003/01/25,10:57:00 +1:00 GMT,132.192.94.84:2687,212.115.195.245:1434,UDP
FWIN,2003/01/25,10:59:34 +1:00 GMT,217.114.96.98:0,212.115.195.245:0,ICMP (type:3/subtype:1)
FWIN,2003/01/25,11:02:34 +1:00 GMT,62.94.81.197:1581,212.115.195.245:1434,UDP
FWIN,2003/01/25,11:04:22 +1:00 GMT,63.168.93.58:2636,212.115.195.245:1434,UDP
FWIN,2003/01/25,11:05:26 +1:00 GMT,204.48.128.111:2342,212.115.195.245:1434,UDP
FWIN,2003/01/25,11:05:30 +1:00 GMT,217.216.155.205:1028,212.115.195.245:137,UDP
FWIN,2003/01/25,11:05:54 +1:00 GMT,139.30.71.61:1202,212.115.195.245:1434,UDP
FWIN,2003/01/25,11:10:18 +1:00 GMT,61.171.22.243:1026,212.115.195.245:137,UDP
FWIN,2003/01/25,11:10:30 +1:00 GMT,207.178.1.10:1189,212.115.195.245:1434,UDP
FWIN,2003/01/25,11:10:44 +1:00 GMT,200.163.73.183:1026,212.115.195.245:137,UDP
FWIN,2003/01/25,11:11:50 +1:00 GMT,212.61.71.2:3046,212.115.195.245:1434,UDP
FWIN,2003/01/25,11:14:40 +1:00 GMT,212.110.162.143:2658,212.115.195.245:1434,UDP
FWIN,2003/01/25,11:15:06 +1:00 GMT,65.113.54.103:4091,212.115.195.245:1434,UDP
FWIN,2003/01/25,11:18:44 +1:00 GMT,217.19.70.102:1026,212.115.195.245:137,UDP
FWIN,2003/01/25,12:05:22 +1:00 GMT,196.25.84.19:1026,212.115.196.110:137,UDP
25-01-2003, 12:19 door Anoniem
Dit kan helpen: http://www.microsoft.com/Downloads/details.aspx?displaylang=en&FamilyID=DCFDCBE9-B4EB-4446-9BE7-2DE45CFA6A89

En het schijnt dat als je de SQL monitor uitzet maar wel poort 1433 wel doorlaat eea werkt maar je wel van het probleem af bent.

#include <disclaimers/i-don't-use-m$-so-don't-know-if-this-works.h>
25-01-2003, 14:44 door Anoniem
Originally posted by Unregistered
Mijn firewall logs en intrusion analyzer lopen over van aanvragen om poort 1434 te mogen openen. In een half uur tijd werd mijn hele beeldscherm opgevuld met slechts 1 logbestand.

Wie weet of er al virusdefinities bestaan om deze worm te detecteren?
maar je firewall blokeert poort 1434 ook dus waarom wachten op een virus update
25-01-2003, 15:21 door Anoniem
Originally posted by Unregistered
heeft iemand links naar die operator mailinglists ?

Lijk ook eens op usenet...
muc.lists.bugtraq
25-01-2003, 16:06 door Anoniem
"shit, meet fan, fan, meet shit" :(

Ik zie sinds een uur steeds meer hits van europese netblocks.

Wat doe je met een admin die 7 maanden heeft zitten snurken, en op maandagochtend pas doorheeft dat er gigabytes aan crap zijn uitgegaan ?

Iets met mieren en honing dacht ik zelf :)
25-01-2003, 17:04 door Anoniem
Originally posted by Unregistered
maar je firewall blokeert poort 1434 ook dus waarom wachten op een virus update

Omdat je inmiddels intern al besmet kan zijn :/ dan helpt je firewall geen f*ck meer
25-01-2003, 17:05 door Anoniem
Originally posted by WormPaul
"shit, meet fan, fan, meet shit" :(

Ik zie sinds een uur steeds meer hits van europese netblocks.

Wat doe je met een admin die 7 maanden heeft zitten snurken, en op maandagochtend pas doorheeft dat er gigabytes aan crap zijn uitgegaan ?

Iets met mieren en honing dacht ik zelf :)


Sorry, maar daar ben ik het helemaal mee eens. Waarom moet men eerst bij systeem beheer 7 maanden zitten niksen op het zitvlees om er nu achter te komen dat men besmet is met een nieuwe worm. En dat terwijl er sinds 2002 een patch voor bestaat. De dames en heren systeem beheerders (zeg maar gerust AMATEURS) worden heel erg hartelijk bedankt!
25-01-2003, 17:19 door Anoniem
Originally posted by WormPaul
Wat doe je met een admin die 7 maanden heeft zitten snurken, en op maandagochtend pas doorheeft dat er gigabytes aan crap zijn uitgegaan ?

Iets met mieren en honing dacht ik zelf :) [/B]

Er gaan maandag gegarandeerd koppen rollen!!
25-01-2003, 17:32 door Anoniem

CL/DCE RPC: Server Boot Time = 16843009
CL/DCE RPC: I/F Version = 16843009
CL/DCE RPC: Sequence number = 16843009
CL/DCE RPC: Operation Number (Method) = 257
CL/DCE RPC: Interface hint = 257
CL/DCE RPC: Activity hint = 257
CL/DCE RPC: Packet Body Length = 257
CL/DCE RPC: Fragment Number = 257


Alle packets van mongolen die blijkbaar al maanden slapen (betaald) hebben dit in ieder geval gemeen.
Heb nu een (ietwat tragere) SQL lopen als test, nog geen false positives.

Commentaar meer dan welkom
25-01-2003, 17:46 door Anoniem
Originally posted by Unregistered
Er gaan maandag gegarandeerd koppen rollen!!

Wat mij betreft mogen ze iedereen die het aandurft om SQL services direct aan internet aan te bieden ook wel koppensnellen, met of zonder patch. Dat geldt trouwens voor elke DBMS, ook Oracle of mySQL dus.

Als je het een beetje serieus doet, staat je SQL in het LAN, je webdoos in de DMZ, en is de webdoos echt alleen maar op poort 80/443 te benaderen. De SQL is dan vanuit internet helemaal niet te bereiken, tenzij iemand via de webdoos weet in te breken (en ja, die webdoos moet dus wel heel goed dicht zitten, liefst geen ASP draaien enz.).

'Gelukkig' zijn er veel tentjes die uit kostenbesparing zowel SQL als IIS op 1 en dezelfde doos gooien, en die ook nog in de DMZ zetten (tenzij ze zelfs een DMZ niet kunnen betalen). Er zijn ook anderen die de admin dwingen om puinzooi zoals M$ CMS of CS in de DMZ te zetten. Deze figuren zien hopelijk nu in dat de kostenbesparing uiteindelijk veel duurder is.

Het is dus niet altijd en alleen de 'lazy admin'. Er bestaan ook baasjes die alles beter weten dan de admin. Zij zijn het die de admin overrulen om bijvoorbeeld de extended nedstat service (vereist externe SQL toegang) te gebruiken, terwijl er veel mooiere en save alternatieven zijn.

Verder vindt ik in de eerste plaats toch de software leverancier verantwoordelijk voor de fouten in hun software. Fijn hoor, die patch, maar hadden ze niet gewoon in eerste instantie die sql crap goed kunnen dichttimmeren?

Goed, maandag zal ik in ieder geval een nieuw argument hebben om dat hele M$ sql bij ons uit te bannen ten faveure van Oracle of voor mijn part mySQL. Mijn webapps zullen zich geen zorgen maken als de andere kant ineens linux heet, en externe sql toegang doen we niet aan, no matter what de baasjes roepen. De binnenkant is afgelopen vrijdag al voorzien van sql sp3, voorzover ik weet zit deze patch daar al ingebakken.

Groeten, GvD.
25-01-2003, 17:54 door boeboe
Het is zowel TCP als UDP verkeer. Allemaal naar poort 1434. Uit de logging van mijn Cisco router:

Jan 25 13:09:03.844: %SEC-6-IPACCESSLOGP: list outside denied udp 64.186.130.4(4948) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 13:18:46.430: %SEC-6-IPACCESSLOGP: list outside denied udp 134.39.241.28(3467) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 13:23:20.057: %SEC-6-IPACCESSLOGP: list outside denied udp 194.47.40.170(1029) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 13:48:15.487: %SEC-6-IPACCESSLOGP: list outside denied udp 66.169.79.10(4766) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 13:56:02.839: %SEC-6-IPACCESSLOGP: list outside denied udp 210.112.229.190(1026) -> aa.bb.cc.dd(137), 1 packet
Jan 25 14:10:22.634: %SEC-6-IPACCESSLOGP: list outside denied udp 205.177.168.32(2701) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 14:16:44.462: %SEC-6-IPACCESSLOGP: list outside denied udp 195.167.178.244(3194) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:00:52.498: %SEC-6-IPACCESSLOGP: list outside denied udp 66.118.140.56(2083) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:01:01.974: %SEC-6-IPACCESSLOGP: list outside denied tcp 216.40.243.24(17300) -> aa.bb.cc.dd(17300), 1 packet
Jan 25 15:23:49.939: %SEC-6-IPACCESSLOGP: list outside denied udp 66.250.59.10(1037) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:26:19.523: %SEC-6-IPACCESSLOGP: list outside denied udp 213.233.121.16(1048) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:31:07.441: %SEC-6-IPACCESSLOGP: list outside denied udp 217.199.33.58(2711) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:32:51.798: %SEC-6-IPACCESSLOGP: list outside denied udp 143.129.135.30(3116) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:40:22.216: %SEC-6-IPACCESSLOGP: list outside denied tcp 62.23.247.212(4389) -> aa.bb.cc.dd(1433), 1 packet
Jan 25 15:42:36.390: %SEC-6-IPACCESSLOGP: list outside denied udp 80.204.93.249(2144) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:44:14.794: %SEC-6-IPACCESSLOGP: list outside denied udp 66.118.149.62(4560) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:44:20.106: %SEC-6-IPACCESSLOGP: list outside denied udp 168.156.116.231(4997) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:46:16.508: %SEC-6-IPACCESSLOGP: list outside denied tcp 62.23.247.212(4389) -> aa.bb.cc.dd(1433), 1 packet
Jan 25 15:49:43.431: %SEC-6-IPACCESSLOGP: list outside denied udp 66.191.40.194(4661) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 16:05:18.281: %SEC-6-IPACCESSLOGP: list outside denied udp 193.225.87.91(3061) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 16:08:57.203: %SEC-6-IPACCESSLOGP: list outside denied udp 216.164.244.113(3342) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 16:18:55.364: %SEC-6-IPACCESSLOGP: list outside denied udp 80.146.200.183(3087) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 16:27:28.325: %SEC-6-IPACCESSLOGP: list outside denied udp 66.118.149.248(1874) -> aa.bb.cc.dd(1434), 1 packet
25-01-2003, 18:04 door Anoniem
Originally posted by boeboe
Het is zowel TCP als UDP verkeer. Allemaal naar poort 1434. Uit de logging van mijn Cisco router:

-SNIP-


Jan 25 13:56:02.839: %SEC-6-IPACCESSLOGP: list outside denied udp 210.112.229.190(1026) -> aa.bb.cc.dd(137), 1 packet

Dat lijkt meer op nimda, of gewoon iemand die probeert een netwerkshare te openen bij je.

-SNIP-

Jan 25 15:01:01.974: %SEC-6-IPACCESSLOGP: list outside denied tcp 216.40.243.24(17300) -> aa.bb.cc.dd(17300), 1 packet

Deze is vaag: niet typerend voor een sql attack. Ik zou die 216.40.243.24 eens lekker doorlichten.

Groeten, GvD
25-01-2003, 18:04 door Anoniem
Het grooste verkeer is al voorbij dat was van 07:00-08:00.

Na 08:00 ging het heel snel omlaag en vanaf 13:00 is het redelijk constant.

Heb een grafiekje van de router op http://www.fect.nl/Traffic.wmf gezet betreffende het inkomende verkeer op poort 1434

Frans Egberink
25-01-2003, 18:20 door Anoniem
http://www.dshield.org/port_report.php?port=17300


Originally posted by boeboe
Het is zowel TCP als UDP verkeer. Allemaal naar poort 1434. Uit de logging van mijn Cisco router:

Jan 25 13:09:03.844: %SEC-6-IPACCESSLOGP: list outside denied udp 64.186.130.4(4948) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 13:18:46.430: %SEC-6-IPACCESSLOGP: list outside denied udp 134.39.241.28(3467) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 13:23:20.057: %SEC-6-IPACCESSLOGP: list outside denied udp 194.47.40.170(1029) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 13:48:15.487: %SEC-6-IPACCESSLOGP: list outside denied udp 66.169.79.10(4766) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 13:56:02.839: %SEC-6-IPACCESSLOGP: list outside denied udp 210.112.229.190(1026) -> aa.bb.cc.dd(137), 1 packet
Jan 25 14:10:22.634: %SEC-6-IPACCESSLOGP: list outside denied udp 205.177.168.32(2701) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 14:16:44.462: %SEC-6-IPACCESSLOGP: list outside denied udp 195.167.178.244(3194) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:00:52.498: %SEC-6-IPACCESSLOGP: list outside denied udp 66.118.140.56(2083) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:01:01.974: %SEC-6-IPACCESSLOGP: list outside denied tcp 216.40.243.24(17300) -> aa.bb.cc.dd(17300), 1 packet
Jan 25 15:23:49.939: %SEC-6-IPACCESSLOGP: list outside denied udp 66.250.59.10(1037) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:26:19.523: %SEC-6-IPACCESSLOGP: list outside denied udp 213.233.121.16(1048) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:31:07.441: %SEC-6-IPACCESSLOGP: list outside denied udp 217.199.33.58(2711) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:32:51.798: %SEC-6-IPACCESSLOGP: list outside denied udp 143.129.135.30(3116) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:40:22.216: %SEC-6-IPACCESSLOGP: list outside denied tcp 62.23.247.212(4389) -> aa.bb.cc.dd(1433), 1 packet
Jan 25 15:42:36.390: %SEC-6-IPACCESSLOGP: list outside denied udp 80.204.93.249(2144) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:44:14.794: %SEC-6-IPACCESSLOGP: list outside denied udp 66.118.149.62(4560) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:44:20.106: %SEC-6-IPACCESSLOGP: list outside denied udp 168.156.116.231(4997) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 15:46:16.508: %SEC-6-IPACCESSLOGP: list outside denied tcp 62.23.247.212(4389) -> aa.bb.cc.dd(1433), 1 packet
Jan 25 15:49:43.431: %SEC-6-IPACCESSLOGP: list outside denied udp 66.191.40.194(4661) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 16:05:18.281: %SEC-6-IPACCESSLOGP: list outside denied udp 193.225.87.91(3061) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 16:08:57.203: %SEC-6-IPACCESSLOGP: list outside denied udp 216.164.244.113(3342) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 16:18:55.364: %SEC-6-IPACCESSLOGP: list outside denied udp 80.146.200.183(3087) -> aa.bb.cc.dd(1434), 1 packet
Jan 25 16:27:28.325: %SEC-6-IPACCESSLOGP: list outside denied udp 66.118.149.248(1874) -> aa.bb.cc.dd(1434), 1 packet
25-01-2003, 18:24 door Anoniem
hmm excuses moest niet worden gepost... wat ff wat aan het knippen en plakken ging verkeerd.
25-01-2003, 19:20 door Anoniem
19:18:45.876491 202.164.168.30.1497 > d80141.upc-d.chello.nl.1434: udp 376
19:18:47.432655 141.84.50.164.1842 > a158236.upc-a.chello.nl.1434: udp 376
19:18:48.284078 80.80.9.5.1073 > a157088.upc-a.chello.nl.1434: udp 376
19:18:48.379164 dhcp-88-06.uni-paderborn.de.1039 > a130209.upc-a.chello.nl.1434: udp 376
19:18:49.290745 c-a0eb72d5.08-60-73746f5.cust.bredbandsbolaget.se.1090 > f72175.upc-f.chello.nl.1434: udp 376
19:18:49.443212 L0962P22.dipool.highway.telekom.at.1091 > e40015.upc-e.chello.nl.1434: udp 376
19:18:52.912994 volta.crmpa.unisa.it.3680 > e180251.upc-e.chello.nl.1434: udp 376
19:18:53.459894 doczy-v2000.drk.hu.2353 > e39145.upc-e.chello.nl.1434: udp 376
19:18:54.917113 160.79.54.42.4834 > e45026.upc-e.chello.nl.1434: udp 376
19:18:55.534608 200.51.197.107.2656 > a155027.upc-a.chello.nl.1434: udp 376
19:18:56.328089 svc1384391.ll.zenon.net.2202 > e182247.upc-e.chello.nl.1434: udp 376
19:18:56.509440 bartgs50.bart.ucl.ac.uk.3435 > a173147.upc-a.chello.nl.1434: udp 376
19:18:57.113379 62.75.136.115.1424 > d93048.upc-d.chello.nl.1434: udp 376
19:18:57.388431 195.141.86.145.36228 > a156064.upc-a.chello.nl.1434: udp 376
19:18:59.536549 61.120.5.243.1139 > d41112.upc-d.chello.nl.1434: udp 376

chello heeft het heel druk nu
25-01-2003, 19:24 door Anoniem
Originally posted by Unregistered
Er gaan maandag gegarandeerd koppen rollen!!


Laat ik nou effe zin hebben om MEE te hakken?!
25-01-2003, 19:48 door Anoniem
ER IS EEN REMOVAL TOOL BESCHIKBAAR VOOR DEZE WORM. MEN KAN DIE DOWNLOADEN VIA ONDERSTAANDE LINK:

http://www.bitdefender.com/virusi/virusi_descrieri.php?virus_id=122

OP DEZE PAGINA STAAT EEN LINK OM DE TOOL OP TE HALEN (ZIP-BESTAND). IS DE COMPUTER NIET GEVOELIG VOOR DEZE WORM DAN WORDT DIT IN DE DIALOOGVENSTER MEEGEDEELD.
25-01-2003, 20:30 door Anoniem
Een TOOL ?

Als je vulnerable bent, ben je daar al ruim achter lijkt me..

Geen dialog voor nodig.
25-01-2003, 21:18 door Anoniem
Originally posted by PatchPaul
Een TOOL ?

Als je vulnerable bent, ben je daar al ruim achter lijkt me..

Geen dialog voor nodig.


Ja, maar sommigen WETEN niet eens dat msql-server op hun computer staat...Dus bedoeld voor de digibeten...!
26-01-2003, 06:05 door Anoniem
Originally posted by Unregistered
ER IS EEN REMOVAL TOOL BESCHIKBAAR VOOR DEZE WORM. MEN KAN DIE DOWNLOADEN VIA ONDERSTAANDE LINK:

Blijf es met je tengels van de caps-lock toets af?
26-01-2003, 11:22 door Anoniem
Originally posted by Unregistered
Sorry, maar daar ben ik het helemaal mee eens. Waarom moet men eerst bij systeem beheer 7 maanden zitten niksen op het zitvlees om er nu achter te komen dat men besmet is met een nieuwe worm. En dat terwijl er sinds 2002 een patch voor bestaat. De dames en heren systeem beheerders (zeg maar gerust AMATEURS) worden heel erg hartelijk bedankt!

Wisten jullie dat bij een boekhoudpakket als Exact Globe voor kleine bedrijven werkt met SQL server (later MSDE) en deze gewoon standaard mee wordt geinstalleerd als Exact wordt geinstalleerd? Daar komt geen systeembeheerder aan te pas en die mensen weten niet eens wat sqlserver of msde is!!! En reken maar dat er heel wat van dat soort boekhoudpakketten draaien hoor, op machines die direct of via een netwerkjes zonder firewall aangesloten zijn op internet, want ook hier worden kant en klare producten verkocht waar ze niks van hoeven te weten om het draaiend te krijgen. Dus het is een beetje kortzichtig om de zogenaamde slapende systeembeheerders de schuld te geven.

Mvg,
Koen Streefkerk
26-01-2003, 13:00 door Anoniem
zo te zien komen er weer meer en meer ongepatchte servers online. De trafic op poort 1434 neem weer toe sinds 09:00

http://www.fect.nl/Traffic.wmf

Frans Egberink
26-01-2003, 14:11 door Anoniem
Originally posted by Unregistered
Wisten jullie dat bij een boekhoudpakket als Exact Globe voor kleine bedrijven werkt met SQL server (later MSDE) en deze gewoon standaard mee wordt geinstalleerd als Exact wordt geinstalleerd? Daar komt geen systeembeheerder aan te pas en die mensen weten niet eens wat sqlserver of msde is!!! En reken maar dat er heel wat van dat soort boekhoudpakketten draaien hoor, op machines die direct of via een netwerkjes zonder firewall aangesloten zijn op internet, want ook hier worden kant en klare producten verkocht waar ze niks van hoeven te weten om het draaiend te krijgen. Dus het is een beetje kortzichtig om de zogenaamde slapende systeembeheerders de schuld te geven.

Mvg,
Koen Streefkerk

Helaas komt dit heel vaak voor! Natuurlijk bedoel ik in voorgaande bijdrage, domme en slaperige systeembeheerders die van de ene problematiek in de andere terecht komen. En wat je bovenstaande bijdrage betreft: nog niet zo lang geleden herinner ik me, dat computergebruikers inderdaad werden opgeroepen om te controleren of dergelijke servers op hun computers waren geinstalleerd.

En dat ik over slaperige systeembeheerders heb gesproken: ik ken een geval van een groot internationaal bedrijf, waar systeembeheer 2 weken lang zat te pitten, terwijl de wereld werd overspoeld met CodeRed worm. En geloof me, systeembeheerders die gewoonweg daar lagen te slapen terwijl iedereen op de alarmknop stond te drukken is gewoonweg voorgekomen. Helaas! Maar het is wel waar.
26-01-2003, 14:25 door Anoniem
Originally posted by Unregistered
En dat ik over slaperige systeembeheerders heb gesproken: ik ken een geval van een groot internationaal bedrijf, waar systeembeheer 2 weken lang zat te pitten, terwijl de wereld werd overspoeld met CodeRed worm. En geloof me, systeembeheerders die gewoonweg daar lagen te slapen terwijl iedereen op de alarmknop stond te drukken is gewoonweg voorgekomen. Helaas! Maar het is wel waar.

Ik kan dit helaas alleen maar bevestigen.

Als je kijkt naar de IP adressen waar de aanvallen vandaan komen dan zie je daar ook bekende namen van root servers als YaHoo en Tucows langskomen.

Dat zijn toch bedrijven die de gevaren zouden kennen.

Frans Egberink
26-01-2003, 17:05 door Anoniem
"Als je kijkt naar de IP adressen waar de aanvallen vandaan komen dan zie je daar ook bekende namen van root servers als YaHoo en Tucows langskomen. "

Als je kijkt naar de analyse van deze worm dan blijkt dat de IP adressen gespoofed worden..
26-01-2003, 20:07 door Anoniem
Originally posted by Unregistered
[BAls je kijkt naar de analyse van deze worm dan blijkt dat de IP adressen gespoofed worden.. [/B]

en als je dan een portscan doet dan blijken er juist op die servers poort 1434 open te staan.

Frans Egberink
26-01-2003, 22:41 door Anoniem
Hai mijn internet doet een beetje raar al 4 dagen als ik de pc opstart doet het internet 5 min ongeveer en dan niet meer en als ik hem weer opnieuw opstart doet het weer 5 mijn dan weer niet kunnen jullie me daarbij helpen kan het die virus zijn die zaterdag is ontdekt ?? ALvast bedankt..

Groetjes,,,
26-01-2003, 23:59 door Anoniem
Originally posted by tufan
Hai mijn internet doet een beetje raar al 4 dagen als ik de pc opstart doet het internet 5 min ongeveer en dan niet meer en als ik hem weer opnieuw opstart doet het weer 5 mijn dan weer niet kunnen jullie me daarbij helpen kan het die virus zijn die zaterdag is ontdekt ?? ALvast bedankt..

Groetjes,,,

het lijkt erop dat je computertje flink pakketjes aan het spuwen is waardoor je internet niet meer lijkt te werken
dit probleem heb je alleen als je SQLserver heb draaien, oplossing is dan SP3 installeren en je computer rebooten
Als je dat niet lukt, sqlserver uninstallen
als dat niet lukt je kabel eruit trekken en nooit meer vast maken.

NB bij visual studio .NET wordt standaard ook een SQLserver desktop engine geinstalled. ook een puntje van aandacht waard
27-01-2003, 11:41 door Anoniem
Originally posted by Unregistered
Als je het een beetje serieus doet, staat je SQL in het LAN, je webdoos in de DMZ, en is de webdoos echt alleen maar op poort 80/443 te benaderen. De SQL is dan vanuit internet helemaal niet te bereiken, tenzij iemand via de webdoos weet in te breken (en ja, die webdoos moet dus wel heel goed dicht zitten, liefst geen ASP draaien enz.).

'Gelukkig' zijn er veel tentjes die uit kostenbesparing zowel SQL als IIS op 1 en dezelfde doos gooien, en die ook nog in de DMZ zetten

Het maakt voor deze worm niet uit of SQL nu in de DMZ of in het LAN staat als je de betreffende poorten maar blokkeert.

Als de webapplicatie (asp/php/whatever) gehackt wordt, wil je niet dat je server een link 'naar binnen' heeft. Zit een hacker eenmaal op je webserver, dan zou hij via de SQL server in het LAN je bedrijfsnetwerk binnen kunnen komen. Dus SQL in het LAN zetten lijkt me niet handig.

DMZ->LAN verkeer zou in principe niet moeten/mogen...
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search