Roemeense hackers braken in op Xs4all-server

Roemeense hackers hebben in december 2011 ingebroken op een shellserver van Xs4all. Ze kregen versleutelde wachtwoorden van systeembeheerders in handen, maar wisten ook van 30 gebruikers wachtwoorden onversleuteld af te luisteren.

Xs4all denkt dat de hackers er in slaagden de getroffen machine, xs3.xs4all.nl, via een bekende exploit te benaderen. De Roemenen kregen het systeembestand met accountgegevens en versleutelde wachtwoorden van de systeembeheerders in handen en publiceerden die op internet.

Ze slaagden er echter ook in het systeemprogramma voor ssh-toegang aan te passen, licht Jacques Schuurman, Security Officer bij Xs4all toe. De gegevens van dertig gebruikers die in de periode van de hack via ssh verbinding maakten, werden daarna door de hackers gekopieerd naar een speciaal daartoe ingericht bestand. Zo kregen ze de inlognaam en het onversleutelde wachtwoord in bezit.

Schuurman kan niet zeggen hoe lang de hack onontdekt is gebleven: "Afgaande op het feit dat er in die periode dertig klanten inlogden, denk ik een paar dagen. Na de ontdekking hebben we het systeem direct offline gehaald." De wachtwoorden van de systeembeheerders zijn daarna gewijzigd en de Security Officer denkt ook niet dat de hackers deze gekraakt hebben: "Die zijn wel zo sterk dat ze daar een aantal jaren voor nodig hebben." Voor overige klanten heeft de hack geen impact, verzekert hij.

De getroffen dertig klanten zijn per mail en telefonisch ingelicht en verteld dat ze hun wachtwoorden moesten wijzigen. Daarbij stelde de provider een deadline: accounts die na die periode niet van een gewijzigd wachtwoord voorzien waren, werden geblokkeerd. De reden dat de hack nu pas naar buiten komt is volgens Schuurman dat het onderzoek plaatsvond ten tijde van het opstellen van het jaarverslag over 2011: "We melden dit soort privacyinbreuken in het jaarverslag. Dit voorval komt dan ook in het verslag van 2012. Ook heeft onze privacyofficer uitgebreid verslag gedaan in zijn logboek." Xs4all claimt de monitoring en beveiliging aangescherpt te hebben na de hack.

Reacties (86)

[CaptJackSparrow]

De reden dat de hack nu pas naar buiten komt is volgens Schuurman dat het onderzoek plaatsvond ten tijde van het opstellen van het jaarverslag over 2011

Volgens mij is de reden dat ze het nu *al* gemeld hebben dat een XS klant op 23-2-2012 in de nieuwsgroep xs4all.general melding maakte dat hij een site gevonden had met zijn password.

Wat is dit voor site en hoe komen ze aan mijn password?

Toen moest XS wel met de billen bloot maar ik heb sterk de indruk dat het anders pas in een hoekje van het jaarverslag over 2012 gemeld zou zijn dat neem ik aan ergens in 2013 uit zal komen.

[The Jester]

Ze communiceren in ieder geval een stuk beter dan hun moeder (KPN).

[Zer0]

Ze communiceren in ieder geval een stuk beter dan hun moeder (KPN).

Ik heb er anders niks van gezien op de pagina's van XS4ALL, en als ik het artikel mag geloven zou XS4ALL het pas in het jaarverslag van 2012 (wat pas aan het einde van het jaar verschijnt) naar buiten brengen.
Nu kun je wel zeggen dat het om "maar" 30 accounts gaat, maar dat is alles waar XS4ALL van weet, wellicht zijn er meer, en als klant had ik dus ook graag in december al een mail/telefoontje gehad met de suggestie mijn wachtwoorden te wijzigen.

[Verwijderd]

als klant had ik dus ook graag in december al een mail/telefoontje gehad met de suggestie mijn wachtwoorden te wijzigen.

En nu je het weet kun je uit voorzorg je wachtwoord wijzigen (als je echt klant bent, natuurlijk, maar dan had je wel "als ik klant zou zijn" neergezet). Dat zou je zowiezo eens in de zoveel tijd moeten doen, gebruik zelf wachtwoorden zo goed als nooit langer dan 72 dagen) ...

niks van gezien

Ik kan me wel iets herinneren over onbeschikbaarheid van specifieke ssh servers. Maar dat was tijdens het inloggen op een van de servers in december. Ik log nog steeds regelmatig in.

Maar het is voor mij duidelijk dat het voor XS4all duidelijk is dat het door onderzoek duidelijk is dat de inbraak beperkt gebleven is tot deze ( customer facing ) shell server. Onderzoek zal uitgewezen hebben dat alleen deze ene server getroffen is.

Het is mij ook duidelijk dat de getroffen accounts tijdig ingelicht werden/zijn.

Maar als je klant bent, kun je je grieven en ideeen hierover kwijt bij XS4all hoor.. https://yellowspaces.xs4all.nl

[arjankoole]

Je kan precies zien wie er ooit gebruik hebben gemaakt van die server. Als jij - zoals ik - nooit op xs3 bent geweest, is er geen enkel risico.

[DFyNt2U]

Ja dat viel me ook op.

Ze hebben het wel niet in december publiek gemaakt, maar wel eerder die 30 klanten benaderd, zelfs telefonisch. Natuurlijk niet enorme aantallen.
Ik vraag me af of ze de hack ook nog bij het CBP gemeld hebben, dan zou het helemaal perfect zijn.

Het verbeteren van de monitoring zou idd wenselijk zijn, want het is jammer dat ze niet kunnen bepalen hoe lang men toegang had tot het systeem.

Shit happens. Moving on.

[Verwijderd]

XS4ALL doet conform het privacy reglement niet aan actieve monitor op wat klanten op het systeem doen. Je hebt als klant privacy in tegenstelling tot bijvoorbeeld UPC/Ziggo dus actief monitoren wat jij doet op het internet.

Waarom zou alle 300.000 klanten moet informeren waarvan 95% niet eens weet wat een shell server is dat er een incident is geweest waar 30 klanten bij betrokken zijn geweest.

[harydoo]

Als de wachtwoorden versleuteld zijn zou ik nog wel willen op welke manier. Een quote met: "Die zijn wel zo sterk dat ze daar een aantal jaren voor nodig hebben" verteld mij nog niet zoveel.

Ergens heb ik wel vertrouwen in XS4all vanwege hun achtergrond. Maar deze sympathie zal toch meer rusten op een vertrouwenskwestie dan feiten.

[defixje]

Zie ook zijn posts in 1 bestand.

http://docsbird.com/?p=ge...9a6de08b6ee782a18d900f6d2

[EnigmA-X]

Je kunt er wel op rekenen dat ze bij xs4all qua beheer op zijn minst keypairs met passphrase gebruiken voor authenticatie.

Je zou dan kunnen denken aan 1024 of 2048bit RSA versleutelde private- en public bestanden, waarbij de private-key zich op de client bevindt (hopelijk met passphrase). Kortom: daar gaat wel even tijd in zitten.

Veel interessanter qua security lijkt mij:

• waarom stond er een internet facing machine met bekende exploits

Tot slot denk ik dat het ook voor xs4all eens tijd wordt om te stoppen met onversleutelde wachtwoorden op de lijn (in dit geval hoogstwaarschijnlijk ftp).

[Reactie gewijzigd door EnigmA-X op 23 juli 2024 20:33]

[Zoijar]

Je zou dan kunnen denken aan 1024 of 2048bit RSA versleutelde private- en public bestanden, waarbij de private-key zich op de client bevindt en de public-key nog eens beveiligd is met een behoorlijke passphrase. Kortom: daar gaat wel even tijd in zitten.

Een public key is nooit beveiligd met een passphrase; daarom is het een 'public' key Public key op de server, private key met eventueel passphrase op de client.

[EnigmA-X]

Je hebt helemaal gelijk. De beveiliging van de public key verloopt idd via de passphrase op de private key.

Voor het geheel van het decrypten maakt het niet zoveel uit qua tijd

[eldering]

Jawel: de private key (ongeacht met/zonder passphrase) staat op de client, dus die kan een hacker vanaf de server niet zomaar in handen krijgen. Wordt dus lastig kraken.

[Graham]

nope dit is gewoon een *nix server waar je toegang tot hebt als je een xs4all gebruiker bent. Deze servers zijn naar mijn weten alleen via SSH (SCP ook) te benaderen.

FTP is via ftp.xs4all.nl (weet niet of die toegankelijk is vanaf non xs4all accounts.

>ping ftp.xs4all.nl

Pinging ftp2.xs4all.nl [194.109.21.26] with 32 bytes of data
Reply from 194.109.21.26: bytes=32 time=37ms TTL=61
Reply from 194.109.21.26: bytes=32 time=63ms TTL=61

>ping xs3.xs4all.nl
Pinging xs3.xs4all.nl [194.109.21.4] with 32 bytes of data:
Reply from 194.109.7.133: Destination net unreachable.

Dat eigenlijk FTP nog gebruikt wordt ipv SFTP/FTPS/SCP is eigenlijk niet slim.

[LuckY]

het gaat om shellservers dus waarschijnlijk een standaard *nix password welke gehashed wordt met MD5 en bekende salt (salt staat in de hash)

Edit:
@HarmoniousVibe
jup maar meeste laten dat default staan voor zover ik weet.
En dit is het nadeel van simultaan posten

[Reactie gewijzigd door LuckY op 23 juli 2024 20:33]

[EnigmA-X]

Het lijkt me onwaarschijnlijk dat ze bij xs4all local authentication doen, gezien de omvang van het serverpark.

Het is meer waarschijnlijk dat er gebruik gemaakt wordt van bv LDAP based authenticatie. Dit is ook in lijn met de berichtgeving:

• via exploit root toegang weten te forceren
• wachtwoorden gesniffed van gebruikers via unencrypted of makkelijk te sniffen services (ftp, htaccess, etc)
• gestolen encrypte beheerderswachtwoorden zouden ssh-keys kunnen zijn

Uiteindelijk kan je natuurlijk vanalles bij elkaar gaan zoeken qua theorie, zolang je de technische details niet hebt blijft het gissen.

[DrClaw]

ik lees toch echt wat anders:
* via exploit root toegang verkregen
* 'systeembestand' met wachtwoorden gekopieerd en gepubliceerd .. dit zal wel /etc/shadow zijn, waar de local admin accounts in staan.
* sshd aangepast, die cleartext user/pass combo's opsloeg in een tijdelijk bestand .. hiermee zijn dus de credentials van 30 klanten verkregen.

[HarmoniousVibe]

Of Blowfish, SHA-256 of SHA-512. Zie de link van cyberstalker.

Edit:
@LuckY
Er is geen default. De default wordt bepaald door de distro. Bij het populaire Ubuntu is dit bijvoorbeeld $6$, oftewel SHA-512. Dit geldt ook voor het eveneens erg populaire Debian Squeeze.

[Reactie gewijzigd door HarmoniousVibe op 23 juli 2024 20:33]

[cyberstalker]

Het lijkt me dat daarvoor de standaard Shadow passwords gebruikt zijn.

[bzerk]

Los van dat het niet waar is (xs4all gebruikt FreeBSD op zijn shell servers, en die maken gebruik van een master.passwd bestand, niet een shadow file), zegt dat niets over de gebruikte versleuteling. Standaard is dat MD5 met seed, maar ook andere methodes zijn mogelijk. Welke ze gebruikt hebben is moeilijk te zeggen zonder in de master.passwd te kijken :-D

[Verwijderd]

Is geen kwestie van jaren meer... De rekenkracht met GPU's neemt dermate toe dat jaren naar enkele maanden kan worden verzet.

[Verwijderd]

Hoe beoordeel je dat precies? Hoe weet jij of de huidige rekenkracht genoeg is om ondanks de sterkte van hun wachtwoorden snel te kraken.

[Geekomatic]

Xs4All gehackt?
Rop draait zich om in zijn graf (euhh, komt uit ruste?)

[Verwijderd]

Je vraagt je af waarom een bedrijf als XS4All anno 2012 nog wachtwoorden gebruikt voor SSH. Geen enkele server onder mijn beheer accepteerd een wachtwoord voor SSH. Public keys all the way en vervolgens privileges managen met sudo (of RBAC als het een Solaris bak is).

Het risico dat een wachtwoord gesnatched word is gewoon te groot om te gebruiken voor zoiets als SSH.

Als je iets moet hebben wat beter schaalt / integreerd (hoewel public keys prima te managen zijn met bijvoorbeeld puppet) kan je ook kiezen voor GSSAPI met Kerberos.

Edit: Typo

[Reactie gewijzigd door Verwijderd op 23 juli 2024 20:33]

[anboni]

Dit betreft shellservers waar al hun klanten ook toegang toe hebben. Ik kan me voorstellen dat ze dan niet zo happig zijn om alleen certificaten te accepteren. Keys zijn simpel zat als je je erin hebt verdiept, maar de meeste mensen willen dat niet dus dat zou een aardige extra belasting op kunnen leveren voor de helpdesk.

[n4m3l355]

Daarnaast moet je je afvragen wat het risico voor klanten is in geval van een hack als deze. Ik ben meermaals klant bij Xs4all en ze verstrekken altijd zelf een onmogelijk wachtwoord. Dus deze gebruik ik elders nergens, al zou men een account van mij te pakken krijgen kunnen ze ergens anders er dus weinig mee. Dit zou anders zijn wanneer klanten zelf wachtwoorden gaan instellen, mensen zijn lui aangelegd en gebruiken vaak dezelfde wachtwoorden op meerdere locaties.

Opvallend is echter wel de manier van beveiliging voor hun eigen personeel. Ik zie boven een opmerking dat dit beter kan, of dit daadwerkelijk zo is weet ik niet. Ook weet ik niet waarom Xs4all specifiek voor deze techniek toepast wat wel goed is en dit is uiteindelijk de essentie, dat de wachtwoorden niet snel te kraken zijn. Hoevaak zien we niet berichten voorbij komen dat gegevens gewoon open en bloot zijn opgeslagen? Xs4all doet wat dat betreft dit toch een stuk beter hoewel ze gehacked zijn is er een beperkte hoeveelheid aan data buit gemaakt en is deze ook nog eens snel waardeloos gemaakt.

Ook is het wel goed om eens te horen waarom men de tijd neemt om te reageren. Vaak vragen we ons af waarom berichtgeving zolang duurt, nu weten we het tenminste eens. Ik vraag me eigenlijk wel af waarom andere partijen dit niet doen, dit is toch iets wat men zo kan toegeven richting het publiek.

[EnigmA-X]

Daarnaast moet je je afvragen wat het risico voor klanten is in geval van een hack als deze.

Die is best aanzienlijk. Het is tenslotte single-sign-on. Als ze jouw wachtwoord via deze weg weten te decrypten, hebben ze ook toegang tot bijvoorbeeld je mail account en/of voip van xs4all. Vooral die combinatie kan vrij kostbaar zijn

[Verwijderd]

Het is tenslotte single-sign-on

Overal hetzelfde wachtwoord is geen single-sign-on. Je moet per slot van rekening iedere keer je wachtwoord opgegeven voor al die verschillende services.

Kerberos en OpenID zijn voorbeelden van single sign on. Je authenticeerd je een keer bij een centrale server en vervolgens kan je met die credentials overal inloggen zonder dat je je eerst hoeft te authenticeren.

[EnigmA-X]

Klopt helemaal.

Waar ik op doelde, is dat als je eenmaal ingelogged bent op 'Mijn xs4all' kan je overal bij zonder verdere authenticatie. Dit zijn weldegelijk verschillende systemen. (facturatie, voip, mail instellingen, website beheer, etc).

Je hebt gelijk als je zegt dat dit niet single-sign-on is over *alle* systemen van xs4all. Echter, inloggen op Google of Facebook geeft je ook toegang tot veel systemen, maar niet alle en valt toch ook wel onder SSO voor de aangesloten diensten.

Daarnaast, of je het nou SSO vindt of niet, de single login blijft hetzelfde risico vormen in de context van de opmerking waarom het erg zou zijn.

[Reactie gewijzigd door EnigmA-X op 23 juli 2024 20:33]

[Verwijderd]

Dat klopt niet. VOIP wachtwoord is altijd anders dan je Mijn XS4ALL wachtwoord, of je moet dit zelf gelijk hebben getrokken. Je kan via Mijn XS4ALL enkel het VOIP wachtwoord wijzigen als je het oude wachtwoord hebt.

Wijzigen van persoonsgegevens e.d. kan enkel met een pincode die je eerst per post ontvangt. Er zijn dus verschillende controles ingebouwd.

Dit niet om je te beschermen tegen een hack maar omdat er zoveel klanten zijn die reageren op waarschuwingsmailtjes die naar vreemde websites verwijzen en hier klakkeloos hun gebruikersnaam en wachtwoord invoeren

[LuckY]

Je zou altijd passworden op lokale accounts nodig moeten houden, die staan dan ook in de /etc/secret.
Klanten daar in tegen kan je niet verplichten om sshkeys te gebruiken, dus moeten er wel wachtwoorden gebruikt worden.

Sudo heeft immers ook liever een wachtwoord nodig, om niet alles uit te laten voeren zonder auth

[Reactie gewijzigd door LuckY op 23 juli 2024 20:33]

[Verwijderd]

Je zou altijd passworden op lokale accounts nodig moeten houden, die staan dan ook in de /etc/secret.

Hoezo ? Je kan gewoon gebruikers aanmaken zonder password welke enkel via een public key met SSH kunnen inloggen. 99% Van het *NIX beheer vind plaats via SSH, dus waarom zou die user een password moeten hebben als hij geauthenticeerd is door middel van een publickey, iets wat vele malen sterker is dan een wachtwoord ?

Klanten daar in tegen kan je niet verplichten om sshkeys te gebruiken, dus moeten er wel wachtwoorden gebruikt worden.

Waarom zou je klanten niet kunnen verplichten gebruik te maken van public keys voor SSH welke gebruik willen maken van die server ?

Sudo heeft immers ook liever een wachtwoord nodig, om niet alles uit te laten voeren zonder auth

Dat is maar net hoe je sudo / RBAC configureerd. Je kan sudo zo configureren dat het geen wachtwoord nodig heeft. Wellicht is het zelfs nog veiliger om een gebruiker welke door middel van een public key geauthenticeerd is geen sudo wachtwoord te laten gebruiken dan hem wel een wachtwoord in te laten typen wat hij waarschijnlijk ook nog voor 20 andere services gebruikt (misschien wel hetzelfde als ze GMail account).

Persoonlijk heb ik het zo ingesteld dat je bij sudo het root password moet opgeven van de server. Iedere server heeft een uniek root password wat opgeslagen word in een password managent oplossing. Verder heeft geen enkele user een password op de server. Gebruikers en beheerders worden geauthenticeerd door middel van public keys over SSH. Stel dat je dat root password in handen krijgt is het dus waardeloos want je zal dan ook een account moeten hebben welke sudo / RBAC rechten heeft om uberhaupt zover te kunnen komen dat je dat wachtwoord in kan vullen. Tevens los je meteen de volgende situatie op: Server uit de lucht en een van de beheerders moet onderhoud doen terwijl de server niet aan het netwerk hangt (ie. hij staat fysiek bij de server). Hij kan dan inloggen met het root password op een fysieke terminal (TTY).

Edit: Typo

[Reactie gewijzigd door Verwijderd op 23 juli 2024 20:33]

[EnigmA-X]

Waarom zou je klanten niet kunnen verplichten gebruik te maken van public keys voor SSH welke gebruik willen maken van die server ?

Hoeveel klanten willen op die server en hoe ga je al die public keys beheren? Als ik mijn key aan xs4all mail moeten ze me terug gaan bellen om vast te stellen dat ik daadwerkelijk klant 48829 ben? Vervolgens moet iemand dan mijn key deployen? Daarna weer wijzigen als ik 'm kwijtraak, wanneer weer vastgesteld moet worden dat ik ben die ik zeg dat ik ben?

Zoiets via een klanten panel doen, is dan ongeveer net zo onveilig als het helemaal niet verplicht stellen...

Lijkt me ook niet zo praktisch en qua kosten ook niet echt handig om *alleen* ssh-keys toe te staan.

Daarnaast is een ssh-key per default helemaal niet zo veilig. Aan een public-key kan je niet zien of er een passphrase op de private zit. Als dat niet het geval is, is het opslaan van je private key ongeveer net zo onveilig als je wachtwoord op een papiertje schrijven.

[Reactie gewijzigd door EnigmA-X op 23 juli 2024 20:33]

[Verwijderd]

Hoeveel klanten willen op die server en hoe ga je al die public keys beheren?

Wat is daar anders aan dan wachtwoorden ? Als ik me wachtwoord kwijtraak moet ik me ook opnieuw authenticeren bij de verstrekkende partij.

Zoiets via een klanten panel doen, is dan ongeveer net zo onveilig als het helemaal niet verplicht stellen...

Dan hoef je enkel die server heel goed te beveiligen. Het gehackt worden van een enkele server waarop mensen normaal connecten met een public key is dan geen ramp. Hoe denk je dat SSL / TLS certificaten uitgegeven en gemanaged worden door partijen als Verizon ?

Daarnaast is een ssh-key per default helemaal niet zo veilig. Aan een public-key kan je niet zien of er een passphrase op zit. Als dat niet het geval is, is het ongeveer net zo onveilig als je wachtwoord op een papiertje schrijven.

Los van dat je inderdaad beter een passphrase op je key kan hebben is dit zeker niet het geval. Het grote voordeel van een public / private key setup is dat de feitelijk secret (de private key) nooit de client verlaat. Dus al zou je connecten met een server die totaal gehacked en hostile zou zijn is er nog niks aan de hand. Dit in tegenstelling tot als je met een wachtwoord connect je gewoon je wachtwoord aan de server geeft en deze die kan opslaan (tenzij je een challenge resonse oplossing gebruikt).

Daarnaast is de beveiliging van de key een taak van de gebruiker en kan de server dat onmogelijk controleren.

Het hele punt is dat het aanvals oppervlak kleiner word met public keys. Als je met een wachtwoord inloged op een server die gehackt is stort het hele kaarten huis in elkaar. De server kan dan je password loggen. Met een public key is er niks aan de hand. Daarnaast kan je password bruteforcen maar is het bruteforcen van een public key onbegonnen werk. Zeker met veel gebruikers is een goede password policy implementeren lastig.

[rvl1980]

Los van dat je inderdaad beter een passphrase op je key kan hebben is dit zeker niet het geval. Het grote voordeel van een public / private key setup is dat de feitelijk secret (de private key) nooit de client verlaat.

Juist, en daar ga je de mist in als je 20.000 klanten voorziet van private keys, want meneer Default heeft hem nodig op zijn telefoon want die wil met connectbot inloggen, en op zijn laptop, en op de computer van zijn vrouw, en op de computer op zijn werk, en op de computer van zijn moeder waar die elke week op visite gaat en op de computer van zijn maitresse waar ie vaak is, zet voor het gemak ook nog even een kopietje op de usb stick want je weet maar nooit waar je nog meer moet inloggen, en ga zo nog maar even door....

Dan zit je dus met 20.000 private keys potentieel zonder wachtwoord die op potentieel ontelbaar veel plekken te vinden zijn o.a. op op straat verloren usb sticks, gejatte laptops en weet ik waar nog meer...

Je kunt dan zoals is gezegd net zo goed briefjes met het password rond gaan strooien....

[EnigmA-X]

Het hele punt is dat het aanvals oppervlak kleiner word met public keys.

Dat is iets waar ik het absoluut mee eens ben. Echter, voor een ISP van formaatje xs4all moet het wel werkbaar blijven. De organisatorische impact die public keys hebben zijn in mijn ogen dusdanig voor zo'n partij, om het niet te doen.

Om het heel concreet te maken, een nieuw wachtwoordje voor een klant genereren is kwestie van op een knopje duwen. Voor iemand met keypairs zou je dan een nieuwe key moeten genereren (dat wordt een lang briefje per post) of je moet de identiteit goed vast gaan stellen.

Er zijn tenslotte ook andere manieren dan public keys (en alle daaraan klevende nadelen) om het op een acceptabel niveau te beveiligen.

[Verwijderd]

De organisatorische impact die public keys hebben zijn in mijn ogen dusdanig voor zo'n partij, om het niet te doen.

Niet alle gebruikers van XS4ALL maken gebruik van terminals via SSH van XS4ALL. We hebben het misschien over max 5% van de user base.

Er zijn tenslotte ook andere manieren dan public keys (en alle daaraan klevende nadelen) om het op een acceptabel niveau te beveiligen.

Ik heb ook nooit gezegd dat public keys de enige manier zijn om dit probleem op te lossen. Kerberos, X509 certificates zijn allemaal geldige oplossingen.

Voor een partij zoals XS4ALL met hun users waarschijnlijk in een LDAP tree zou Kerberos een prima alternatief zijn voor SSH in plaats van wachtwoorden.

[EnigmA-X]

Ik ben erg benieuwd hoe je denkt Kerberos te gaan integreren. Zelfs de CPE is voor xs4all untrusted: klanten kunnen alles neerzetten wat ze maar willen.

Kortom, zowel het netwerk als de hosts zijn untrusted? Daarnaast moet je een complete (erg robuuste!) KDC infrastructuur gaan bouwen die dus ook weer internet facing moet zijn.

Bij x509 krijg je weer te maken met dezelfde nadelen als SSH keypairs (beheer/uitgave), het is alleen breder inzetbaar. Echter, je wilt niet *al* je klanten ermee lastigvallen want hoe ga je al die mensen die certificaten op alle pc's laten installeren? Voor een paar kleine services zoiets uitrollen.... lijkt mij niet echt rendabel.

Waar ik op doelde met 'andere manieren om het op een acceptabel niveau te krijgen', was dat je het prima met wachtwoorden kunt doen, mits je de systemen netjes up to date houdt en wanneer je als xs4all bereid bent het risico te lopen.

Kennelijk is dat laatste het geval, als ik de google nieuwsgroep lees die elders werd gelinkt, is het allemaal keurig opgelost

[Verwijderd]

Ik ben erg benieuwd hoe je denkt Kerberos te gaan integreren. Zelfs de CPE is voor xs4all untrusted: klanten kunnen alles neerzetten wat ze maar willen.

Ik heb het enkel over terminal accounts welke via SSH gebruikt worden. Los daarvan kan CPE prima kerberos gebruiken (het tenslotte een open standaard). Ook hoef je niet meteen overal Kerberos voor te gebruiker. Bijvoorbeeld Active directory ondersteund zowel simple binds (ie passwords) als Kerberos. Alle LDAP / Kerberos opstellingen die ik gezien (en gemaakt) heb ondersteunen naast Kerberos ook gewoon normale PW authenticatie door middel van bijvoorbeeld LDAP binds (Kerberos word bijna altijd gebruikt icm LDAP). Het doel is uiteraard wel om Kerberos zo breed mogelijk in te zetten voor authenticatie. Aangezien SSH Kerberos ondersteund had het in dit geval het probleem opgelost.

Kortom, zowel het netwerk als de hosts zijn untrusted?

Dat is het probleem wat Kerberos onder andere oplost.

Daarnaast moet je een complete (erg robuuste!) KDC infrastructuur gaan bouwen die dus ook weer internet facing moet zijn.

Dat is niet zo heel bijzonder ? Active Directory ondersteund Kerberos en daar zijn grote deployments van. Maar je hoeft geen ADS te nemen; Ziggo gebruikt bijvoorbeeld OpenDJ + OpenAM (is geen Kerberos maar is wel SSO).

Echter, je wilt niet *al* je klanten ermee lastigvallen want hoe ga je al die mensen die certificaten op alle pc's laten installeren?

Waarom op de PC's ? Certificaat zou prima in de modem kunnen. Maar zoals ik hierboven al zei; We hebben het enkel over de SSH accounts niet over alle andere diensten. Tevens hoeft 1 oplossing niet meteen overal voor te gebruiken.

[EnigmA-X]

Het begint laat te worden. Technisch gezien heb je op sommige punten helemaal gelijk, desondanks lijkt het mij in de praktijk veel haken en ogen hebben voor een ISP als xs4all.

Daarnaast kan ik niet in de keuken van xs4all kijken en dus ook niet zien wat er qua techniek toegepast wordt. Dat blijft dus een beetje gissen.

Als je bekijkt welke architectuur ze erop los moeten laten (met jouw voorstel) om een paar publieke shell servers te beveiligen.... lijkt me niet echt proportioneel. Zelfs die 5% van de gebruikers zijn toch een paar honderd klanten. Die zijn zeker niet allemaal even bedreven zijn in het gebruik van de genoemde technieken. Je moet dan wel mensen op de helpdesk hebben zitten die vragen kunnen beantwoorden en problemen kunnen helpen oplossen als het niet werkt.

Jouw plan voor een ISP met alleen maar doorgewinterde IT'ers... ja, zou best leuk en waarschijnlijk zelfs een prima keuze zijn qua security.

[zvbhvb]

Die shell server draaide eerst op BSD en daarna op linux.
Als je gewone gebruikers op een shell server toestaat om de processen die als root draaien te bekijken geef je teveel informatie weg.

[Verwijderd]

Of het BSD of Linux (Debian) is, maakt geen ruk uit.
Het gaat er gewoon om wat je erop host, en hoe je je SSH server geconfigureerd heeft.

[Verwijderd]

Host ... : In het algemeen misschien, maar er wordt voor zover ik weet niets speciaal gehost op deze machines: er wordt een alternatieve toegang geboden tot diensten.

Configuratie ... : Je hebt mogelijk een punt vwb de configuratie :

De Roemenen kregen het systeembestand met accountgegevens en versleutelde wachtwoorden van de systeembeheerders in handen

Interessant is hoe /etc/shadow verkregen is, hoe men binnengekomen is, omdat normaal gesproken alleen root hier toegang toe heeft. Want als ik het goed lees zou een goed geimplementeerde combinatie van SRP/SSH/SSO dit probleem hebben kunnen voorkomen...

[arjankoole]

BSD of Linux maak wel degelijk een hoop uit.

[Durandal]

Zo, dus die jongens krijgen nu dan een jaartje gratis lidmaatschap?
Zoiets staat er er in de voorwaarden van XS4All als ik me niet vergis

[anboni]

Alleen als ze de hack netjes hadden gerapporteerd en de verkregen info niet publiek hadden gemaakt

[Verwijderd]

Het was toch appeltaart?

Mits ze vertellen hoe ze het hebben gedaan. En aangezien het een bekende exploit is, gaat er waarschijnlijk geen appeltaart richting Roemenië.

[AW_Bos]

Dat stond in de vroegere voorwaarden: Een half jaar gratis toegang tot al hun diensten.

[Rembert]

public key authenticatie is ook niet optimaal. Als je een account hackt waar die keys staan, dan is de beer pas echt los. En als je kijkt wat er zoal is aangetroffen op die xs3: van meerdere gebruikers (danielm, donar, kai, kane, micks, oliver, reinoudw, thomas, vinces, wijhenke, johnpc) zie ik heel veel van dit soort keys staan waarmee je met public key authenticatie kan inloggen. Al die systemen moeten dus ook als gecompromitteerd worden beschouwd - dit lijken allemaal xs4all systemen te zijn, waaronder mail-office1.

Kortom, deze Roemenen hebben wel hun gratis internet account bij xs4all verdiend :-) Heb zelf wel eens een shadow file buitgemaakt bij xs4all en ook keurig gemeld. Maar dat was nog voordat ze dit in hun voorwaarden hadden staan. Was toen nog sport, nu wordt het anders gezien.

Ik gebruikte deze servers zelf ook om naar andere servers te kunnen hoppen waarbij ik de beveiliging op basis van IP had ingesteld. Ik had de keys al een maand of wat geleden verwijderd.

[Verwijderd]

Certificate login is veel beter dan user/pass login, da's algemeen bekend.
Moet je natuurlijk niet je private keys lopen rond te slingeren als een idioot ^^

[LopendeVogel]

Weleens van het kleine hulp middel ubikey gehoort?? Dat is 1 van de dingetjes wat wij erbij gebruiken.

[CAPSLOCK2000]

Als je slim bent zet je een passphrase op je private key. Als ie dan gestolen wordt kunnen ze er niks mee als ze niet ook het wachtwoord van die key weten.

Voor de duidelijkheid, dat wachtwoord hoort alleen bij de key, het is dus niet je XS4all wachtwoord.

Als je het dan helemaal goed wil doen dan zet je de private-key niet op je PC, maar op een apart stukje hardware dat je via USB aansluit. Je private key verlaat die hardware nooit. Krakers moeten dan zowel je USB-key stelen (ze moeten dus in je huis inbreken) en ze moeten je wachtwoord afluisteren op de computer waar jij op zit te werken.

[Verwijderd]

Na mijn idee heeft xs4all alles netjes in orde gelukkig dat er maar 30 accounts zijn buitgemaakt (zonder wachtwoord)

Lekker nutteloos

[tinzarian]

Als ze ALLES netjes op orde hadden, fanboy, dan had er geen gebruik gemaakt kunnen worden van een bekende exploit, en waren er 0 accounts buitgemaakt.

[rvl1980]

Juist, maar de enige computer die echt goed beveiligd is tegen hackers staat zonder stroom erop, unlugged, in een kluis. En zelfs dan is ie niet 100% beveiligd.

Er blijft altijd een mate van beveiliging 'op orde' hebben over.

Als iemand gehacked wordt kun je je beveiliging dramatisch slecht op orde hebben: alle tienduizenden klanten plain text password in een mysql databaseje met root wachtwoord 'password', redelijk op orde hebben waarbij van de tienduizenden klanten slechts door pro-hackers na een maand 10 wachtwoorden achterhaald werden, of goed op orde hebben waarbij er 'slechts' van een aantal klantaccounts het encrypted password achterhaald wordt.

Sure ze kunnen klanten verplichten om te gaan werken met 4096-bit encrypted public - private keys voorzien van password op de private key... om ook dat stukje af te dichten.... Maar dan snapt simpelweg 95% van de klanten niet meer hoe het werkt...

Beveiliging is omgekeerd evenredig met gebruiksgemak, dus zorg je ervoor dat de kritische delen extreem goed zijn beveiligd, beperk je impact van een eventueel beveiligingslek in systemen waar dat mogelijk is voor systemen die je simpelweg niet wilt of kunt voorzien van 'extreem' goede beveiliging...

Lijkt erop dat ze dat op orde hadden.

0 accounts gekraakt != goede beveiliging !!!

0 accounts gekraakt == iemand is het >nog< niet gelukt om het te doen.

100% beveiliging bestaat niet, waar toegang is, is ALTIJD een beveiligingsrisico.

[itsalwaysme]

Blijkbaar hebben ze het dus niet in orde. Er zijn 30 accounts en wachtwoorden buit gemaakt. En er kan door XS4All niet aangegeven worden hoe lang de servers gehacked geweest zijn.

Ik moet wel zeggen, is Ziggo, UPC Of KPN valt elke tweaker erover. Is het XS4All en dan wordt het door sommige afgedaan als, ah het zijn mijn 30 accounts.

[Verwijderd]

Als het één van die anderen was geweest, dan was het inderdaad niet bij maar 30 gebleven, schat ik zo in.

Niets is 100% te beveiligen hoeveel maatregelen je ook neemt, je kunt wel proberen het zo veilig mogelijk te maken en dat is iets waar ik bij Xs4all wel vertrouwen in heb.

[weebl15]

Ik denk dat de 30 accounts inclusief wachtwoord zijn buitgemaakt.


http://groups.google.com/.../thread/a6352a780e93d6b9#

[GrooV]

Dit gaat dus over de Shell/SSH servers waar XS4ALL standaard toegang voor haar klanten aan geeft, elke xs4all klant heeft hier toegang toe met zijn/haar account met het wachtwoord wat gelijk is aan de site, email, ftp , etc, etc.

Waarschijnlijk is er van een local gebruikt gemaakt op deze servers die trouwens FreeBSD draaien

[Verwijderd]

Niet meer... als ik mijn login mag geloven. De motd geeft het zo aan ...

Sinds kort is shell.xs4all.nl een Linux server ipv FreeBSD.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 20:33]

[arjankoole]

Behalve de IPv6 bak, xs6, die is nog wel FreeBSD. (gelukkig)

[Verwijderd]

shell.xs4all.nl is xs8.xs4all.nl, da's een Debiandoos. Xs3 is bij mijn weten nog een FreeBSDdoos.

[Mega_Mouse]

Ik weet of xs4all dit doet, maar misschien moeten toch een nadenken om SELinux of iets vergelijkbaars aan te zetten op dit soort publieke ssh bakjes. Er zijn inmiddels al aardig wat linux root exploits geweest en 1 dag te laat upgraden, kan bij dit soort machientjes al te laat zijn.

[arjankoole]

Er was een mogelijkheid om via SELinux een bak te rooten. Ik heb wel eens zo'n bak aangetroffen ergens.

De grote fout die xs4all wat mij betreft heeft gemaakt is het vervangen van de Shell dozen door Linux varianten. Toen ze allemaal nog FreeBSD draaiden kwamen dit soort grappen niet voor. BSD is toch echt even een stukje volwassener dan Linux vind ik. Nu is alleen xs6 nog een BSD bak geloof ik.