image

Hackertool voor platleggen Apache webservers

vrijdag 19 juni 2009, 09:45 door Redactie, 25 reacties

Een bekende beveiligingsonderzoeker heeft een programma online gezet waarmee het kinderspel is om Apache webservers plat te leggen. Apache is de populairste webserver voor het hosten van websites en wordt door talloze bekende sites gebruikt. Slowloris, zoals de tool heet, houdt alle verbindingen open door gedeeltelijke HTTP requests te sturen. De server wacht tot de volledige header binnenkomt, maar Slowloris stuurt die niet en blijft de nep-headers sturen, die de verbinding openhouden. Hierdoor raakt de webserver uiteindelijk overbelast en is er sprake van een Denial of Service.

Volgens Robert "RSnake" Hansen die de tool ontwikkelde, zijn met name servers met threading kwetsbaar. Dit komt omdat ze de hoeveelheid threading die ze toestaan proberen te beperken. De DoS-tool moet wachten totdat alle sockets beschikbaar zijn, voordat die ze allemaal in beslag kan nemen. In het geval van een druk bezochte website kan het dus even duren voordat dit het geval is. Slowloris is verder van een aantal stealth features voorzien. Zo kan het verschillende host headers sturen, in het geval het doelwit een virtuele host is en de logs apart per virtuele host worden opgeslagen. Als de aanval echter plaatsvindt, worden de logs pas geschreven als de request is voltooid. "Het is dus mogelijk om een server voor minuten uit de lucht te halen, zonder dat het log wordt bijgewerkt om iemand te waarschuwen."

Scriptkiddies
Hansen krijgt het verwijt dat hij hiermee een "leger van scriptkiddies" bewapent. De onderzoeker ontkent dat. Het probleem is namelijk de manier waarop Apache werkt. Volgens het Internet Storm Center, dat bewust niet naar de pagina van Hansen linkt, zijn er geen instellingen in Apache die de aanval voorkomen. Het verhogen van MaxClients maakt het alleen iets lastiger voor een aanvaller. Wie voor zijn webserver de Perlbal reverse proxy neerzet zou de aanval echter kunnen afslaan.

Hansen hoopt dat ontwikkelaars beter gaan nadenken over de architectuur van webservers. Met name als het gaat om het "verwachte" gedrag van de webserver. Daarnaast zou er een standaard configuratie moeten zijn om tegen dit soort aanvallen bescherming te bieden. "Als het geen probleem is, dan maakt het ook niet uit als scriptkiddies het hebben, niet waar? Of het nu wel of geen groot probleem is, het is de moeite waard om erover te praten, aangezien de aanbevelingen van Apache waardeloos zijn." Beheerders van een IIS-webserver hoeven zich geen zorgen te maken, Microsoft's webserver is niet kwetsbaar voor de aanval.

Reacties (25)
19-06-2009, 10:12 door Anoniem
Tja, aannemende dat dit probleem tijdig is aangekaart bij de Apache Foundation, zie ik hier geen probleem in. Men heeft dan immers tijd genoeg gehad om dit punt te ondervangen. Is men doof en stom gebleven, tja, dan zijn er nog voldoende andere alternatieven voor de meeste sites.

Frans.
19-06-2009, 10:16 door Anoniem
dit mag niet hiermee kunnen er miljoenen websites plat worden gelegd
19-06-2009, 10:31 door Anoniem
Microsoft is een keer niet kwetsbaar, dat is het feitelijke nieuws in dit bericht.

Jammer dat Hansen de tool zomaar plaatst. Dit kan voor veel problemen zorgen. Hopelijk zal er snel een oplossing komen voor het probleem waar de tool op in speelt.
19-06-2009, 10:39 door Anoniem
Het probleem is oud en hoort bij een beetje professionele hoster bekend te zijn. Er zijn zelfs al kernel modules voor geschreven. Zo'n module geeft alleen compleet ontvangen headers door aan de webservice.
19-06-2009, 10:59 door Anoniem
Is de oplossing niet heel simpel? Een beetje header is echt niet zo lang en zou dus binnen een paar tellen binnen moeten zijn. Apache zou kunnen zien dat de header erg lang op zich laat wachten en zou dan de verbinding moeten verbreken. Pech voor het request, maar dan moet het request maar opschieten. Requests die zo langzaam zijn, moeten maar op nieuw verstuurd worden.

Opzettelijk verstuurde halve requests zouden dan minder effectief zijn.

- Unomi -
19-06-2009, 11:02 door Anoniem
Zijn we wakker?

Ilja. _\\//
19-06-2009, 12:50 door SavageTiger
Of zou het niet gewoon een oplossing zijn om de maximale threads per IP te limiteren? zover ik weet gebruiken zommige browsers inderdaad simultane connecties om verschillende acties uit te voeren op de webpagina (AJAX bijvoorbeeld), maar als je één IP 5 maximale childs geeft moet dit ruim voldoende zijn.
19-06-2009, 12:52 door Anoniem
Door Anoniem: dit mag niet

yea right... wat denk je te doen ? Apeldoorn bellen?
19-06-2009, 13:04 door RichieB
Zoals SavageTiger al aangeeft is dit simpel op te lossen met [url=http://dominia.org/djao/limitipconn2.html]mod_limitipconn[/url]. Storm, glas water enzo.
19-06-2009, 13:07 door Anoniem
Mag je het op je eigen site testen, is dat legaal?
19-06-2009, 13:42 door RichieB
Tuurlijk. Wie zou dat een probleem vinden? Het is een low bandwidth attack, dus je ISP zal het een zorg zijn. Als je een gedeelde webserver hebt waardoor er ook andere sites plat kunnen gaan is het natuurlijk een ander verhaal.
19-06-2009, 14:19 door roedie
Door RichieB: Zoals SavageTiger al aangeeft is dit simpel op te lossen met [url=http://dominia.org/djao/limitipconn2.html]mod_limitipconn[/url]. Storm, glas water enzo.

Nu kan het aan mij liggen, maar volgens mij klopt dit niet.

Heb het net getest tegen een server met limitipconn maar bij mij word hij gewoon onbereikbaar. Volgens mij werkt limitipconn alleen maar bij volledige connectie zodat hij netjes een 503 terug kan sturen. Aangezien deze tool geen volledige connectie maakt zal limitipconn hier nooit iets tegen kunnen doen....
19-06-2009, 14:30 door [Account Verwijderd]
[Verwijderd]
19-06-2009, 14:48 door RichieB
Door roedie:
Heb het net getest tegen een server met limitipconn maar bij mij word hij gewoon onbereikbaar. Volgens mij werkt limitipconn alleen maar bij volledige connectie zodat hij netjes een 503 terug kan sturen. Aangezien deze tool geen volledige connectie maakt zal limitipconn hier nooit iets tegen kunnen doen....

Je hebt gelijkt. De ap_hook_quick_handler() en ap_hook_access_checker() vuren waarschijnlijk pas af als het gehele verzoek gedaan is. Erg jammer. Dan toch maar op je firewall het aantal connecties per ip limiteren. Daar hoort het ook eigenlijk thuis natuurlijk.
19-06-2009, 16:44 door spatieman
die man is dus PRO IIS :(
19-06-2009, 17:24 door Anoniem
Of gwoon

-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j LOG
-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
-A RH-Firewall-1-INPUT -p tcp --dport 80 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --set
-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j LOG
-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
-A RH-Firewall-1-INPUT -p tcp --dport 443 -j ACCEPT
19-06-2009, 17:40 door prosolit
of gewoon ongeveer zoiets in iptables:

-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j LOG
-A RH-Firewall-1-INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
-A RH-Firewall-1-INPUT -p tcp --dport 80 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --set
-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j LOG
-A RH-Firewall-1-INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP
-A RH-Firewall-1-INPUT -p tcp --dport 443 -j ACCEPT

Mzls

Patrick Noblesse
19-06-2009, 20:48 door Anoniem
volgens mij heeft de suggestie van prosolit geen zin, hij bouwt 1 verbinding op en verstuurt dan vervolgens lege headers waardoor apache elke keer een nieuwe thread start.
ik heb het getest vanmiddag, op het moment dat je het script start stopt de webserver al met reageren.

wat ik heb ingebouwd is een logwatch die monitort op een foutmelding die voorkomt op het moment dat apache de limiet bereikt. mijn apache wordt dan gestopt en een paar seconden later weer gestart, tevens wordt er een drop uitgevoerd van alle active verbindingen die er zijn. zo ben je even veilig. het werkt niet vlekkeloos helaas maar zolang er geen oplossing is kan het helpen
19-06-2009, 21:30 door Anoniem
Door Anoniem: Microsoft is een keer niet kwetsbaar, dat is het feitelijke nieuws in dit bericht.

Je ziet ook een verschuiving plaats vinden. Hackers en dergelijke hebben het nu ook op andere OS gemund. M$ is lang niet meer "the only target".
20-06-2009, 09:21 door Anoniem
In verband met het gebrek aan leestekens heb ik ze even geplaatst.
Door Anoniem: Dit mag niet hiermee.
Wat mag niet waarmee? Ik snap je stelling niet helemaal.
Kunnen er miljoenen websites plat worden gelegd?
Ja, dat stond in het oorspronkelijke bericht, maar misschien snap ik je vraag niet zo goed.
20-06-2009, 10:53 door Anoniem
Oud nieuws.

Apache gaat niet plat alleen tijdelijk zijn er geen connecties meer beschikbaar.

Oplossing o.a. mod_limitipconn.
Naast tcp/ip stack hardening en FW/IDS/IPS.
20-06-2009, 14:14 door rob
Door Anoniem:
Door Anoniem: Microsoft is een keer niet kwetsbaar, dat is het feitelijke nieuws in dit bericht.
Je ziet ook een verschuiving plaats vinden. Hackers en dergelijke hebben het nu ook op andere OS gemund. M$ is lang niet meer "the only target".


Nee hoor.

Apache heeft NCSA webserver opgevolgt... je zou kunnen zeggen dat sinds het begin van het WWW, Apache/NCSA de #1 webserver is geweest. Apache is altijd doelwit geweest voor hackers.

In de code van Apache worden trouwens bijzonder weinig ernstige lekken gevonden. Daarom is er ook meteen paniek in de keet, als er eens een keer wel een tamelijk ernstig security probleem word aangetroffen.
20-06-2009, 14:22 door Eghie
Door Anoniem: volgens mij heeft de suggestie van prosolit geen zin, hij bouwt 1 verbinding op en verstuurt dan vervolgens lege headers waardoor apache elke keer een nieuwe thread start.
ik heb het getest vanmiddag, op het moment dat je het script start stopt de webserver al met reageren.

wat ik heb ingebouwd is een logwatch die monitort op een foutmelding die voorkomt op het moment dat apache de limiet bereikt. mijn apache wordt dan gestopt en een paar seconden later weer gestart, tevens wordt er een drop uitgevoerd van alle active verbindingen die er zijn. zo ben je even veilig. het werkt niet vlekkeloos helaas maar zolang er geen oplossing is kan het helpen
Nee, hij bouwt wel degelijk meerdere verbindingen op.

Laat de volgende commando maar een draaien op de server terwijl je slowloris uittest:

while [ true ]; do netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n; echo "Aantal verbindingen poort 80: "; lsof -i :80| grep ESTA | wc -l; echo '---------------------'; sleep 1; done

Dat iptables commando werkt wel. Ook met deze tool. Kijk maar eens voordat je dit iptables commando gebruikt met die voorgaande commando regel en ernaa.
Je kunt er ook een reverse proxy voor je Apache neerzetten, zoals Perlbal of Varnish ofzo. Die hebben er ook geen last van.
22-06-2009, 16:33 door Anoniem
Door Hugo: Remedie: [url=http://www.hiawatha-webserver.org/]Hiawatha webserver[/url].


Ah, Hugo loopt weer eens z'n eigen brouwsel te pluggen :')

Een andere webserver gebruiken is geen oplossing maar een workaround.
03-07-2009, 11:46 door Anoniem
Onder FreeBSD kun je de accf_http_load kernel module laden. Slowloris kan je server dan niet meer platleggen.

#kldload accf_http

# kldstat
Id Refs Address Size Name
1 4 0xc0400000 97f870 kernel
2 1 0xc0d80000 6a2c4 acpi.ko
3 1 0xc350c000 2000 accf_http.ko

Als je server herstart is deze module niet meer geladen. Voeg daarom het volgende toe aan /boot/loader.conf:

accf_http_load=”YES”

Uit de manual (man accf_http):

This is a filter to be placed on a socket that will be using accept() to
receive incoming HTTP connections.

It prevents the application from receiving the connected descriptor via
accept() until either a full HTTP/1.0 or HTTP/1.1 HEAD or GET request has
been buffered by the kernel.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.