'Ex-werknemer HostGator zet backdoor op 2700 servers'
Een voormalige werknemer van het Amerikaanse hostingbedrijf HostGator is gearresteerd en aangeklaagd wegens het installeren van een backdoor waarmee hij toegang tot meer dan 2700 servers van het bedrijf had. De 29-jarige Eric Gunnar Gisse werkte van september 2011 tot 15 februari 2012, de dag van zijn ontslag, bij HostGator. Het hostingbedrijf host meer dan 8 miljoen domeinen.
Een dag na zijn ontslag ontdekten werknemers van HostGator de backdoor, waarmee Gisse vanaf buiten op de servers kon inloggen. Hij zou moeite hebben gedaan om zijn malware als normale Unix-beheertools te vermommen, aldus de openbare aanklager.
Het zou om een proces genaamd 'pcre' gaan, een veel voorkomende bestandsnaam, aldus de aanklager in een document waar Ars Technica over schrijft. Het ongeautoriseerde proces werd op 2723 verschillende servers aangetroffen.
Ontdekking
De backdoor waarmee Gisse volledige controle over de Apache webservers zou hebben gekregen, was mogelijk omdat hij de SSH-sleutel van HostGator had bemachtigd en die op computers onder zijn controle had gezet. Ondanks zijn toegang zouden er geen klantgegevens zijn gestolen, zo laat HostGator in een reactie weten.
"We ontdekten het voordat hij de kans kreeg dit soort dingen te doen", aldus een woordvoerster. De malware zou minder dan een maand op de systemen van HostGator hebben gestaan.
Het bedrijf kon via een desktopmonitoringssysteem dat elke minuut een screenshot van de werkstations van werknemers maakt Gisse als verdachte aanmerken. De ex-werknemer moet volgende maand voor de rechter verschijnen.
Zelfs voor de VS lijkt dat me erg ver gaan. ( het is een hostingbedrijf, geen trading floor of NSA desktop)
Voor een echte insider op waarschijnlijk precies de goede plek is dat wel heel moeilijk voorkomen.
Ook al heb je een signature check om te controleren dat er geen 'unauthorized' software gedeployed wordt, er zijn wat mensen in het beheerteam die daar dingen aan toe kunnen voegen omdat dat hun werk is en er natuurlijk soms dingen toegevoegd moeten worden.
Termen als 'functie scheiding' en 'vier ogen' komen dan op tafel, en dat geeft erg veel overhead. Hosting marges zijn niet groot, en een verdubbeling van personeel is duur. En voor een vertrouwde insider is daar vaak wel omheen te werken. (kijk maar naar al die traders die alleen opvallen als ze een paar miljard verlies maken. Ondanks de nomimale controles van meer ogen )
Wacht even.
Staat hier dat er een enkele sleutel is voor het hele bedrijf?
Waarschijnlijk log je daar dan ook gelijk mee in als root.
Hoeveel klanten zijn opgestapt vanwege dit totale gebrek aan beveiliging?
Iedere beheerder heeft zijn eigen account (met zijn eigen sleutel) en heeft vervolgens op de systemen de rechten die hij nodig heeft. Als hij Apache moet beheren, krijgt hij alleen rechten daartoe. Als iemand vertrekt, worden zijn rechten ingetrokken en het account verwijderd. Dat is binnen een half uur gerealiseerd op al onze servers.
De enige andere manier om er dan nog binnen te komen is door de sleutel van een collega te bemachtigen. Ik zou trouwens geen toegang van buiten het beheernetwerk toe willen laten. Dan kan hij nog zo veel sleutels hebben, maar toegang krijgt hij niet.
Is dat niet mogelijk (omdat klanten ook SSH toegang moeten krijgen), dan zou ik in ieder geval bij de beheerders met 2-factor (of 2-step) authenticatie gaan werken.
Peter
Een dergelijke Non Personal Account moet je aanvragen voor een machine met een reden waarom je het wil aanvragen bij een security afdeling (tenminste bij ons) Je kan nog zo fijn iedereen toegang geven via zijn eigen account om dit "accountable" te maken via auditfiles, event logs etc etc. maar het kenmerk van mensen die via hun account toegang hebben om dit soort handelingen te doen is, dat ze ook vaak de logging kunnen manipuleren ..
Ergo: schiet niet op.
Nadeel van een NPA is natuurlijk dat het moeilijk wordt om te bepalen wie op welk moment waar mee bezig is geweest. Daar is echter de registratie voor op een dergelijke securty afdeling.
- sander -
Indien noodzakelijk werken we hier wel met NPA's.
Write-only logfiles op een centrale logserver.
Je weet dan nog altijd niet wat die persoon daar heeft gedaan. Dan heb ik liever dat ze inloggen met hun eigen account en vervolgens sudo naar dat andere account doen.
Peter
Wacht even.
Staat hier dat er een enkele sleutel is voor het hele bedrijf?
Waarschijnlijk log je daar dan ook gelijk mee in als root.
In de context van hostingbedrijf denk ik dat het een sleutel is voor een auto software install account.
Als je praat over dergelijke aantallen servers moet je een mechanisme hebben waarmee de basis software op alle machines kunt beheren/bijhouden/patchen/updaten.
Hoeveel klanten zijn opgestapt vanwege dit totale gebrek aan beveiliging?
Iedere beheerder heeft zijn eigen account (met zijn eigen sleutel) en heeft vervolgens op de systemen de rechten die hij nodig heeft. Als hij Apache moet beheren, krijgt hij alleen rechten daartoe. Als iemand vertrekt, worden zijn rechten ingetrokken en het account verwijderd. Dat is binnen een half uur gerealiseerd op al onze servers.
Heel mooi, maar ik denk/hoop dat ook jullie een gecentraliseerde en snelle mogelijkheid hebben om updates/patches snel een breed uit te rollen. Als dat proces gecompromitteerd is, heb je een groot probleem.
Bij een voldoende gesloten netwerk moet je dan hopen dat de open backdoor niet van buitenaf bereikbaar is (wegens beheertoegang alleen vanaf vpn e.d.) maar bij een hoster is dat niet zo makkelijk. Plus dat er natuurlijk tig manieren zijn voor een backdoor om van binnenuit een sessie te initieren.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
