We zijn nu ruim een halve week verder - hoe "erg" is deze vulnerability nou gebleken? Zijn er daadwerkelijk sites downgegaan en overgenomen door black-hats? Of bleek het in de praktijk lastiger om kwetsbare servers te vinden?

Ik had een site die kwetsbaar was en die men geprobed heeft maar de kwetsbaarheid was alleen aanwezig als men een
bestaande virtuele server aansprak, en de probes gaven die niet mee. De default server gaf alleen een redirect naar een van
de kwetsbare virtuele servers (domeinnaam) en die redirect werd door de exploit niet gevolgd. Pfew.
De boel is inmiddels gefixed op diverse fronten (waardoor bash helemaal niet meer gebruikt wordt).

Daar komen we wellicht niet achter.
als ik een Linux in eigendom heb genomen middels een script-kiddie-commando, kan het weken of jaren duren voordat ik deze machine in ga zetten, en nieuwe servers van oude cd tjes die in het verkeerde netwerk geïnstalleerd worden, worden als geïnfecteerd voor je de updates kunt draaien. Het punt is denk ik dat de boel 22 jaar open heeft gestaan, en de laatste week met een dikke neon-reclame pijl erbij. Dat er niks weg is, of je dat niet ziet, wil niet zeggen dat er niks extra's is binnengebracht.
Die inmiddels gepatchte webserver? dat is wellicht nu een springplank voor een windows hacker, die as we speak een linux cursus doet om te leren wat ls doet, en wat sudo betekent. maar springplank.php heet hij wel nog kunnen droppen voordat de patch draaide.

Maar ja, hoe groot is die kans nu helemaal? ^^

Het is niet gebruikelijk dat beheerders wiens servers gehacked worden dat meteen wereldkundig maken. Daar komt bij dat de serieuzere scans waarschijnlijk eind vorige week zijn begonnen, en omdat veel servers slecht gemonitord worden (en vaak geen virusscanner draaien) duurt het vaak erg lang voordat ontdekt wordt dat een server gecompromitteerd is.

De meeste exploits voor andere dan de eerste kwetsbaarheid zijn eind vorige week of in het weekend gepubliceerd. Onduidelijk is nog hoe effectief die zijn. Het feit dat Michal Zalewski weinig prijsgeeft over de laatste door hem gevonden bug kan betekenen dat deze ook eenvoudig te exploiten valt. Daarbuiten worden nog steeds nieuwe/andere kwetsbaarheden gevonden.

De eerste meldingen komen vaak uit honeypots. Google: bash honeypot

Doordat er een weekend tussenzat is er nog niet zoveel over te vinden, maar er zijn al wel enkele resultaten. Zie bijv. http://blog.trendmicro.com/trendlabs-security-intelligence/shellshock-updates-bashlite-ccs-seen-shellshock-exploit-attempts-in-brazil/.
Bron: http://www.datacenterdynamics.com/focus/archive/2014/09/vendors-patch-%E2%80%98shellshock%E2%80%99-hackers-attack (hierin worden nog twee andere sites met resultaten genoemd).

Een ander punt is dat je een geldige "cgi-bin" URL moet hebben ("cgi-bin" hoeft daar overigens niet letterlijk in voor te komen) voordat Apache een shell start. Je ziet nu sites opkomen die zowel goedwillenden als kwaadwillenden kunnen helpen; bijv. https://shellshock.detectify.com/ kan een server scannen en maakt daarbij gebruik van "well-known" URL's die tot het starten van een potentieel kwetsbare shell leiden. Die URL's (zoals /cgi-bin/admin.pl) zijn gedocumenteerd in https://docs.google.com/document/d/1vN2QOG2OZIAHGXDmd5wB8FPi-Hin2GaIlWRJ0RYkTbA.

Waar de eerste aandacht vooral uitging naar het patchen tegen remote exploits, is er begin deze week duidelijk een toenemende interesse voor bash privilege escalation exploits. Zoals in http://www.mail-archive.com/cygwin@cygwin.com/msg137461.html staat: Los van dat niet alle interne gebruikers te vertrouwen hoeven te zijn is het ongewenst dat malware op hun PC bijv. rootrechten krijgt op een interne NAS (voor QNap is een exploit gepubliceerd, zie http://seclists.org/oss-sec/2014/q3/806, niet script-kiddy-ready) of een "rogue DHCP server" opzet. Of netwerkapparatuur weet over te nemen, bijv. Cisco heeft ondertussen ook patches uitgebracht, zie http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140926-bash.

Meer geavanceerde exploits zouden van "Javascript port scanning" gebruik kunnen maken, waarbij een webbrowser van een nietsvermoedende gebruiker als spingplank voor het scannen en aanvallen van interne systemen wordt gebruikt (zonder dat de bijbehorende PC gecompromitteerd is). Het is dus ook zaak om intranetservers te controleren en zonodig te patchen!

Voor een redelijk actuele lijst van kwetsbare systemen zie https://www.ncsc.nl/dienstverlening/response-op-dreigingen-en-incidenten/beveiligingsadviezen/NCSC-2014-0595+1.03+Ernstige+kwetsbaarheid+in+Bash+verholpen.html.

With all this hyping around shellshock I have several questions I would like somebody having explained me. I found: http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html

1/ The first thing that wonders me: I see no Privilege escalation or memory leak being mentioned.
When I have access to the shell there is no additional risk. The extra command is run by my credentials in a way that I also could have typed.
Correct?

2/ This limits the impact of vulnerabilities by access methods you are not expected to use a shell.
I see the webservice being mentioned Apache as an example. It could also be a remote login, that easy way for taken over a machine (rat). That is because identification/authentication is missing.
Correct?
Of course the webinterface is an important one.

3/ The observed problem is of the type "code injection". Not an unknown attack options, a very classic one. https://www.owasp.org/index.php/Code_Injection and more dedicated https://www.owasp.org/index.php/Reviewing_Code_for_OS_Injection If the problem was mentioned as being SQL-injection the reaction would be "tell something new"
Correct?

4/ For the webinterface Apache is common used one. It is having environment variables being mentioned as a way to communicate to other programs. I found
http://httpd.apache.org/docs/2.2/env.html - http://httpd.apache.org/docs/2.2/programs/suexec.html
At the moment it is processed and passed to an other program OS calls are involved.
The webserver could have run by a restricted user and the involved run could have defined to run by an other restricted user. The problem of shellshock at this point is the credentials of the webserver process are used. A common habit is to leave that very open because ....
Correct?

I think so because I also have seen thinks like:
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
http://security.stackexchange.com/questions/68146/how-do-i-secure-apache-against-the-bash-shellshock-vulnerability

My question for this all is: Why are all those services running by default with that high privileges that when something gets broken the impact is that high. Would it not be better to run services at the least needed privileges.


Als een gebruiker die al shell toegang heeft dit problem zou kunnen hebben dan was het probleem 20 jaar terug al opgelost. Wat is terug zie komen dat zijn de advanced Unix functies (webservice remote login) waar het Unix process onder hoge rechten draait en men probeert dat af dekken door te beweren dat iemend van buiten daar niets onder kan activeren.

Dat staat ook in deze blog.
http://www.slate.com/articles/technology/technology/2014/09/shellshock_what_you_need_to_know_about_the_bash_vulnerability.html

Ik zie Engelstalige vragen (zijn die van jouzelf of heb je die ergens vandaan gekopieerd?) en een stuk Nederlands dat een antwoord zou kunnen zijn, erg onduidelijk allemaal. Maar goed, ik probeer de vragen te beantwoorden.

1/ Als je gewoon (zonder hacks) een bash shell kunt starten op een systeem heb je niets met de kwetsbaarheden te maken die de afgelopen week zijn gepubliceerd. Wel kun je dan aantonen dat bash kwetsbaar is indien deze ook door het systeem wordt gebruikt zoals beschreven onder 2/ (whitehats publiceren dit soort tests en geen full blown externe exploits om script kiddies niet in de kaart te spelen).

2/ "not expected to use a shell": niet interactief, maar het systeem kan wel een shell gebruiken om een bepaald commando (script en/of programma) uit te voeren. Als de aanvaller informatie mee kan geven die in 1 of meer environment variabelen van bash worden gestopt, en bash is niet gepatched voor CVE-2014-6271, dan kan die aanvaller code naar keuze laten uitvoeren met de rechten van bash op dat moment.

3/ Je zou het een vorm van "code injection" kunnen noemen, maar dit is wel een nieuw type.

4/ Natuurlijk is het verstandig om processen met minimaal benodigde rechten te laten draaien. Maar soms is root noodzakelijk (dhclient bijvoorbeeld), en zelfs bij heel beperkte rechten wil je niet dat een derde daar andere dingen mee kan doen dan bedoeld (zoals spam verzenden, DoS aanvallen uitvoeren, een bankpagina nabootsen etc).

Advies gebruik SELinux: https://www.youtube.com/watch?v=jOT-c0k0bdY

Het nadeel is dat dit totaal ontraceerbare problemen in je systeem geeft.
"cannot open file" met totaal geen info over waarom dit is.
Je kunt je totaal kleurenblind zoeken waarom iets niet weekt als dit er op staat.
Daar zouden ze iets aan moeten doen...

1) patch
2) kijk welke aanvullende maatregelen (zoals SE Linux) mogelijk en realistisch zijn op de betreffende server(s)

Met een MAC benadering waarbij de security benadering centraal beheerd wordt en niet door de "eigenaar" is er ook central logging. Moet je wel gebruik van maken en weten hoe the gebruiken. Altijd maar blijven leren