'Criminelen braken in op servers Yahoo door misbruik Bash-bug'

Kwaadwillenden zouden er onlangs in zijn geslaagd om door middel van de recent ontdekte bug in Bash in te breken op servers van Yahoo. Ook kregen zij met dezelfde methode mogelijkerwijs toegang tot Lycos en WinZip, beweert een beveiligingsonderzoeker.

De onderzoeker, Jonathan Hall, ontdekte dat vermoedelijk Roemeense aanvallers toegang tot tenminste twee servers van Yahoo hadden gekregen. Hiervoor maakten zij gebruik van een recent ontdekte kwetsbaarheid in de Bash-shell, waarbij het mogelijk is om malafide code uit te voeren. Vermoedelijk gebruikten de aanvallers de bug om een botnet van Unix-hosts te creëren.

Hall kwam achter de aanval nadat een script op een van zijn servers zocht naar de aanwezigheid van de Bash-bug. Hij gebruikte een zelfgeschreven exploit om vervolgens via Google te kijken welke servers er kwetsbaar bleken voor de bug. Hall ontdekte op die manier dat ook Lycos en de site van het populaire archiveringsprogramma WinZip waren getroffen. Bij de laatste vond hij in de cgi-bin-dir op één van de servers een malafide Perl-script, dat hij identificeerde als ha.pl.

Hall waarschuwde de FBI en de getroffen bedrijven afgelopen weekend. Intussen heeft WinZip de servers gepatcht, laat de onderzoeker weten. Daarnaast zou ook Yahoo de kwetsbaarheid aan het dichten zijn. Dat laat een medewerker aan Hall weten, die van het mailcontact een screenshot online zette als bewijs.

Het beveiligingsprobleem in Bash, ook wel bekend als Shellshock, kwam in de afgelopen maand aan het licht. Het liet kwaadwillenden eigen code in een zogenoemde environment-variabele stoppen, waarna hij werd uitgevoerd zodra een systeem een Bash-sessie initieert. Veel applicaties leunen op shell-scripts en sommige daarvan zijn via het internet te benaderen, bijvoorbeeld cgi-scripts.

Software-ontwikkelaars pletten de bug in de Bash-shell, dat vooral gebruikers van Linux trof, enkele dagen later. Dat gebeurde met twee patches, nadat bleek dat de eerste incompleet was. Ook Apple, dat de Bash-shell met OS X meelevert, komt met een patch. Gebruikers van OS X waren standaard niet kwetsbaar, maar alleen als ze volgens Apple 'geavanceerde' Unix-diensten zelf hadden geconfigureerd.

Reacties (31)

[Jimmy89]

Reddit topic van de onderzoeker:
http://www.reddit.com/r/p...oo_hacked_october_5_2014/

Daarin staat ook een link naar bevestiging van de inbraak:
http://www.futuresouth.us/yahoo_response.jpg

Ook zeer interessant (voor admins) om te lezen, is deze post die alle mogelijke aanvallen afgaat en een universele poc exploit aanbied.
Hierin wordt duidelijk gesteld dat de officiele updates niet alle gaten dichten.
http://lcamtuf.blogspot.n...w-we-finally-cracked.html

Ze refereren hierbij naar 'florian's unofficial patch' die wel alle gaten dicht.
http://lcamtuf.blogspot.n...unofficial-patch-now.html

Ik weet verder niet in hoeverre deze patch gedistribueerd is, maar het lijkt me als admin zijnde zeker het controleren op eigen servers waard.

[Armin]

Hierin wordt duidelijk gesteld dat de officiele updates niet alle gaten dichten.

Het kernprobleem is dan ook tweeledig. Allereerst is de shellshock slechst de exploit-methode van een andere kwetsbaarheid. HeartBleed legde een hele rij andere problemen bloot (zoals user-after free, caching van prive key onderdelen en het niet correct wissen van vrijgegeven stukjes geheugen) die samen een veel groter probleem bleken te zijn dan de heartbleed kwetsbaarheid zelf. Hier niet anders.

Ten tweede echter, het kernprobleem is dat data van een niet geautenticeerde bron ongeverifieerd doorgegeven wordt aan een niet geprivileerd process. Dat is een mond vol, maar betekent in feite dat data van het internet ongecontroleerd doorgegeven wordt aan een process dat niet (altijd) in een sandbox draait.

Dat is de kwetsbaarheid. Er is nu igv bash een echte methode gevonden om van deze design zwakheid gebruik te maken. Bash is een commandshell, en de overdracht van data komend van het internet wordt gedaan via omgevingsvariabelen. Echter bash kent geen onderscheid tussen data en commando's, en door een truc kan nu data doorgegeven wordt, die vervolgens bij uitvoeren als commando's gezien worden. De exacte ernst hangt van van het gebruikte systeem. Sommige websystemen draaien bash in een sandbox zodat de schade wel meevalt bijvoorbeeld.

Maar het kernprobleem is natuurlijk dat data die van het internet komt als 'radioactief' gezien moet worden en niet zomaar doorgegeven mag worden. Dat is echter igv bash extreem moeilijk te fixen, want bash is én extreem flexibel ("er mag veel"), én wordt zeer breedt gebruikt (dus elke verandering heeft de kans iets anders stuk te maken) én nooit ontworpen om data van niet-vertrouwde bronnen te behandelen - itt het is ontworpen van input van de gebruiker zelf te behandelen. Bash is dus gemaakt om fundamenteel alles te vertrouwen ipv wat je in deze context wilt, standaard alles wantrouwen.

Maar wat we niet moeten vergeten is dat bash fixen (of vervangen door een andere shell) het fundamentele probleem niet oplost. Er wordt nog steeds data van het internet 1-op-1 doorgegeven aan een intern process. Veel webservers zullen daarvoor veel grotere - want fundamentele design - aanpassingen moeten uitvoeren.

Het is echter maar zeer de vraag of alle fabrikanten dat gaan doen ...

[Reactie gewijzigd door Armin op 23 juli 2024 00:01]

[Soldaatje]

Zoals op de website van Apache staat:

First of all, you always have to remember that you must trust the writers of the CGI scripts/programs or your ability to spot potential security holes in CGI, whether they were deliberate or accidental. CGI scripts can run essentially arbitrary commands on your system with the permissions of the web server user and can therefore be extremely dangerous if they are not carefully checked.

Het komt er dus op neer dat de ene software vertrouwen heeft in de andere software en zo een ketting vormt. Bash is op dit moment dus de zwakste schakel (voor zover bekend). Of het zinvol is om elk stukje software elke variable te laten checken vraag ik me af, het zal in ieder geval nadelen hebben als meer processor-tijd en grotere bestanden.
Toch is het wel bijzonder dat deze bug zo lang onopgemerkt is kunnen blijven.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 00:01]

[Armin]

Het komt er dus op neer dat de ene software vertrouwen heeft in de andere software en zo een ketting vormt

Exact, en dat is dus precies de fout hier.

Data komende vanaf het internet is in thread models per definitie 'onveilige' data. In het thread model van apache doet momenteel echter niemand verificatie! Iedereen neemt zoals jij aangeeft enkel aan dat de volgende laag het wel doet.

Echter niemand doet het dus en momenteel gaat het dus bij bash inderdaad fout.

De "fix" is van bash is echter nu enkel gericht op het onmogelijk maken van data die van het internet komt als script-commando's te laten uitvoeren, maar dat is enkel het fixen van de specifieke exploit. Nog steeds wordt de data 1-op-1 ongecontroleerd doorgegeven. Enkel bepaalde doorgiften zullen nu leiden tot interne (!) foutmeldingen bij executie van de scripts.

Dat is uiteraard beter, maar 'morgen' wordt er elders in de keten weer iets gevonden wat op een andere wijze wél lukt.

Wat men zal moeten doen is data verificatie. Twee voorbeelden op basis van twee werkelijk gevonden kwetsbaarheden van ShellShock.
1) Client side: DHCP return data moet men kijken of de inkomende data een valide DHCP return pakket is alvorens het aan het DHCP client-script geven. Nu wordt ongeldige data gewoon doorgegeven aan de client-script met ernstige gevolgen betreft code execution. (Gelukkig is deze exploit variant zeldzaam.)
2) Server side: De headers in een HTTP request moeten eerst geparst worden op valide headers, alvorens door te geven aan de cgi-scripts. Nu worden alle headers omgezet in omgevingsvariabelen alvorens het bash script te starten. Na de fix wordt het enkel niet meer mogelijk script code in een variable te krijgen, maar onzin-headers worden nog steeds doorgegeven wat andere exploits wellicht mogelijk maakt.

[Anoniem: 329694]

LET OP: Controleer altijd alle code dat je vanaf het internet download op malicious code, alvorens je het uitvoert.

Voor de liefhebbers.

Met het volgende commando kun je je unix systeem in één klap voorzien van de nodige updates om het probleem in Bash te fixen. "curl https://shellshocker.net/fixbash | sh"

Natuurlijk wil je eerst weten of je vulnerable bent, gebruik hiervoor "curl https://shellshocker.net/shellshock_test.sh | bash"

Shellshock is a vulnerability in bash. In order to patch your vulnerable system, you will need to get the most up to date version of bash available from GNU.org.

Depending on your package manager (yum, apt-get, etc) you may be able to just run a yum update and you'll be good to go.

Je kunt het natuurlijk ook gewoon handmatig updaten dmv repo's:"

Voor CentOS:
yum update bash -y

Voor Ubuntu:
apt-get update; apt-get install --only-upgrade bash

Voor Arch Linux:
pacman -Syu

[Reactie gewijzigd door Anoniem: 329694 op 23 juli 2024 00:01]

[rogierslag]

Om te testen of je vatbaar bent word je gevraagd om van een willekeurige website code af te halen en direct te executen in je terminal, met dezelfde rechten als jij op dat moment hebt Ondanks dat het idee vast legitiem en nobel is, geeft het ook aan hoe makkelijk mensen blijkbaar de zwakste schakel zijn door direct commando's van het internet hun shell in te donderen.

Wees op dit punt gewoon intelligent en laat het over aan apt/yum/pacman door daar te updaten. Weet je zeker dat je binnen je distributie niet ook andere meuk stukmaakt doordat je naar een "te nieuwe" versie overgaat (repo bouwers hebben de patches waar nodig keurig gebackport)

[BartOtten]

Ik zat ook al te grinniken. Net zoals bij Heartbleed schieten er meer websites omhoog dan paddestoelen in de herfst. Hou je bulletins van je distro gewoon goed in de gaten; er zitten mensen dag en nacht klaar om zulke patches te packagen en uit te rollen.

[Anoniem: 1322]

Inderdaad... Ik ken anders nog wel een "rm -rf" commando dat je deze bug ook fixed op ieder systeem met bash...

Mensen moeten gewoon onthouden dat wat je op het internet leest nooit direct te vertrouwen is. Of het nu Wikipedia of een bash commando is wat jou specifieke probleem oplost.

[Anoniem: 329694]

Ik neem aan dat de code door de 'uitvoerders' wel eerst bekeken wordt...

[egnappahz]

je bedoeld Voor Arch Linux:
pacman -Sy && pacman -S bash

[LoneVVolf]

egnappahz,

https://wiki.archlinux.or..._upgrades_are_unsupported

de combinatie van pacman -Sy + pacman -S is bijna altijd een SLECHT idee, zoek maar eens op arch forum / mailing lists.
hier is een goed voorbeeld wat fout kan gaan : http://gist.io/5660494
Zoals unflux hoger aangeeft is pacman -Syu het juiste commando om bij te werken naar de meest recente bash (nu versie 4.3-030 ).

[egnappahz]

Oke, gesnopen.

Bedankt voor de tip

[WhatsappHack]

Morgen: shellshocker.net servet was gehacked.
Tientallen servers gecompromiteerd...
Je kan het inderdaad beter aan de repos overlaten.
Dit doet me denken aan die site om je "private key" te testen op de heartbleed bug Daar waren ook serieud mensen die zo snugger waren hun private key te "controleren".


Ohhh en zo te zien is dit waarschijnlijk de laatste comment die ik ooit kan plaatsen via de Tweakers App.
*pinkt traantje weg* Einde van een tijdperk van gebruiksgemak, doodzonde.

[grep]

Intussen heeft WinZip de servers gepatcht, laat de onderzoeker weten. Daarnaast zou ook Yahoo de kwetsbaarheid aan het dichten zijn.

Dat heeft weinig zin dan meer...

Als je bewezen exploited bent, kan er vanalles aan backdoors en rootkits op je systeem zitten. Full reinstall is dan de enige manier om 100% weer schoon te worden.

[Reactie gewijzigd door grep op 23 juli 2024 00:01]

[mcmd]

Ik mag hopen dat dat dan wel algemene kennis is bij beheerders, anders zijn we echt verloren

[relativity]

Inderdaad. Ook al vinden ze niks, dat betekend niet dat er niks draait.

[calvinturbo]

Backup terugzetten?

[OB1]

Je kan een image terugzetten

[Wyox]

Apple heeft al een patch uitgebracht, het zit alleen nog niet standaard in een OS X update.
http://support.apple.com/kb/dl1769

Ongeacht dat het een security issue is zullen de meeste (standaard) gebruikers geen last van Shellshock bug hebben. In de meeste gevallen gaat het om webservers die via bash commando's uitvoeren om externe applicaties of andere processen aan te spreken.

[Reactie gewijzigd door Wyox op 23 juli 2024 00:01]

[Keypunchie]

Ze vinden hem (vind ik redelijk) niet kritiek voor huis-, tuin- en keukengebruikers.

Daarnaast, hoewel het wel kan, gebruiken maar heel weinig mensen OS X als webserver. De primaire functie die ik doorgaans heb gezien is inzet van OS X voor kantoorautomatisering (fileserver, LDAP, etc.) op kleinere kantoren (met veel Macs).

Het vervelende met deze patch is dat de kans bestaat dat allerhande geavanceerde bash-scripts niet meer werken, terwijl je eigenlijk geen kwetsbaarheid hebt omdat de shell niet (via bvb. cgi) aan het internet/derde partijen is blootgesteld.

Daarom neem ik aan dat in de launch-release van OS X Yosemite deze patch straks gewoon is ingebakken. Wie zijn OS gaat upgraden, kan immers redelijkerwijs verwachten dat sommige applicaties niet meer/anders werken en dan grootschalige scripts eerst getest en aangepast zullen moeten worden.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 00:01]

[drdelta]

"Laat het gat maar open staan, want er zijn toch niet veel mensen geraakt." Wat een onzin. Ze hebben een patch, rol die dan uit naar iedereen. Better safe than sorry.

[Keypunchie]

Als systeembeheerder is het ook je taak om dit soort patches actief binnen te halen. Als je webspul op je Mac activeert, doe je dat niet per ongeluk. Dan hoort het er ook bij dat je het proactief beheert.

Het nadeel van deze patch is dat het veel meer schade kan aanrichten als ze hem automatisch uitrollen dan dat het exploiten van de bug in redelijkheid zou kunnen doen.

Dat uitrollen is helemaal niet safe, dat is dan vooral erg veel sorry.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 00:01]

[Blokker_1999]

Maar als systeembeheerder moet je er op kunnen vertrouwen dat updates gewoon netjes via de normale kanalen binnenkomen. Het kan toch niet zijn dat omdat je een optioneel stukje software hebt geïnstalleerd je ineens zelf in het oog moet gaan houden of er updates voor zijn.

[Keypunchie]

Ben ik het fundamenteel mee oneens!

Als consument mag je dat verwachten, maar als systeembeheerder is het je vak om hiervan op de hoogte te zijn!

Dat Apple het zo oplost is gewoon over de mailinglists heengegaan en ook redelijk wijdverbreid op de Apple/OSX specifieke sites voorbijgekomen. (voorbeeld) Dat hier op Tweakers mensen er nou van opkijken dat niet elke patch altijd maar rucksichtlos in een repository wordt geflikkerd...

(p.s. Je verdient absoluut die +2 voor de hilarische opmerking dat bash een "optioneel stukje software" is. 100% mee eens dat het optioneel is, maar een "stukje software" is toch wat understated, zeker voor OSX. Ik moet nog steeds denken aan de OSX systeembeheerder die ik ooit kende die zo'n fundamentele hekel aan bash had dat hij deze consequent op alle installaties verving door zsh. Dat was bepaald geen peuleschil. *pun*)

[Reactie gewijzigd door Keypunchie op 23 juli 2024 00:01]

[drdelta]

Het nadeel van deze patch is dat het veel meer schade kan aanrichten als ze hem automatisch uitrollen dan dat het exploiten van de bug in redelijkheid zou kunnen doen.

Natuurlijk, meer schade dan ongeautoriseerde derden volledige toegang geven tot een systeem. Droomt u lekker verder.


"Kwaadwillenden zouden er onlangs in zijn geslaagd om door middel van de recent ontdekte bug in Bash in te breken op servers van Yahoo. Ook kregen zij met dezelfde methode mogelijkerwijs toegang tot Lycos en WinZip, beweert een beveiligingsonderzoeker."


Totaal niet de moeite om tegen te beschermen. "Had je zelf die updates maar handmatig moeten downloaden".

[Reactie gewijzigd door drdelta op 23 juli 2024 00:01]

[Keypunchie]

Natuurlijk, meer schade dan ongeautoriseerde derden volledige toegang geven tot een systeem. Droomt u lekker verder.

Geen systeembeheerder, gok ik:
Als je 10 klanten hebt waarbij de patch ertoe leidt dat hun (bedrijfskritische) scripts niet meer werken en maar 1 klant die via bvb. cgi-scripts toegang tot de shell geeft aan het internet.... dan richt je 10x meer schade aan door automatisch updaten dan door de kans op een exploit*.

Het is altijd al zo geweest met patchen: damned if you do, damned if you don't. In dit geval is selectief aanbieden van de patch een verdedigbare beslissing.

Totaal niet de moeite om tegen te beschermen. "Had je zelf die updates maar handmatig moeten downloaden".

Lijkt me sterk dat ze bij Yahoo OSX draaien voor hun webservers, dus wat dit te maken heeft met mijn opmerking, geen idee. Voor verschillende linux-distros zijn de patches wel via de geautomatiseerde kanalen beschikbaar, maar om wat voor reden dan ook, niet op deze (legacy?) servers toegepast.

*Heb je eigenlijk wel een goed idee wat het probleem is met Shellshock? Als jij geen zaken als cgi-scripts met shell-toegang hebt draaien, dan kan je niks gebeuren. De media-hype rond deze bug vind ik zelf ook wat aan de overdreven kant. Het opvallende is dat het zo'n wijdverbreid stuk software en zo'n fundamenteel probleem met de werking is. De risico's zijn vrij makkelijk met een work-around ipv. directe patch af te dekken. Een stuk makkelijker dan een fundamentele patch, zie ook de discussie hironder van Jimmy89 en Armin.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 00:01]

[Conzales]

Het gaat behalve webservers ook om bijvoorbeeld mailservers, routers, IP-camera's en allerlei andere netwerkapparatuur. Het is dus niet alleen een 'webserverlek'. De komende maanden zullen we nog wel meer van deze 'bug' (eigenlijk feature) horen.

[SJBijzitter]

Dank u!

[relativity]

Waar kan ik een dergelijk script vinden. Ik heb zelf namelijk een GNU/Linux webserver thuis.

[Patriot]

Wat bedoel je precies? De scripts om de bug te misbruiken? Of doel je op de updates die het probleem verhelpen? In dat geval hoop ik dat die server niet open en bloot aan het net hangt, want als je de package manager niet kunt vinden gaat dat niet lang goed

[Reactie gewijzigd door Patriot op 23 juli 2024 00:01]

[lord4163]

Sorry? Waarom patchen ze niet? Ik hoef alleen de logs te bekijken om te verifiëren of de update geïnstalleerd is. Zelfs als ik slaap weet ik dat mijn systeem gepatcht is. sudo dpkg-reconfigure -plow unattended-upgrades