Hackers breken in op supportserver cPanel
Onbekende aanvallers hebben ingebroken op de supportservers van cPanel, software die door hostingproviders wordt gebruikt om meerdere websites op dezelfde server te hosten. Wie is geholpen door de supportafdeling, dient zijn wachtwoord te wijzigen.
CPanel heeft nog geen verklaring uitgegeven over de aanval; het bedrijf brengt de aanval aan het licht in een mail aan klanten die de afgelopen zes maanden contact hebben opgenomen met de supportafdeling en die is ontvangen door tweaker Punked24. In de mail schrijft cPanel dat een van de servers op de supportafdeling is gekraakt. Een medewerker van cPanel bevestigt de legitimiteit van de mail op het officiële supportforum.
De precieze omvang van de aanval is niet duidelijk, maar het bedrijf raadt gebruikers aan om hun rootwachtwoorden te wijzigen als die zijn gebruikt door de supportafdeling. "We weten nog niet alles van de aanval, dus vragen we onze klanten om direct actie te ondernemen", schrijft het beveiligingsteam van cPanel. Gebruikers die in plaats van wachtwoorden cryptografische sleutels gebruiken om in te loggen op ssh, hoeven geen actie te ondernemen.
Het nieuws komt op het moment dat een rootkit de ronde doet die zich richt op Cent OS- en Cloud Linux-systemen waar cPanel op geïnstalleerd is. Of het een iets met het ander te maken heeft, is onbekend. CPanel is software die wordt gebruikt door hostingproviders om meerdere websites op dezelfde server te hosten. Vergelijkbare softwarepakketten zijn Plesk, DirectAdmin en Ensim.
Reacties (18)
Dat krijg je als een bedrijf om je wachtwoord vraagt. Wanneer er op basis van public/private certificaten was gewerkt, was dit nooit gebeurd. Dan kun je bij een supportaanvraag gedurende korte tijd toestaan dat cPanel met hun certificaat in kan loggen, en hoef je helemaal geen wachtwoorden af te staan. Schijnbaar gebeurde dit wel:Wie is geholpen door de supportafdeling, dient zijn wachtwoord te wijzigen.
Maar dit had gewoon standaard moeten zijn.Gebruikers die in plaats van wachtwoorden cryptografische sleutels gebruiken om in te loggen op ssh, hoeven geen actie te ondernemen.
Normaliter wel, maar dan alleen als je direct de Key van cPanel eraf had gegooit. Van wat er nu bekend is is de exploit dusdanig dat hij de volledige keypair doorgaf (exploit draaide immmers al aan de kant van de private key, de public kon zo van de server worden gewipt)
Wat een onzin.
a) de meeste certificaten t.b.v. authenticatie op bijv. SSH verlopen helemaal niet, sterker nog, het is meestal alleen maar een private/public keypair, daar zit helemaal geen gedeelte bij zoals op een SSL certificaat met een verloop datum
b) het onderhouden van dergelijke certificaten kost veel meer tijd dan een tijdelijk account aanmaken of je wachtwoord even op een tijdelijk wachtwoord zetten en terug zetten als de support afdeling klaar is
c) dat een bedrijf om mijn wachtwoord vraagt t.b.v. het verlenen van support betekend niet dat ze die wachtwoorden als ze klaar zijn met de support toch nog maar moeten bewaren, wel?
d) Tja, ik vind ook dat het een standaard moeten worden om bevolkingspopulatie te beperken. Lost niet alleen milieu problemen op, het lost ook voedsel en grondstof tekorten op evenals vele andere problemen - net als in dit geval niet aan ons om te bepalen lijkt me zo.
Sorry, vergat e:
e) Als je ze certificaat jatten is dat hetzelfde als dat ze het wachtwoord weten. Certificaten zijn inderdaad veiliger dan een simpel paswoordje, bij hele complexe wachtwoorden vervalt een groot deel van dat voordeel al meteen.
a) de meeste certificaten t.b.v. authenticatie op bijv. SSH verlopen helemaal niet, sterker nog, het is meestal alleen maar een private/public keypair, daar zit helemaal geen gedeelte bij zoals op een SSL certificaat met een verloop datum
b) het onderhouden van dergelijke certificaten kost veel meer tijd dan een tijdelijk account aanmaken of je wachtwoord even op een tijdelijk wachtwoord zetten en terug zetten als de support afdeling klaar is
c) dat een bedrijf om mijn wachtwoord vraagt t.b.v. het verlenen van support betekend niet dat ze die wachtwoorden als ze klaar zijn met de support toch nog maar moeten bewaren, wel?
d) Tja, ik vind ook dat het een standaard moeten worden om bevolkingspopulatie te beperken. Lost niet alleen milieu problemen op, het lost ook voedsel en grondstof tekorten op evenals vele andere problemen - net als in dit geval niet aan ons om te bepalen lijkt me zo.
Sorry, vergat e:
e) Als je ze certificaat jatten is dat hetzelfde als dat ze het wachtwoord weten. Certificaten zijn inderdaad veiliger dan een simpel paswoordje, bij hele complexe wachtwoorden vervalt een groot deel van dat voordeel al meteen.
[Reactie gewijzigd door freaky op vrijdag 22 februari 2013 15:47]
Onzin? Ik zou mezelf even beter informeren voordat je deze conclusie trekt.
In principe is je private key veilig. Totdat je eigen workstation dus mbv een exploit deze deelt. En de public key staat op de server .. dan kan je er toch in?
Wat je bij B meldt is niet het geval. Wanneer je aan cPanel hun public key opvraagt kan je die via de cPanel software op je eigen server/vps heel gemakkelijk toevoegen (en weer verwijderen). Het aanpassen van een wachtwoord zodra er een derde er klaar mee is lijkt me per definitie een goed idee. In dit geval zou alleen de infectie op de achergrond al kunnen hebben plaatsgevonden, aangezien deze geautomatiseerd lijkt.
Verder wat je meldt bij punt C is nl niet het geval: er is geen databreach waarbij ze een hele lijst gegevens op hebben gepakt, de exploit geeft realtime tijdens het gebruik van een password of key deze realtime door.
En ik lees nu pas je punt D .. .volgens mij ben je gewoon aan het trollen.. nevermind .
In principe is je private key veilig. Totdat je eigen workstation dus mbv een exploit deze deelt. En de public key staat op de server .. dan kan je er toch in?
Wat je bij B meldt is niet het geval. Wanneer je aan cPanel hun public key opvraagt kan je die via de cPanel software op je eigen server/vps heel gemakkelijk toevoegen (en weer verwijderen). Het aanpassen van een wachtwoord zodra er een derde er klaar mee is lijkt me per definitie een goed idee. In dit geval zou alleen de infectie op de achergrond al kunnen hebben plaatsgevonden, aangezien deze geautomatiseerd lijkt.
Verder wat je meldt bij punt C is nl niet het geval: er is geen databreach waarbij ze een hele lijst gegevens op hebben gepakt, de exploit geeft realtime tijdens het gebruik van een password of key deze realtime door.
En ik lees nu pas je punt D .. .volgens mij ben je gewoon aan het trollen.. nevermind .
Ah ja, waar hadden ze de wachtwoord gejat? Juist, op de server van cPanel. Waar staan die certificaten over het algemeen? Juist... bovendien uit je eigen post van hieronder: "mbv passwords/keys die ze met de exploit bemachtigen"In principe is je private key veilig. Totdat je eigen workstation dus mbv een exploit deze deelt. En de public key staat op de server .. dan kan je er toch in?
Mja, m'n cPanel kennis laat ongetwijfeld te wensen over (heb het 1 keer gezien), maar het kopieeren van een sleutel op de cli is toch echt (al dan niet marginaal) lastiger dan passwd. Daarbij kun je vele certificaten aan 1 account hebben hangen - maar maar 1 ww.
En ik zie niet in wat D met trollen te maken heeft. Mensen hebben verschillende meningen, blijkbaar ben je het niet eens met mijn standpunt over de overbevolking. Ondanks dat ik het wel eens ben met GlowMouse kan ik je hordes met beheerders aanwijzen die dat definitief niet zijn. En net als hier geld dat zij net zo veel recht hebben op een stem als jij (of ik - alleen Torvalds telt voor 2, nou goed, Alan Cox mss ook maar die heeft pauze
). Waarom mijn reactie onder jouw staat terwijl ik op GlowMouse reageerde ontgaat mij overigens ook, maar gaat sinds de nieuwe layout wel vaker mis volgens mij.Hoe dan ook, of je wachtwoord of je key nou lekt, het eind resultaat verschilt niet veel. Daarbij zie je vaak dat mensen nog wel de intelligentie hebben om verschillende wachtwoorden te gebruiken voor verschillende servers, maar wel overal hetzelfde certificaat gebruiken. Alhoewel ook dat er maar net aan ligt waar je zit, moest laatst nog een SQL server met pensioen gegevens virtualiseren en die bleek gewoon open te hangen richting het internet, met een database naam die gelijk was aan het software pakket, met idem username/password. Zelfs op dat niveau zitten ze geregeld nog steeds te slapen helaas.
Kan je aanraden om de WHT thread te lezen. Het heeft nl lang niet zoveel met cPanel te maken als jij nu doet voorkomen.
Er is OOK een cPanel workstation met die exploit gëinfecteerd geraakt. OOK. En over die workstation gaan relatief veel key/passwords heen aangezien ze vanaf daar cPanel/server klanten helpen.
Er zijn echter ook servers van heren/dames geïnfecteerd die niet door cPanel zijn geholpen de afgelopen 6 maanden, en waar uiteindelijk bleek dat ze ZELF geïnfecteerd waren met de exploit.
WB je reactie op D dan: ik ging ervanuit dat dat op iets zou moeten zijn geweest dat ik getikt had, en ik kon er geen gehakt van maken ... nu blijkt waarom . .excuus voor de aantijging...
EDIT: ik lees net mn reactie.. voor de duidelijkheid dit is de flow van infectie:
1 - een werkstation/computer wordt geinfeceerd met een exploit
2 - die vangt alle l/p+keys af voor servers
3 - op die servers wordt vervolgens een hele vervelende SSHD exploit gezet
4 - die vervolgens alle l/p+key inlogpogingen op die server weer doorstuurt
Bij cPanel was 1 van toepassing . .maar dat gebeurde ook bij andere personen die servers beheren.
Er is OOK een cPanel workstation met die exploit gëinfecteerd geraakt. OOK. En over die workstation gaan relatief veel key/passwords heen aangezien ze vanaf daar cPanel/server klanten helpen.
Er zijn echter ook servers van heren/dames geïnfecteerd die niet door cPanel zijn geholpen de afgelopen 6 maanden, en waar uiteindelijk bleek dat ze ZELF geïnfecteerd waren met de exploit.
WB je reactie op D dan: ik ging ervanuit dat dat op iets zou moeten zijn geweest dat ik getikt had, en ik kon er geen gehakt van maken ... nu blijkt waarom . .excuus voor de aantijging...
EDIT: ik lees net mn reactie.. voor de duidelijkheid dit is de flow van infectie:
1 - een werkstation/computer wordt geinfeceerd met een exploit
2 - die vangt alle l/p+keys af voor servers
3 - op die servers wordt vervolgens een hele vervelende SSHD exploit gezet
4 - die vervolgens alle l/p+key inlogpogingen op die server weer doorstuurt
Bij cPanel was 1 van toepassing . .maar dat gebeurde ook bij andere personen die servers beheren.
[Reactie gewijzigd door DonLexos op vrijdag 22 februari 2013 16:25]
Hebben ze bij de supportafdeling de wachtwoorden dan? Klinkt niet erg veilig, iemand die weet hoe dat zit?
Nee dat zeker niet, maar als je een probleem hebt waarbij ze dieper moeten kijken dan een user account dan kan je die beveiligd doorgeven. Probleem is dat een werkstation van een medewerker de key/login/pass dus kennelijk weer doorgaf aan een derde ..
Merk op dat in de thread op WebHostingTalk ook verbanden werden gelegd met Facebook, Apple en andere die allemaal deze week interne hacks meldden. .. niet zozeer mbt het stelen van wachtwoorden, wel met het feit dat zelfs in dichtgetimmerde netwerken workstations alsnog (Java/Flash exploit?) kunnen worden geinfecteerd..
Lastig tegen te wapenen lijkt het
Merk op dat in de thread op WebHostingTalk ook verbanden werden gelegd met Facebook, Apple en andere die allemaal deze week interne hacks meldden. .. niet zozeer mbt het stelen van wachtwoorden, wel met het feit dat zelfs in dichtgetimmerde netwerken workstations alsnog (Java/Flash exploit?) kunnen worden geinfecteerd..
Lastig tegen te wapenen lijkt het
Je moet niet alles geloven wat mensen op WHT roepen. Er is nog niets bekend over hoe ze binnen zijn gekomen en het hoeft absoluut niet via eennworkstation gegaan te zijn, dat lijkt zelfs bijna onmogelijk met de interne business architectuur bij cPanel.
Ja, dat staat er toch:
maar het bedrijf raadt gebruikers aan om hun rootwachtwoorden te wijzigen als die zijn gebruikt door de supportafdeling.
maar het bedrijf raadt gebruikers aan om hun rootwachtwoorden te wijzigen als die zijn gebruikt door de supportafdeling.
Helemaal mee eens. Lijkt me dat ze dat uberhaupt altijd al roepen, dit lijkt meer damage control; er was één systeem (voor zover bekend) geïnfecteerd, en ik vermoed dat ze er meer hebben.
Derhalve is niet iedereen die door cPanel is geholpen direct mogelijk gehacked... maar er zit dus nergens een gat, als de SSHD exploit op je server terecht is gekomen doen ze dat mbv een eerder afgeluisterd login/wachtwoord. Derhalve kan het alsnog zin hebben om dat wachtwoord aan te passen.
Derhalve is niet iedereen die door cPanel is geholpen direct mogelijk gehacked... maar er zit dus nergens een gat, als de SSHD exploit op je server terecht is gekomen doen ze dat mbv een eerder afgeluisterd login/wachtwoord. Derhalve kan het alsnog zin hebben om dat wachtwoord aan te passen.
Ik vold de thread op WebHostingTalk al dagen en het lijkt erop dat de hackers initieel servers binnen komen mbv passwords/keys die ze met de exploit bemachtigen. .Daarna gaat het snel verkeerd, er wordt vanalles geinstalleerd (waaronder tools die weer van alle inlogs op de server l/p doorgeven)..
Naar nu blijkt is 1 van de support pc's bij cPanel zelf geïnfecteerd geweest, en die is gebruikt om voor klanten problemen op hun pc's op te lossen, kan dus om veel systemen gaan.
In eerste instantie werd gedacht aan een gat in openSSH, maar al snel leek het er toch op dat de eerste toegang tot de server mbv een desktop hack/exploit tot stand kwam.
Als je een dag niets te doen hebt, op dit moment 85 pagina's lang:
http://www.webhostingtalk.com/showthread.php?t=1235797
Voor zover nu bekend is dit de exploit die wordt geinstalleerd:
http://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229
Grootste nadeel is dat de servers waarop de exploit terecht is gekomen vanaf 0 opnieuw moeten worden opgebouwd omdat nog onbekend is wat er allemaal door de exploit wordt aangepast.
Naar nu blijkt is 1 van de support pc's bij cPanel zelf geïnfecteerd geweest, en die is gebruikt om voor klanten problemen op hun pc's op te lossen, kan dus om veel systemen gaan.
In eerste instantie werd gedacht aan een gat in openSSH, maar al snel leek het er toch op dat de eerste toegang tot de server mbv een desktop hack/exploit tot stand kwam.
Als je een dag niets te doen hebt, op dit moment 85 pagina's lang:
http://www.webhostingtalk.com/showthread.php?t=1235797
Voor zover nu bekend is dit de exploit die wordt geinstalleerd:
http://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229
Grootste nadeel is dat de servers waarop de exploit terecht is gekomen vanaf 0 opnieuw moeten worden opgebouwd omdat nog onbekend is wat er allemaal door de exploit wordt aangepast.
Ik heb een VPS bij Corgi Tech, Ik heb van hun een mail gehad met een link in naar het zelfde topic. Corgi Tech raad aan om met behulp van ip tables enkel de IP's toe te laten die je vertrouwt.
Het is dus geen lek in cPanel?
EDIT: Voor de geïnteresseerde ik gebruik als firewall Shorewall (op Debian) dat is een cover over iptables. Is heel makkelijk in te stellen.
Het is dus geen lek in cPanel?
EDIT: Voor de geïnteresseerde ik gebruik als firewall Shorewall (op Debian) dat is een cover over iptables. Is heel makkelijk in te stellen.
[Reactie gewijzigd door LEDfan op vrijdag 22 februari 2013 15:36]
Het is inderdaad geen lek in cPanel.
Sowieso is werken met keypairs veiliger dan via password, en als je inderdaad een VPN hebt of statisch IP kan je overwegen om bepaalde zaken maar beperkt beschikbaar te maken.
Als je een cPanel (VPS) draait kan ik je de (gratis) firewall van ConfigServer zeker aanraden!:
http://www.configserver.com/cp/csf.html
Sowieso is werken met keypairs veiliger dan via password, en als je inderdaad een VPN hebt of statisch IP kan je overwegen om bepaalde zaken maar beperkt beschikbaar te maken.
Als je een cPanel (VPS) draait kan ik je de (gratis) firewall van ConfigServer zeker aanraden!:
http://www.configserver.com/cp/csf.html
Zoals ik lees is dit alleen voor RPM based linux distro's.
Eigenlijk meer over de CentOS/Redhat familie, zover ik lees. Niet alle RPM based distro's zijn familie van CentOS/Redhat.
[Reactie gewijzigd door d1ng op vrijdag 22 februari 2013 15:59]
Er zjin gevallen van de exploit bekend op Debain, CentOS/RedHat & CloudLinux.
In eerste instantie werd gedacht dat een speciale race condition in de kernel, een 0 day, tot de hacks heeft geleid, alleen daarvoor is toegang tot system levels nodig die via SSH kan gegeven worden zónder login, dat lijkt nog steeds het geval. Zie de volgende CVE http://
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
