Apache gehackt via slechte SSH implementatie
Om het internet een veiligere plek te maken, heeft de Apache Software Foundation in alle openheid verklaard hoe aanvallers eind augustus verschillende servers wisten te hacken en wat het gaat doen om herhaling te voorkomen. Zoals in eerste instantie al werd aangenomen, begon de aanval met het overnemen van de server die apachecon.com host. De machine draaide CentOS en Apache vermoedt dat de aanvallers een recente local root exploit hebben gebruikt om hun rechten te verhogen. Aangezien de logs werden vernietigd, is het lastig om vast te stellen wat er precies op de machine gebeurde.
De server in kwestie wordt beheerd door de ApacheCon conference productiemaatschappij. Verschillende Apache Software Foundation leden hadden accounts op deze machine, waaronder één voor het maken van backups. De aanvallers probeerden tevergeefs om met wachtwoorden van de gehackte ApacheCon machine op de productie webservers in te loggen. Via de SSH-sleutel van het backup account wisten ze uiteindelijk toegang tot people.apache.org te krijgen. Dit account was van een "unprivileged user", gebruikt voor het maken van backups van de ApacheCon host.
Zodra de aanvallers shell toegang hadden, voegden ze CGI scripts aan de document root folder van verschillende websites toe. Een gepland rsync proces kopieerde deze scripts naar de productie webserver, eos.apache.org, waar ze uiteindelijk door de aanvallers werden aangeroepen. Toen de scripts ontdekt werden, haalde Apache alle mogelijk getroffen servers offline. Het heeft nu vastgesteld dat geen enkele download, gebruiker of code repository door de aanval risico heeft gelopen.
SSH implementatie
Apache is zeer te spreken over het gebruik van ZFS snapshots om de webservers weer te herstellen. Ook de redundante services op twee locaties en het gebruik van verschillende besturingssystemen, werkten naar behoren. In het laatste geval maakte dit het lastiger voor de aanvallers om hun rechten op meerdere machines te verhogen. Wat niet werkte was het gebruik van SSH-sleutels. De gebruikte implementatie liet volgens Apache veel te wensen over. Zo werden de SSH-sleutels niet voldoende beperkt en was men niet op de hoogte van het misbruik. Ook de mogelijkheid om CGI scripts in elke virtual host te draaien, ook al hebben de meeste websites van Apache dit niet nodig, vormde een onnodig risico. Verder betreurt men ook het bewaren van logs op de machine, waardoor de aanvallers die konden verwijderen om hun sporen te wissen.
Om herhaling te voorkomen neemt Apache verschillende maatregelen, zoals het opnieuw aanmaken en gebruiken van nieuwe SSH-sleutels, het instellen van toegangsbeperkingen, IP banning, gecentraliseerde logging en nog een aantal andere zaken, zoals het audit verslag duidelijk maakt. Negen jaar geleden wisten Nederlandse hackers Apache al een keer te defacen.
Dit zou je niet verwachten als aanvaller zijnde. Ik ben op zich wel benieuwd hoe de aanvallers wisten(?) dat deze mogelijkheid er was...
Zie http://www.debian-administration.org/articles/590
hulde.
Waarom?
True, maar ze hadden dus geen shell toegang. Althans niet op de systemen waar ze die CGI scripts op gingen uploaden (via het automatische backup proces).
> Aangezien de logs werden vernietigd, is het lastig om vast te stellen wat er precies op de machine gebeurde.
Dus er was geen remote opslag van logfiles, wat men zelf ook al concludeert. En nee nee nee, niet nu stomweg standaard syslog aanzetten natuurlijk hè
> Dit account was van een "unprivileged user", gebruikt voor het maken van backups van de ApacheCon host.
Hoe kan een unpriv. user nu een correcte backup van *alles* maken ?
> voegden ze CGI scripts aan de document root folder van verschillende websites toe.
Dus die unpriv user had wel schrijfrechten in die documentroots.. Interesant ondoordachte opzet.
> Een gepland rsync proces kopieerde deze scripts naar de productie webserver, eos.apache.org, waar ze uiteindelijk door de aanvallers werden aangeroepen.
Dus er staat geen enkel filter op de import van die files
> Toen de scripts ontdekt werden, haalde Apache alle mogelijk getroffen servers offline.
Dus er draait geen software die de content in de gaten houdt en verdachte zaken als plotseling opduikende cgi-script's opmerkt. Kan ook zijn dat het script nog niet draaide of bezig was met. Directories met CGI's houdj je toch wel wel wat strikt in de gaten, lijkt me.
> Het heeft nu vastgesteld dat geen enkele download, gebruiker of code repository door de aanval risico heeft gelopen.
Men geeft openheid over het hoe, maar waarom zou ik deze claim zonder onderbouwing (hoe weten ze dat ?) aannemen ? Misschien heb ik een persbericht gemist, kan.
> en was men niet op de hoogte van het misbruik.
Pardon ? MIsbruik van ssh ? Het feit dat het kan ? Men was niet bekend over misbruik in het verleden ?
> Om herhaling te voorkomen neemt Apache verschillende maatregelen, zoals het opnieuw aanmaken en gebruiken van nieuwe > SSH-sleutels, het instellen van toegangsbeperkingen, IP banning, gecentraliseerde logging en nog een aantal andere zaken
Nou nou. Van de makers van dit soort software had ik toch meer preventief vermogen verwacht. Kalf. Dempen. Put. Beveiligingen is een vak. Pluim aan apache foundation voor dir rapport en nu als een idioot aan het werk om die rotzooi op te ruimen. Foei.
Waarom?
De drie gangbare niveau's in access control voor Unix: read, write en execute voor de drie domeinen me, group en everyone, schieten meestal te kort.
Met Security Enhanced Linux (geen distro, maar een set Linux security modules) kun je rollen en policies definieren.
Bijvoorbeeld, een php script hoeft niet bij /etc/shadow te kunnen komen, sterker, die hoeft helemaal niet buiten de http docs directory te kunnen komen. Als er bestanden buiten de http docs directory staan met permissions op world readable, kan zou een script dat kunnen uitlezen. Dit kun je met SELinux voorkomen :)
Voor meer info:
- http://en.wikipedia.org/wiki/Security-Enhanced_Linux
- http://tweakers.net/reviews/946/se-linux-een-kwestie-van-vertrouwen.html
Als je een Apache mirror wilt worden, dan is dat heel gemakkelijk. Inbreken niet nodig. Stel je wilt alleen een bepaalde target infecteren. Je verwijst requests van deze IP's door naar een andere directory. Goed, de sigs kloppen niet, maar niemand kan dat aantonen. De target is dom genoeg om de sigs niet te controleren.
Het hele third party mirror systeem is achterhaald. Public keys die op de mirror worden aangeboden. Tja, dat is helemaal nutteloos.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.