Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Shellshock: Immer mehr Lücken in Bash

Angriffszenario für NGINX und Apache mit PHP Modul?

  1. Thema

Neues Thema Ansicht wechseln


  1. Angriffszenario für NGINX und Apache mit PHP Modul?

    Autor: ICH_DU 28.09.14 - 00:54

    Ich betreibe einen NGINX Reverseproxy hinter dem sowohl 1 Windows IIS + ActiveSync Proxy steht, als auch ein ein Ubuntu Server mit nem Apache2 als Owncloud Server....

    Ich überlege grade wie groß die Gefahr bei einer solchen Konstellation ist.
    CGI wird nicht genutzt, PHP läuft als Apache Modul.
    Geöffnete Ports sind 80 und 443, sowohl via CISCO ASA als auch direkt auf dem Server per ufw gefiltert, Zusätzlich läuft der ganze Traffic noch über eine NextGen Firewall von PaloAlto (nur prüfbar bei Port 80, 443 ist ja SSL verschlüsselt)

    Aktuelle Patches die via Paketmanagement kommen sind selbstverständlich installiert.

  2. Re: Angriffszenario für NGINX und Apache mit PHP Modul?

    Autor: Anonymer Nutzer 28.09.14 - 01:22

    Na, wenn du mod_php nutzt musste doch keine Angst haben, sofern CGI deaktiviert ist?

    Zumindest hab ich nirgends gelesen das mod_php, mod_python, mod_perl, mod_wsgi etc für die Lücke genutzt werden kann.

    Da du UFW nutzt, tippe ich auf Ubuntu? Da kam doch eh schon ein Update.

  3. Re: Angriffszenario für NGINX und Apache mit PHP Modul?

    Autor: RipClaw 28.09.14 - 01:55

    PyCoder schrieb:
    --------------------------------------------------------------------------------
    > Na, wenn du mod_php nutzt musste doch keine Angst haben, sofern CGI
    > deaktiviert ist?
    >
    > Zumindest hab ich nirgends gelesen das mod_php, mod_python, mod_perl,
    > mod_wsgi etc für die Lücke genutzt werden kann.
    >
    > Da du UFW nutzt, tippe ich auf Ubuntu? Da kam doch eh schon ein Update.

    Ich würde nicht darauf wetten das das nicht ausnutzbar ist.

    z.B. die Funktionen shell_exec, system und die Backtick Operatoren in PHP verwenden unterliegend /bin/sh soweit ich weiß. Das ist in vielen Fällen ein Link auf /bin/bash.

    Bei der Gelegenheit einen besonderen Gruß an alle Entwickler die immer noch einfach "convert" über eine exec Funktion aufrufen statt vorher mal zu checken ob nicht die Imagick Erweiterung für PHP installiert ist und diese dann zu verwenden.
    Wenn ihr das so machen würdet dann könnte man ohne Nebenwirkungen exec Kommandos sperren und damit die Angriffsfläche reduzieren.

  4. Re: Angriffszenario für NGINX und Apache mit PHP Modul?

    Autor: ICH_DU 28.09.14 - 01:56

    PyCoder schrieb:
    --------------------------------------------------------------------------------
    > Na, wenn du mod_php nutzt musste doch keine Angst haben, sofern CGI
    > deaktiviert ist?
    Nichtmal installiert ;)
    >
    > Zumindest hab ich nirgends gelesen das mod_php, mod_python, mod_perl,
    > mod_wsgi etc für die Lücke genutzt werden kann.
    naja wer weis worüber die noch so was finden um die Lücke auszunutzen...
    Gelesen hab ich darüber auch noch nix, aber da so eine Panik wegen der Lücke geschoben wird verunsichert das natürlich trotz dem.
    >
    > Da du UFW nutzt, tippe ich auf Ubuntu? Da kam doch eh schon ein Update.
    jop, Ubuntu Server. Updates sind installiert aber die finden ja ständig neue Fehler in Bash ;)

  5. Re: Angriffszenario für NGINX und Apache mit PHP Modul?

    Autor: El_Duderino 28.09.14 - 11:36

    RipClaw schrieb:
    --------------------------------------------------------------------------------
    > z.B. die Funktionen shell_exec, system und die Backtick Operatoren in PHP
    > verwenden unterliegend /bin/sh soweit ich weiß. Das ist in vielen Fällen
    > ein Link auf /bin/bash.

    Bei Debian und Derivaten (also auch Ubuntu) nicht, da ist das ein Symlink auf /bin/dash, und mich würde stark wundern, wenn das irgendjemand ändern würde. Warum auch?

    Sicherheitslücken sollten also nur dann auftreten, wenn über shell_exec() und Konsorten ein Skript aufgerufen wird, das explizit /bin/bash startet.

  6. Re: Angriffszenario für NGINX und Apache mit PHP Modul?

    Autor: RipClaw 28.09.14 - 12:42

    El_Duderino schrieb:
    --------------------------------------------------------------------------------
    > RipClaw schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > z.B. die Funktionen shell_exec, system und die Backtick Operatoren in
    > PHP
    > > verwenden unterliegend /bin/sh soweit ich weiß. Das ist in vielen Fällen
    > > ein Link auf /bin/bash.
    >
    > Bei Debian und Derivaten (also auch Ubuntu) nicht, da ist das ein Symlink
    > auf /bin/dash, und mich würde stark wundern, wenn das irgendjemand ändern
    > würde. Warum auch?
    >
    > Sicherheitslücken sollten also nur dann auftreten, wenn über shell_exec()
    > und Konsorten ein Skript aufgerufen wird, das explizit /bin/bash startet.

    Das ist aber erst ab Debian 6.0 (Squeeze) so. Vorher war /bin/bash die Shell.
    Bei einem Dist-Upgrade wird das nicht geändert soweit ich weiß.

    Kann also auch aktuelle Debian Systeme treffen.

  7. Re: Angriffszenario für NGINX und Apache mit PHP Modul?

    Autor: furburlong 28.09.14 - 19:29

    RipClaw schrieb:
    --------------------------------------------------------------------------------
    > PyCoder schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Na, wenn du mod_php nutzt musste doch keine Angst haben, sofern CGI
    > > deaktiviert ist?
    > >
    > > Zumindest hab ich nirgends gelesen das mod_php, mod_python, mod_perl,
    > > mod_wsgi etc für die Lücke genutzt werden kann.
    > >
    > > Da du UFW nutzt, tippe ich auf Ubuntu? Da kam doch eh schon ein
    > Update.
    >
    > Ich würde nicht darauf wetten das das nicht ausnutzbar ist.
    >
    > z.B. die Funktionen shell_exec, system und die Backtick Operatoren in PHP
    > verwenden unterliegend /bin/sh soweit ich weiß. Das ist in vielen Fällen
    > ein Link auf /bin/bash.

    Wenn mod_php benutzt wird können allerdings keine Umgebungsvariablen vom Clienten gesetzt werden, darum ist mod_php mit der bekannten Schwachstelle nicht verwundbar.

  8. Re: Angriffszenario für NGINX und Apache mit PHP Modul?

    Autor: Dubu 29.09.14 - 10:15

    ICH_DU schrieb:
    --------------------------------------------------------------------------------
    > Geöffnete Ports sind 80 und 443, sowohl via CISCO ASA als auch direkt auf
    > dem Server per ufw gefiltert, Zusätzlich läuft der ganze Traffic noch über
    > eine NextGen Firewall von PaloAlto (nur prüfbar bei Port 80, 443 ist ja SSL
    > verschlüsselt)

    Na, da würde ich mir doch fast eher Gedanken machen, inwiefern die Firewalls anfällig sind: die Palo Alto Networks Firewalls sind wohl nur durch lokale Nutzer angreifbar und Cisco ASAs sind angeblich nicht betroffen. :)

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Schaltbau GmbH, Velden (Landkreis Landshut)
  2. DATAGROUP Köln GmbH, Frankfurt
  3. SEG Automotive Germany GmbH, Stuttgart-Weilimdorf
  4. Hays AG, Raum Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. 429,00€
  3. ab 369€ + Versand
  4. 127,99€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ricoh GR III im Test: Kompaktkamera mit Riesensensor, aber ohne Zoom
Ricoh GR III im Test
Kompaktkamera mit Riesensensor, aber ohne Zoom

Kann das gutgehen? Ricoh hat mit der GR III eine Kompaktkamera im Sortiment, die mit einem APS-C-Sensor ausgerüstet ist, rund 900 Euro kostet und keinen Zoom bietet. Wir haben die Kamera ausprobiert.
Ein Test von Andreas Donath

  1. Theta Z1 Ricoh stellt 360-Grad-Panoramakamera mit Profifunktionen vor
  2. Ricoh GR III Eine halbe Sekunde Belichtungszeit ohne Stativ

Forschung: Mehr Elektronen sollen Photovoltaik effizienter machen
Forschung
Mehr Elektronen sollen Photovoltaik effizienter machen

Zwei dünne Schichten auf einer Silizium-Solarzelle könnten ihre Effizienz erhöhen. Grünes und blaues Licht kann darin gleich zwei Elektronen statt nur eines freisetzen.
Von Frank Wunderlich-Pfeiffer

  1. ISS Tierbeobachtungssystem Icarus startet
  2. Sun To Liquid Solaranlage erzeugt Kerosin aus Sonnenlicht, Wasser und CO2
  3. Shell Ocean Discovery X Prize X-Prize für unbemannte Systeme zur Meereskartierung vergeben

Orico Enclosure im Test: Die NVMe-SSD wird zum USB-Stick
Orico Enclosure im Test
Die NVMe-SSD wird zum USB-Stick

Wer eine ältere NVMe-SSD über hat, kann diese immer noch als sehr schnellen USB-Stick verwenden: Preiswerte Gehäuse wie das Orico Enclosure nehmen M.2-Kärtchen auf, der Bridge-Chip könnte aber flotter sein.
Ein Test von Marc Sauter

  1. Server Supermicro mit Chassis für 40 E1.S-SSDs auf 2 HE
  2. Solid State Drive Longsys entwickelt erste SSD nur mit chinesischen Chips
  3. SSDs Samsung 970 Pro mit 2TB und WD Blue 3D mit 4TB

  1. Projektorkauf: Lumen, ANSI und mehr
    Projektorkauf
    Lumen, ANSI und mehr

    Gerade bei Projektoren werden auf Plattformen verschiedener Onlinehändler kuriose Angaben zur Helligkeit beziehungsweise Leuchtstärke gemacht - sofern diese überhaupt angegeben werden. Wir bringen etwas Licht ins Dunkel und beschäftigen uns mit Einheiten rund um das Thema Helligkeit.

  2. Telefónica: Software-Fehler beschert O2-Kunden erhöhtes Datenvolumen
    Telefónica
    Software-Fehler beschert O2-Kunden erhöhtes Datenvolumen

    Telefónica gibt sich kulant. Der Mobilfunknetzbetreiber hatte einigen O2-Kunden aufgrund eines Software-Fehlers ein doppelt so hohes ungedrosseltes Datenvolumen angezeigt. Als Reaktion erhalten die betroffenen Kunden das erhöhte Datenvolumen.

  3. Elektroauto-Sounddesign: Und der Benz macht leise "wuuuuh"
    Elektroauto-Sounddesign
    Und der Benz macht leise "wuuuuh"

    Daimler hat die Töne präsentiert, die Elektroautos bei langsamer Fahrt künftig in den USA und in Europa künstlich produzieren, um andere Verkehrsteilnehmer über ihre Präsenz zu informieren. Das Rückwärtsfahren bietet Diskussionsstoff.


  1. 09:01

  2. 08:47

  3. 08:32

  4. 07:53

  5. 07:36

  6. 07:15

  7. 20:10

  8. 18:33