Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 120 reacties

Een worm gebruikt Microsofts Remote Desktop Protocol om zichzelf te verspreiden. Voor zover bekend gaat het om de eerste worm die dat protocol gebruikt. Volgens Microsoft is de worm in staat om dos-aanvallen te verrichten.

Volgens F-Secure is het de eerste keer dat een worm het Remote Desktop Protocol van Microsoft gebruikt om zichzelf te verspreiden. De malware verspreidde zich niet dankzij een kwetsbaarheid in rdp; de worm probeert op andere pc's in te loggen met een lijst van standaardaccounts en -wachtwoorden als 'test', 'user', '1234' en 'letmein'. Volgens Microsoft is de worm in staat om denial of service-aanvallen uit te voeren, al is onduidelijk of dat ook daadwerkelijk is gebeurd.

Hoeveel computers zijn geïnfecteerd met de worm, die de naam Morto draagt, is onbekend, maar het Internet Storm Center maakt melding van een grote stijging van het aantal computers dat portscans op poort 3389 uitvoert. Inmiddels lijkt het aantal sources dat rdp-portscans uitvoert fors te verminderen; waarschijnlijk komt dit doordat virusscanners de worm beginnen te detecteren. In ieder geval Microsofts eigen beveiligingssoftware is zo bijgewerkt dat deze het virus kan verwijderen.

Volgens Microsoft zoekt de worm verbinding met een aantal servers, zo blijkt uit een analyse die het bedrijf online heeft gezet. Een deel van die servers lijkt inmiddels offline. Vreemd genoeg behoort het ip-adres van een van de servers waarmee Morto volgens Microsoft contact zoekt toe aan Google. Een ander ip-adres dat zou worden gebruikt eindigt op '820', wat een ongeldige cijfercombinatie is.

Scans RDP

Bron: Internet Storm Center

Moderatie-faq Wijzig weergave

Reacties (120)

Alle te raden wachtwoorden waren dit:
*1234, 0, 111, 123, 369, 1111, 12345, 111111, 123123, 123321, 123456, 168168, 520520, 654321, 666666, 888888, 1234567, 12345678, 123456789, 1234567890, !@#$%^, %u%, %u%12, 1234qwer, 1q2w3e, 1qaz2wsx, aaa, abc123, abcd1234, admin, admin123, letmein, pass, password, server, test, user
Het zijn bijna allemaal wachtwoorden die op een rijtje op het toetsenbord zitten, 1qaz2wsx is bijvoorbeeld begonnen bij 1 en dan een rijtje naar beneden, met daarna de 2. Het is natuurlijk ook erg zwak, en word je bij elke attack die gewoon bruteforce gebruikt gehackt.

Ook behoorlijk veilige systemen zoals Linux zijn zo te kraken met zo'n wachtwoord als root password, kijk maar eens hoe veel bruteforce attacks er op ssh uit worden gevoerd.

[Reactie gewijzigd door marcop23 op 29 augustus 2011 12:28]

In navolging:

het is NIET alleen het admin-account dat gebruikt wordt, de volgende useraccounts worden ook uitgeprobeerd volgens één van de beheerders van een RDP-server op iss.sans.edu:
1
123
a
actuser
adm
admin
admin1
admin2
administrator
aspnet
backup
console
david
guest
john
office
owner
reception
root
server
sql
support
support_388945a0
sys
test
test1
test2
test3
user
user1
user2
user3
user4
user5
ook hiervoor geldt weer dat het allemaal redelijk basale accounts zijn (SQL, Support, Console, etc)

[Reactie gewijzigd door tes_shavon op 29 augustus 2011 12:53]

het zijn ook de combinaties die de "downloadversies" gebruiken van windows.
En aangezien 80% van die downloaders ook niet verder kijken dan het buroblad aanpassen, staat vaak de pc wagenwijd open hierdoor
"Het is natuurlijk ook erg zwak, en word je bij elke attack die gewoon bruteforce gebruikt gehackt."

Een bruteforce attack gaat elke mogelijkheid af. Wat jij bedoeld is een Dictonairy Attack een hybride varriant.
Het "probleem" is dus op te lossen wanneer iedereen fatsoenlijke wachtwoorden gebruikt..... Kom op zeg.... 12345 is toch geen wacht woord meer in de huidige tijd.

De Worm doet niets anders dan simpele voorgeprogrameerde toetsenboardcodes uitvoeren, wanneer je als gebruiker/admin dan zelf zo onhandig bent om een heel eenvoudig te raden wachtwoord gebruikt ben je in mijn ogen deels zelfs schuldig.
12345 als wachtwoord, dan ken je je klassiekers.
Tsjah, dan moet je de boel zo configureren dat na 3 foute pogingen het account geblokeerd wordt. En natuurlijk "sterke" wachtwoorden afdwingen.
Dit is alles? Kan er zo zonder al te lang over na te denken nog veel meer standaard pwds bedenken om te proberen. Dingen als %u%12 lijken me weer ernstig onwaarschijnlijk.
Ik denk dat de software bij %u% het omgevingsvariabele van de gebruikersnaam invult, ik kom vaak zat configuraties tegen waarbij het wachtwoord hetzelfde is als de gebruikersnaam (bijv. laatst nog: username: magazijn, password: magazijn 8)7 , waarbij je met dezelfde credentials ook op het "magazijn" account van de server (DC) kunt, op de server staat RDP voor de hele wereld open, prima target voor deze worm ;( ).

[Reactie gewijzigd door donny007 op 29 augustus 2011 12:53]

Kijk dan maar eens op een AZERTY toetsenbord.
Er is dus geen exploit in het RDP. Een goed wachtwoord is dus de oplossing. Is dit dan geen storm in een glas water?
Niet meer dan andere exploits die van slechte wachtwoorden en gebruikers-acties gebruik maken.
En dan nog is dit een eesrste die van RDP(-gedrag) gebruik wil maken. Ik weet dat bij heel veel bedrijven RDP niet geblokkeerd wordt. En dus een optie is voor exploits.
Zoals die SQL worm die installaties zonder SA wachtwoord infecteerde in het verre verleden.

Bedrijfen zijn overigens vaak niet de "doelgroep". Bedrijven hebben een wachtwoord beleid en virusscanners die beheerd worden door systeembeheerders.

Wachtwoorden zoals hierboven beschreven worden ook niet geaccepteerd binnen een standaard Windows domein.
Plak 'vaak' tussen je tweede paragraaf en je hebt gelijk.
Een van die wachtwoorden komt mij namelijk bekend voor van een van mijn vorige opdrachtgevers.
I kid you not! :+
Op zich is het verbazingwekkend dat er nog niet eerder zo'n worm gesignaleerd is.

Maar met een firewall zul je al meteen een stuk beter beschermd zijn. De meeste particulieren hebben die poort toch niet openstaan.

Tip: verander de naam van het administrator account in iets wat een doorsnee gebruiker zou kunnen zijn. Zet er een sterk wachtwoord op en vernieuw het regelmatig. Op die manier krijg je minder aanvallen op je admin account. Verander ook de beschrijving van het account, anders is het nog zo duidelijk dat het toch een admin account is. Stel vervolgens een zeer beperkt account in met de naam administrator en de bijbehorende omschrijving. Zelfs al kraken ze dat nep admin account dan nog kan men niet zoveel.
Zo verbazingwekkend vind ik het niet. Als je iemand's wachtwoord weet, kun je namelijk via iedere service inloggen die open staat. RDP is dan een heel onlogische keuze, omdat het lastig is om iets te doen als je een desktop moet besturen waarvan je niet precies weet wat er op staat. Via een commandline-achtige interface werken, zoals met ssh, is dan veel makkelijker, omdat een commando altijd werkt, en gesimuleerde muis- en keyboard-input afhankelijk is van wat iemand op z'n desktop heeft.
Het verbaasd me niet zo veel dat er nu dan een worm is die het wel gebruikt, maar een logische keuze vind ik het niet. Ik denk dat de grootste reden om voor dit protocol te kiezen moet zijn geweest, dat het vaak open staat. Dingen als smb kom je meestal niet bij van buitenaf.
Autohotkey scriptje. Send Winkey-R, "cmd", enter. En dan heb je je console.
Bedrij[b]v[/v]en hebben meestal geld, en willen dat meestal houden en niet uitgeven aan dingen als 'beleid waar werken moeilijker door wordt'. Dat zijn dus alle non-large-coprorates. En dat zijn er best veel. Zeker wel een doelgroep, en er is zeker ook veel te halen.
Zoals die SQL worm die installaties zonder SA wachtwoord infecteerde in het verre verleden.
Je bedoeld SQL/Slammer? die had een kleine bijkomstige narigheid, die genereerde verkeer van een bepaalde aard waardoor complete netwerken onderuit gingen omdat de switches crashten.
Als je het zo stelt niet nee. Als je kijkt naar hoe wijd verbreid RDP is, is het misschien erger. Ik bedoel, die service draait gewoon als je computer aan staat en is dus altijd te bereiken. Daarmee is het wel degelijk nieuwswaardig, aangezien het risico behoorlijk groot is als er slechte wachtwoorden gebruikt zijn. Wat ik wel kwalijk vind is dat het juist bij een dergelijk cruciale netwerktechniek (met grote gevolgen) mogelijk is een dergelijk paswoord te gebruiken. Microsoft zou er toch best toe over kunnen gaan bepaalde paswoorden op een blacklist te zetten...
99,9999999999 van de consumenten zit achter een router met NAT. Dus die RDP-poort staat gewoon netjes dicht. Bovendien moet je het expliciet aanzetten.
Kennelijk is de worm eerder op bedrijven gericht. Kennelijk zijn sommige bedrijven zo dom om rechtstreeks verkeer op poort 3389 door te laten. Zelf gebruiken we al jaren VPN's en SSH-tunnels voor dat doel.
Er is niks dom aan om 3389 open te zetten. Rdp is ervoor bedoeld en geencrypted. Er zijn niet eens exploits bekend. Wat ze hier zeggen is dat er ma ware is die standaard wachtwoorden uitprobeert. Vrij zinloos want na x inlogpogingen wordt een account x minuten geblokkeerd.
Vertrouwen op de veiligheid van de RDP server code en op de sterkheid van wachtwoorden is echt niet voldoende. Je kunt beter het zekere voor het onzekere nemen en ook nog eens achter VPN's kruipen.
Dat is hetzelfde als zeggen dat VPN en sterke wachtwoorden echt niet voldoende is...
Dat is het ook niet. Ga na hoe vaak gebruikers wachtwoorden met elkaar delen. Soms staan wachtwoorden gewoon op een geeltje aan de monitor geplakt.

Als een medewerker wachtwoorden kent van collega's en die medewerker wordt ontslagen, dan kan hij de wachtwoorden van de collega's gebruiken om wraak te nemen. Om van buitenaf binnen te komen raad ik echt twee autenthicatie methoden aan waarbij 1 smartcard/token
En dan moet HR natuurlijk ook direct aan de ICT dienst melden wanneer zo'n token inactief geschakeld moet worden - wat ook lang niet altijd gedaan wordt. Zwakste schakel in ICT beveiliging is altijd de gemakzucht van de gebruikers en beheerders. Daar helpen geen 100 firewalls tegen.
Je hebt liever niet teveel protocollen met hun eigen inlognamen en wachtwoorden naar buiten toe openstaan, elke extra loginpoort die openstaat biedt extra kansen op exploits en simpelweg op bots die wachtwoorden gaan proberen te raden.
Onzin, ik ken genoeg mensen die direct met hun kabelmodem op internet zitten.
Ik weet niet of het met allemaal zo is, maar er zijn in ieder geval zat modems die eigenlijk gewoon 1 poort routers zijn, en dus wel effectief achter een router zitten. Dan willen ze meer computers erachter hebben en kopen ze dus een router, en begint het port forwarding gezeik.
Overdrijven is ook een vak hoor....

Standaard staat RDP uit. Je moet zelfs nog specifiek aangeven welke gebruikers er mee mogen inloggen.

Als je dan een zo makkelijk te raden passwords gebruikt, dan is het écht gewoon je eigen schuld.
Naast een goed wachtwoord en een goede inlognaam (die niet op je visitekaartje staat) is het ook aan te bevelen om poort 3389 dicht te zetten en bijvoorbeeld poort 4000 door te laten sturen naar 3389 aan de binnenkant.
Je mag niet zomaar poortnummers bedenken, daar zijn standaarden voor, die worden centraal uitgedeeld.

Bovendien is dit security through obscurity. Een slimmerik (en dat zijn ze) scant alle poorten op zoek naar eentje die open staat, en analyseert dan challenge/response wat er op die poort leeft.
Ja maar als je poort 8 - 65535 moet scannen van elk IP ben je wel even bezig. Een hacker die het op RDP heeft voorzien zal dus alleen de standaard poort scannen.

Ik zet SSH ook altijd op poort 55522 en heb er nooit scans op, anders dan op 22.
Je mag niet zomaar poortnummers bedenken, daar zijn standaarden voor, die worden centraal uitgedeeld.
Tuurlijk mag dat wel. Het zijn geen prescriptieve standaarden. Het zijn descriptieve standaarden. Je moet alleen niet verbaasd zijn wanneer sommige produkten niet compatibel zijn. Puur "omdat het de standaard' is, is op zich geen voldoende reden om iets wel/niet te doen. Je mag best zelf kiezen welke standaarden je wel en niet implementeert.

RDP op een andere dan standaard-poort draaien is een prima middel voor een huis-, tuin- en keukenservertje om wat minder vaak lastig te worden gevallen. Als het om professionele omgevingen gaat, dan kun je het inderdaad beter standaard laten en op basis van VPN/Firewall oplossingen werken.

Of het "security-through-obscurity" is? Ach, het is niet zozeer security op zich, als een methode om het aantal aanvallen te verminderen. Ik zie geen enkele reden waarom dat kwaad zou kunnen. Zoals al eerder gesteld, het is niet alsof RDP protocol zelf kwetsbaar is, dus je hebt precies dezelfde security als op een standaard poort. Wat dat betreft maakt dit niks uit.
en een niet te vermijden oplossing als je thuis 2 of meer apparaten hebt staan die je met hetzelfde protocol wilt benaderen.
Of door gewoon de poort die voor RDP wordt gebruikt aan te passen...
Helaas is de perceptie die ontstaat dat er een exploit is. Zo vind ik dat de berichtgeving in de algemene (niet op ict-kenners) gerichte media er wel erg vaak naast zit. beetje zoals dit.
Al vanaf het moment dat RDP beschikbaar kwam voor Windows heb ik het van mijn systemen verwijderd uit veiligheidsoogpunt. Het heeft lang geduurd, maar ik blijk toch nog niet zo gek te zijn geweest.
Nou ik vind je wel degelijk gek als een deur hoor!

Als ik op alle servers fysiek moest inloggen om iets uit te voeren, was ik nog niet jarig..

Dat verkeer blokkeer je niet op je hosts maar gewoon op je firewall. Daarnaast gebruik je een degelijk wachtwoord. EN zorg je dat een account na een aantal x wordt geblocked.

Als je het echt goed doet, is er niet een actief administrator account. Die disable je en je maakt een aantal domain admins aan.

[Reactie gewijzigd door Ghost21 op 29 augustus 2011 12:56]

Misschien gebruikt hij teamviewer ofzo. Lekker je servers beheren via 3de partij.
Wat je ook kan doen is in het register de poort van rdp server veranderen naar iets anders zodat je hier geen last meer van hebt.
Alleen moet je dan wel alle legitieme clients aanpassen zodat ze niet meer over de default poort 3389 gaan. Niet erg handig, om het maar zacht uit te drukken.

Handiger lijkt me gewoon sterke wachtwoorden gebruiken, dan is deze worm dus meteen kansloos om binnen te komen.

Behoorlijk amateuristisch aanpak van deze worm eerlijk gezegd. Dit is nu niet bepaald het meest enge, schadelijke stukje malware...
Makkelijker is om met NAT een forward van een andere poort naar 3389 te geven.
Dan hoef je alleen van buitenaf nog rekening te houden met een aparte poort.
Maar voor een bedrijfsnetwerk lijkt het me handig om die van buiten geheel dicht te houden en de poort als policy te veranderen op de clients (of gewoon een ander remote desktop programma te gebruiken).

Wel grappig/eng om te zien als je 3389 in je router openzet dat je allemaal hits krijgt in je firewall.
Soms kan je dan op dat IP met RDP verbinding leggen en dan zie je een Russische Windows 2003 ofzo.
Inderdaad ik hoop dat bedrijven die werken met RDP ook een soort van VPN oplossing gebruiken... Voor consumenten ligt dat iets anders natuurlijk
Om RDP poorten te veranderen heb je toch gewoon GPO's voor (registeraanpassingen doorvoeren kan ook via GPO's)
De windows remote desktop client accepteert gewoon host:poort, dus het is wat dat betreft geen probleem om een afwijkende poort te gebruiken.
Als je niet van buiten RDP't in de router 3389 forwarden naar een niet gebruikt IP adres.
Dan kun je hem net zo goed dicht laten staan???
Security through obscurity. Met een simpele poortscan val je al door de mand.
Lijkt me het werk van redelijk amateuristische "hackers"
De worms van vandaag zijn heel wat geavanceerder, en een IP met een cijfer in de 800 range? 8)7

Zowiezo is het aan te raden om poort 3389 te blocken en RDP op een andere te draaien.
Hoe kom je er bij dat het amateurs zijn als ze het wel voor elkaar krijgen om een IP adres in de 800 range te krijgen. Ben zelf geen hacker en niet zo bekend met IP ranges, maar als het een onbekende range hebben ze het toch wel goed voor elkaar denk ik zo.
ehrmmm.....

omdat de range TOT 254 loopt ?
van 0.0.0.0 tot 254.254.254.254 ...
Correctie: tot 255. 2 tot de macht 8 is 256. Omdat we niet bij 1 maar bij 0 beginnen is de maximum waarde dus 255. In de praktijk kom je 255 niet vaak tegen in een host adres, maar het is een geldige waarde in een IP adres.
jep.

10.255.255.254 als ook 10.254.255.255 zijn prima ip-adressen (bij een subnetmask van 255.0.0.0)
.255 wordt meestal gebruikt als broadcast adres, het is niet verstandig om .255 uit te delen aan een host.
nee hoor ... alleen als je de eerste 24 bits gebruikt worden voor het subnet is 255 het broadcast-adres, met minder dan die 24 kan het prima.

[Reactie gewijzigd door tes_shavon op 29 augustus 2011 12:47]

Per octet tot en met 255, om precies te zijn (2^8 -1).
Een adres als 10.10.255.1 is geldig.
Ik heb ooit x.x.x.255 als webserver adres van een ISP gekregen. Dat werkte inderdaad niet :-)
Zonder de netmask te noemen weet je niet of het juist is. Het hoogste (broadcast address) en het laagste IP address (netwerk address) uit een reeks kunnen niet gebruikt worden.

Zo zou je uit de reeks 10.0.0.0/8 prima 10.10.10.255 kunnen gebruiken als geldig IP address.

Overigens begrijp ik niet hoe zinvol die 820 is, een simpele nslookup geeft er in ieder geval geen resultaat op....
Een uitleg kan zijn dat je de laatste byte gewoon laat overflowen naar de voorlaatste byte. Een andere uitleg kan zijn dat je gewoon een mod255 operatie krijgt (je neemt gewoon de laagste byte van het getal). Afhankelijk van de omzetting van de string naar het 4 byte IP veldje van de header.

[Reactie gewijzigd door High-Voltage2 op 29 augustus 2011 12:42]

Kan inderdaad:

http://213.239.39459

Bovenstaand IP gaat ook naar tweakers. De laatste byte als 255 is officieel een broadcast in het locale net als je subnet 255.255.255.0 is.

http://en.wikipedia.org/wiki/Broadcast_address
http://213.239.39459:

Wrong host
The host 213.239.154.35 is not known on this location
Apache at tweakers.net (Abaris)
het laatste byte overflowen naar het voorlaatste byte is niet mogelijk omdat je dan de voorgaande waarde aantast. Het "ip" 210.3.38.820 bestaat uit 3 keer 8 bits gevolgd door 1 keer 10 bits, terwijl het IP veld in een header uit 4 keer 8 bits bestaat.

Het zal dus ongetwijfeld een typo zijn, want in een IP header past het gewoon niet.

@hierboven, wat jij doet is gewoon het binair aan elkaar plakken van de laatste twee octetten:
154 = 10011010
38 = 00100011
39459 = 1001101000100011
Dit is dus geen overflow, je mist alleen decimaal de scheiding tussen de laatste 2 octetten.
Als je het volledige IP binair aan elkaar plakt (11010101111011111001101000100011) en omzet naar decimaal krijg je http://3589249571, dit is dus GEEN overflow, de scheiding ontbreekt alleen; het blijven gewoon de originele 32 bits.

[Reactie gewijzigd door axel_007 op 29 augustus 2011 14:01]

Dan hebben ze het toch goed voor elkaar om het in de 800 te krijgen en dus waarschijnlijk niet herleidbaar ?

[Reactie gewijzigd door Ventrigo op 29 augustus 2011 12:32]

Nee, ze proberen te verbinden met een computer mbv een onmogelijk IP-adres. Oftewel het zal nooit lukken. Lijkt me trouwens een typo, extra 0 achter 82
Nee want het is gewoon niet mogelijk... Je hebt maar 254 mogelijkheden. Wat is het? 8 bits per getal?

Ik dacht persoonlijk dat 255 gereserveerd was, zoals ik hieronder lees is dat niet het geval.. Het moet dus 255 zijn

[Reactie gewijzigd door Mellow Jack op 29 augustus 2011 12:38]

Eigenlijk heb je 256 mogelijkheden omdat je ook de 0 mee moet tellen, en 255 gereserveerd is zoals je zegt.

Vreemd dat de worm verbinding zoekt een ip adres van Google
Sorry dat je vanaf 0 moet tellen had ik inderdaad al als algemene kennis meegenomen :P
het is compleet onmogelijk om een ip in die reeks te krijgen en al heb je er een dat kan je er niks mee
De range loopt tot 255

Verder zijn er best wel applicaties die IP nummers in tekstvorm afkappen op 8 bits (per adresbyte) voor getallen > 255; die 820 wordt dan 52.
Ze hebben het zo voormekaar dat ze de boel weten te foppen met een ongeldig IP adres. I sdat nu zo lastig te begrijpen?
Je bedoelt "onmogelijke" range? het gaat maar tot 255 namelijk (255 is broadcast)
Waarom? Dit de-standariseert je omgeving alleen maar. Gewoon deugdelijke wachtwoorden hebben. :)
Want je kunt niet instellen in je netwerkpolicies dat je een andere poort gebruikt?
Het is gewoon algemeen bekend dat de oude RDP proto's niet veilig zijn, maar die lopen wel gewoon over 3389.. dan is het een uitstekend idee om een niet-standaard poort te gebruiken.
Een nog uitstekender idee is om alleen veilige protocollen te gebruiken. Toen ik een eigen studentenservertje had draaien op de universiteit, werd je dezelfde dag nog van de switch afgesmeten als je een bekende service niet op de daarvoor toegewezen poort had draaien. Policy van de netwerkbeheerders, niemand ontkwam eraan :')
En het word er veiliger op als je over een andere poort laat lopen? Als je RDP niet veilig genoeg acht moet je het uberhaupt niet gebruiken want als iemand echt wat wil zijn ze 1 poortscan verwijderd er alsnog achter te komen waar je machines op lopen. Vind het een beetje symptoombestrijding. Iemand die zich laat tegenhouden door een ander poortje is uberhaupt niet in staat RDP te misbruiken.
"de worm probeert op andere pc's in te loggen met een lijst van standaardwachtwoorden, zoals 'test', 'user', '1234' en 'letmein'"

Tja, je kunt beveiligen tot je een ons weegt maar met dat soort beveiliging is het dweilen met de kraan open. |:(
Bij winxp heeft de administrator account geen wachtwoord, en het komt zelfs bij bedrijven voor dat deze niet is afgeschermd.

En vervolgens vragen mensen zich af hoe je toegang tot de pc hebt gekregen.


@onder
Ging me meer om fysieke toegang.
Vervolgens kun je vb je mail checken. Maar je kunt het ook misbruiken.

[Reactie gewijzigd door Iblies op 29 augustus 2011 13:06]

alleen mag je niet via RDP inloggen zonder wachtwoord ;)
Dat wachtwoord moet je normaal instellen bij installatie. Het is echter niet verplicht, dus iemand die next next next doet vergeet dat natuurlijk... Hoe het zit met voorgeinstalleerde versies of automatische instal scripts, geen idee.
Zonder wachtwoord op het account kan je geen RDP verbinding maken.
Daarbij komt ook nog dat de meeste bedrijven deze standaard admin account met policies uitschakelen en een ander local admin account aanmaken.
De worm zou proberen in te loggen als Administrator. En die kan bij ons niet RDP-en, dat heb ik uitgeschakeld (via group policies), en het wachtwoord ervan laten genereren om dit soort dingen een beetje tegen te gaan.
Maarre, wie een wachtwoord op die lijst als administratorwachtwoord instelt verdient het bijna om zo'n virus op z'n dak te krijgen. :X

Er staat in dat bronartikel van F-Secure trouwens dit:
Once you are connected to a remote system, you can access the drives of that server via Windows shares like \\tsclient\c and \\tsclient\d for drives C: and D:, respectively
Dat zijn de schijven van de client, als je ervoor kiest die te delen in je sessie, niet de schijven/partities van de server. Rare fout van dat artikel.

[Reactie gewijzigd door Cyphax op 29 augustus 2011 12:21]

UIt het gequote stukje staat volgens mij \\tsclient\c voor de c: schijf van de terminal client die uiteindelijk gewoon op de server staat?
Open die "share" maar eens dan, dan kom je op de c-schijf van de computer waar je verbinding mee maakt, niet op de c-schijf van de server. Ik iig wel. :+

Of die worm moet dat zo doen maar dat zal wel niet lijkt me.
Als die worm zich wil verspreiden kan ik me voorstellen dat ie een share maakt, en zichzelf naar het doelsysteem kopieert. Maar 't zou ook om een foutje kunnen gaan.

Edit: typo

[Reactie gewijzigd door Flight77 op 29 augustus 2011 12:35]

dat is natuurlijk wel afhankelijk van de instelling voor het delen van resources vanaf de client. Als je dat niet aan hebt staan dan heb je die share niet. Het is wel een instelling die de client zelf bepaald.
Als client vraag je die share inderdaad aan, maar dit kan op de server uitgeschakeld zijn eventueel via policies.

Dit kan een beveiliging zijn om geen data van de server te laten copieren naar de client PC.
Bij mij werkt dat -gelukkig- niet, in geen van beide richtingen. Google leert mij dat tsclient hoort bij Citrix.
Probeer c$ ipv gewoon c... Windows variables moeten toch gewoon werken in die omgeving :P
Doet ie dat bij jou wel dan? C$ werkt hier ook niet.
Veel Windows computers hebben shares voor alle lokale schijven maar dan met een dollar erachter. Met een dollar kun je namelijk een share "verbergen"
En probeer die maar een uit te zetten :(
Om de haverklap komen ze weer terug omdat Microsoft vindt dat ze 'nodig' zijn.

@jvdmeer: Leuk en aardig, maar na een service-pack en sommige updates staan ze gewoon weer aan. zoals gezegd "Microsoft vindt dat ze 'nodig' zijn."

[Reactie gewijzigd door Roland684 op 29 augustus 2011 14:17]

Als ik het goed begrijp is er dus geen enkel probleem indien je maar een sterk wachtwoord hebt. In andere woorden, een storm in een glas water...
Het blijft natuurlijk wel vreemd dat je een hele lijst mag proberen.
Het is dan gewoon een kwestie van (heel veel) tijd voordat inloggen een keer lukt.
En als er foutjes in zitten waardoor een wachtwoord dat helemaal fout is net iets sneller wordt afgekeurd dan een wachtwoord dat wat minder fout is, is ook een sterk wachtwoord vrij snel gekraakt.
Niets aan de hand dus, want het doet automatisch wat een kwaadwillende met de hand zou proberen. Gewoon deugdelijke wachtwoorden hebben wat überhaupt al zo zou moeten zijn en er is niets aan het handje. :)
hmm that's why... Ik had inderdaad ook vele aanvallen op men rdp connectie. Heb ondertussen van poort veranderd, zodat we niet meer de default poort gebruiken.
Ik vond het al gek, nooit geen last van gehad.

Thanks tweakers voor de info :)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True