2 miljoen webservers kwetsbaar door nieuw Apache-lek
Wereldwijd zijn 2 miljoen webservers kwetsbaar door een nieuw Apache-lek dat een lokale gebruiker de mogelijkheid biedt om root te worden. Het probleem speelt met name bij shared webhostingomgevingen waar meerdere websites op dezelfde Apache-webserver draaien.
Ook als Apache-servers niet door meerdere gebruikers worden gedeeld kan de kwetsbaarheid in combinatie met andere beveiligingslekken door een aanvaller worden gebruikt om code met rootrechten uit te voeren. Op 1 april verscheen er een beveiligingsupdate van de Apache Foundation om de kwetsbaarheid te verhelpen.
Securitybedrijf Rapid7 besloot een online scan uit te voeren en ontdekte zo'n 2 miljoen verschillende Apache-webservers die kwetsbaar zijn. Ongeveer de helft hiervan werd bij grote cloudhostingproviders aangetroffen, waaronder Amazon, Digital Ocean en OVH. Het grootste deel van de getroffen systemen, zo'n 770.000 servers, staat in de Verenigde Staten, gevolgd door Duitsland (224.000) en Frankrijk (111.000). Ook in Nederland vond Rapid7 tienduizenden kwetsbare systemen.
"Hoewel dit geen kwetsbaarheid is om op afstand code uit te voeren, is het een springplank voor aanvallers om acties uit te voeren die de meeste hostingproviders juist proberen te voorkomen. Organisaties moeten de Apache-update zo snel als mogelijk toepassen", aldus Bob Rudis van Rapid7. Organisaties die van een shared webhostingomgeving gebruikmaken krijgen het advies om hun hostingprovider te vragen om de patch zo snel als mogelijk uit te rollen of naar een andere provider of platform over te stappen.
Omdat linux root permissions nodig heeft voor alle poorten <1000. Dus services draaiende onder poort 80 en 443 hebben root access nodig
Inderdaad! @reageerders Als je dat niet eens weet wat doe je hier dan?
zoals bijvoorbeeld kwetsbare versie httpd 2.4.39,
men kan het natuurlijk ook op andere wijzen aan de weet komen,
maar men gaat altijd natuurlijk het eerst voor het laaghangend fruit.
Is server security dan zo'n ver van m'n bed show?
Het is net Bingo in dit geval:
Date: Thu, 04 Apr 2019 05:12:08 GMT
Server: Apache/2.4.38 (Debian)
X-x-httpd-MLG-noscope-x-X: WUB WUB WUB WUB SKREEEEEEE
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Het wordt ze wel erg gemakkelijk gemaakt tegenwoordig, neen geen adres, geen verdere info.
#sockpuppet
Omdat linux root permissions nodig heeft voor alle poorten <1000. Dus services draaiende onder poort 80 en 443 hebben root access nodig
https://bjornjohansen.no/redirect-to-https-with-nginx
Als je weet dat je niet onder root moet draaien gewoon werk verzetten om dat niet te doen. Hoe moeilijk kan het zijn...
Ik zie reacties van NVA en een anoniem in dezelfde richting. Je zult dan wat met high privileged accounts moeten doen
Omdat linux root permissions nodig heeft voor alle poorten <1000. Dus services draaiende onder poort 80 en 443 hebben root access nodig
https://bjornjohansen.no/redirect-to-https-with-nginx
Niet echt relevant dus.
Omdat linux root permissions nodig heeft voor alle poorten <1000. Dus services draaiende onder poort 80 en 443 hebben root access nodig
https://bjornjohansen.no/redirect-to-https-with-nginx
Als je weet dat je niet onder root moet draaien gewoon werk verzetten om dat niet te doen. Hoe moeilijk kan het zijn...
Ik zie reacties van NVA en een anoniem in dezelfde richting. Je zult dan wat met high privileged accounts moeten doen
Jij snapt gewoon echt niet wat droppen van privileges inhoudt hè? Als gevolg daarvan begrijp je niet dat jouw reactie in deze nogal lachwekkend overkomen.
Nogal lachwekkend om daar niet iets voor te verzinnen terwijl je weet dat port redirecting mogelijk is.
Het is negeren van dat soort zaken is de reden van het falen van Linux omgevingen.
Nogal lachwekkend om daar niet iets voor te verzinnen terwijl je weet dat port redirecting mogelijk is.
Het is negeren van dat soort zaken is de reden van het falen van Linux omgevingen.
Q.E.D. Je begrijpt het dus echt niet... (en waarom verbaast me dat eigenlijk helemaal niet).
Nogal lachwekkend om daar niet iets voor te verzinnen terwijl je weet dat port redirecting mogelijk is.
Het is negeren van dat soort zaken is de reden van het falen van Linux omgevingen.
Dit is jou al tientallen keren verteld maar dan nog maar een keer: Linux daemons draaien helemaal niet onder root. Ze starten - indien nodig - op onder root, reserveren poorten, en laten dan hun root privileges vallen. Resulteert een daemon die niet onder root draait en dus geen toegang heeft tot het hele systeem. Verder nog misvattingen of vragen?
P.S. met dat niet kunnen gebruiken van poorten onder 1024 heeft Linux een extra beveiligingsniveau t.o.v. besturingssystemen die zonder meer toegang tot alle poorten voor iedereen toestaan. Zoals je hierboven kan lezen heeft het nodig hebben van root privileges voor poorten onder de 1014 niet tot gevolg dat software onder root moet draaien. Want je laat de root privileges vallen wanneer je ze niet meer nodig hebt. Best moeilijk te bevatten hè, die technische aspecten...
Dit is jou al tientallen keren verteld maar dan nog maar een keer: Linux daemons draaien helemaal niet onder root. Ze starten - indien nodig - op onder root, reserveren poorten, en laten dan hun root privileges vallen. Resulteert een daemon die niet onder root draait en dus geen toegang heeft tot het hele systeem. Verder nog misvattingen of vragen? …
" Unfortunately, this is no laughing matter, since this vulnerability makes it possible for module code—software components that enhance the functionality of Apache HTTPD servers—and scripts executed via modules such as mod_php to run code with the privileges of the parent process, which is usually root."
Letterlijk staat er dat het gewoonlijk onder root draait. Dat is ook mijn ervaring, standaard installatie onder root want dan werkt het tenminste. Niet zo moeilijk doen. Leg maar eens uit waarom het daar zo staat en waarom die houding gangbaar is.
Best lastig die verkeerde gewoontes met het eigenwijs er aan vasthouden.
Dit is jou al tientallen keren verteld maar dan nog maar een keer: Linux daemons draaien helemaal niet onder root. Ze starten - indien nodig - op onder root, reserveren poorten, en laten dan hun root privileges vallen. Resulteert een daemon die niet onder root draait en dus geen toegang heeft tot het hele systeem. Verder nog misvattingen of vragen? …
" Unfortunately, this is no laughing matter, since this vulnerability makes it possible for module code—software components that enhance the functionality of Apache HTTPD servers—and scripts executed via modules such as mod_php to run code with the privileges of the parent process, which is usually root."
Letterlijk staat er dat het gewoonlijk onder root draait.
Nee het parent process draait onder root. Zie de documentatie hier over hoe het werkt: https://httpd.apache.org/docs/2.2/mod/mpm_common.html#user.
Best lastig die verkeerde gewoontes met het eigenwijs er aan vasthouden.
Het staat er dus niet. Lees de Apache documentatie. Het child process heeft privileges gedropt waardoor het niet meer onder root draait. Daarmee is toegang tot het systeem afgeschermd. De bug waarover het hier in deze thread gaat betreft een probleem waardoor een child process alsnog met privileges van de parent kan draaien (dus root). Dat is een bug die opgelost is of snel gaat worden. Het heeft dus niet met een 'standaard installatie' te maken, zoals jij die meent te ervaren.
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.
