Vraag Hoe te testen of mijn server kwetsbaar is voor de ShellShock-bug?


Hoe kan ik ervoor zorgen dat mijn Bash-installatie niet kwetsbaar is voor de ShellShock bug meer na de updates?


77
2017-09-25 14:25


oorsprong


Zien Is er een korte opdracht om te testen of mijn server beveiligd is tegen de shellshock bash-bug? - Martin Schröder
Let op: er zijn nog twee andere kwetsbaarheden in bash die nog niet zijn gecrawld (CVE-2014-7186 en CVE-2014-7187). - Deer Hunter
Patches die CVE-2014-7186 en CVE-2014-7187 repareren zijn beschikbaar vanaf niet lang nadat Deer Hunter zijn commentaar plaatste. Als je een door distro geleverde patch hebt voor CVE-2014-7169, heb je misschien al genoeg om 7186/7187 te blokkeren, test je je systeem met de onderstaande opdrachten en zie je. Controleer ook voor meer beveiligingsupdates voor je distro. - BeowulfNode42


antwoorden:


Controleren op het beveiligingslek met betrekking tot CVE-2014-6271

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

het zou NIET het woord kwetsbaar moeten nabootsen.


Controleren op het beveiligingslek CVE-2014-7169
(waarschuwing: als de jouwe faalt zal het een bestand maken of overschrijven /tmp/echo die je na kunt verwijderen en moet verwijderen voordat je het opnieuw test)

cd /tmp; env X='() { (a)=>\' bash -c "echo date"; cat echo

het zou het woord date moeten zeggen, dan klagen met een bericht als cat: echo: No such file or directory. Als het in plaats daarvan vertelt wat de huidige datum-tijd is, dan is je systeem kwetsbaar.


Controleren op CVE-2014-7186

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

het zou NIET de tekst terug moeten echoën CVE-2014-7186 vulnerable, redir_stack.


Controleren op CVE-2014-7187

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

het zou NIET de tekst terug moeten echoën CVE-2014-7187 vulnerable, word_lineno.


Controleren op CVE-2014-6277. Ik ben er niet 100% zeker van, omdat het lijkt te vertrouwen op een gedeeltelijk gepatcht systeem waar ik geen toegang meer toe heb.

env HTTP_COOKIE="() { x() { _; }; x() { _; } <<`perl -e '{print "A"x1000}'`; }" bash -c "echo testing CVE-2014-6277"

Een positief resultaat op deze is dat het ALLEEN de tekst terugkaatst testing CVE-2014-6277. Als het perl wordt uitgevoerd of als het klaagt dat perl niet is geïnstalleerd, is dat absoluut een mislukking. Ik ben niet zeker van andere faaleigenschappen omdat ik geen ongepatchte systemen meer heb.


Controleren op CVE-2014-6278. Nogmaals, ik ben niet 100% zeker van als deze test omdat ik niet langer geen ongepatchte systemen heb.

env HTTP_COOKIE='() { _; } >_[$($())] { echo hi mom; id; }' bash -c "echo testing CVE-2014-6278"

Een voldoende voor deze test is dat deze ALLEEN de tekst terug moet echoën testing CVE-2014-6278. Als de uwe terugkeert hi mom overal waar het absoluut niet lukt.


83
2017-09-26 07:49



Kunnen we de algemene test toevoegen? foo='() { echo not patched; }' bash -c foo hieraan? Totdat de functie-exporten in een aparte naamruimte worden geplaatst, zullen we niet stoppen om van de ene parser-bug naar de volgende te rennen. - billyw
Heeft die test een CVE? Heeft u verwijzingen om dit probleem te beschrijven? Ook dit soort informatie kan op een van de andere vragen over shellshock thuishoren, omdat deze Q gaat over het testen van het succes of falen van bestaande patches. - BeowulfNode42
Dat komt uit het blogbericht van Michal Zalewski over een aantal aankomende Shellshock CVE's (lcamtuf.blogspot.com/2014/09/...). Het is zijn voorgestelde test voor CVE-2014-6278, die nog steeds niet openbaar is. Het lijkt erop dat ik het mis had met de algemeenheid van de test. Ik ben al een geval tegengekomen waar de test van Zalewski is geslaagd maar de CVE-2014-7187-test is mislukt. - billyw
En hier is de volledige openbaarmaking op CVE-2014-6277 en CVE-2014-6278, samen met opdrachten om ze te controleren: seclists.org/fulldisclosure/2014/Oct/9 - billyw
Een punt van aandacht: zelfs als de versie van BASH kwetsbaar is, als niets het gebruikt (dwz alle accounts gebruikt door daemons, zoals "www" of "cups" of wat dan ook) zijn geconfigureerd met BASH als hun standaard shell, en geen van uw codes oproepen systeem () of iets dergelijks, de kwetsbare versie is misschien minder riskant, maar upgrade BASH nog steeds zo snel mogelijk. - DTK


Een speciaal ontworpen omgevingsvariabele exporteren die automatisch wordt beoordeeld door kwetsbare versies van Bash:

$ export testbug='() { :;}; echo VULNERABLE'

Voer nu een eenvoudige echo uit om te zien of Bash de code in $ testbug zal evalueren, ook al heb je die variabele niet zelf gebruikt:

$ bash -c "echo Hello"
VULNERABLE
Hello

Als de string "KWETSBAAR" wordt weergegeven, is het antwoord duidelijk. Anders hoeft u zich geen zorgen te maken en is uw gepatchte versie van Bash in orde.

Merk op dat er meerdere patches zijn vrijgegeven door de grote Linux-distributies en dat ze het lek soms niet volledig oplossen. Blijf de beveiligingswaarschuwingen en de CVE-invoer voor deze bug.


32
2017-09-25 14:25



Naast CVE-2014-6271 heeft de onvolledige fix van Red Hat in het bijzonder ook zijn eigen die ook de moeite waard is om te volgen: CVE-2014-7169. - DocMax
One-liner die je shell env niet vervuilt en toevallig werkt, zelfs als je een alternatieve inlogshell gebruikt (die misschien niet bekend is met export): env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello" - Lloeki
Er zijn enkele Ubuntu-specifieke details hier askubuntu.com/questions/528101/... - persoonlijk moest ik upgraden van Ubuntu 13.10 naar 14.04 om het probleem op te lossen - dodgy_coder


ShellShock is praktisch een combinatie van meer dan één kwetsbaarheid van bash, en op dit moment is er ook malaware die misbruik maakt van dit beveiligingslek, dus ShellShock kan een probleem zijn dat nog steeds open is, er is een thread met updates van RedHat over deze problemen.

Redhat beveelt het volgende aan: 

Uitvoeren commando:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

Als de uitvoer is:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

je hebt geen oplossing.

Als de uitvoer is:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

jij hebt CVE-2014-6271 repareren

Als uw uitvoer is:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

je bent niet kwetsbaar.

Het andere deel van ShellShock-controle is de CVE-2014-7169-beveiligingsscheck zorgt ervoor dat het systeem is beschermd tegen het probleem met het maken van bestanden. Als u wilt testen of uw versie van Bash kwetsbaar is voor CVE-2014-7169, voert u de volgende opdracht uit:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

Als uw systeem kwetsbaar is, worden de tijd en datum weergegeven en / tmp / echo gemaakt.

Als uw systeem niet kwetsbaar is, ziet u uitvoer als:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory

2
2017-09-29 14:43





Ik schreef een CLI-hulpprogramma genaamd ShellShocker om uw webserver te testen op kwetsbaarheden op CGI-scripts. Als u uw site wilt testen, voert u het volgende uit:

python shellshocker.py <your-server-address>/<cgi-script-path>

d.w.z

python shellshocker.py http://example.com/cgi-bin/possibly-vulnerable-script.cgi

EDIT: dit hulpprogramma is verwijderd, sorry: '(


2
2017-09-26 17:24



Je link is dood - SSK
@SSK Sorry;) Mistype. - Liam Marshall
Je link is nog steeds dood. - Mxx
Ja, sorry, ik heb het naar beneden gehaald. Het werd uitgebuit op manieren die ik niet leuk vond. - Liam Marshall


U kunt uw CGI-URL indienen bij deze online test:

http://shellshock.iecra.org


1
2017-09-25 20:46



Het is beleefd om redenen voor downvotes te geven. - David
"We loggen alle scans" ??? Griezelig. Ik zou de python downloaden en hem zelf uitvoeren. - Brad
@brad vertellen het je tenminste. Ik ben er zeker van dat als ik een whitehat-beveiligingsdienst zou aanbieden die deze service zou aanbieden, ik misschien een log (als enige teller zonder individuele details) zou bijhouden van hoeveel mensen blindelings hun sitegegevens hebben ingevoerd in een website die zei dat het ging om een ​​penetratietest uit te voeren, zonder veel af te weten van de authenticiteit van de site die de test aanbiedt ... en ze wilden een logboek van wie testte wat als iemand zijn service gebruikte om ook kwetsbare sites van anderen te vinden ... - Rob Moir


type env x = '() {:;}; echo kwetsbare 'bash -c' echo dit is een test 'en als dit kwetsbaar terugkomt en dit een test is, betekent dit dat uw OSX / Linux-machine wordt beïnvloed. Oplossing is om te updaten naar de nieuwste versie van bash.


-1
2017-09-27 11:33



Waarom als root? Helemaal overbodig. - Mat