MAL_HIFIRM auf Index



  • Marc++us schrieb:

    Du kannst es ja an den beiden ersten Postings sehen, die Malware war offensichtlich bekannt, zwei Scanner sprangen an, ich würde also annehmen, daß das die Masse der Scanner detektiert hätte.

    Die Scanner-Meldungen in den ersten Postings sehen eher nach Heuristiken aus. Ein <iframe> direkt hinter </html> ist wahrscheinlich so verdächtig, dass das viele Scanner triggert.



  • Christoph:
    Habe leider gerade keine Linux shell am laufen, aber hast du es schon mal mit einem Windows-User-Agent probiert? Vielleicht ist Linux dem Script ja zu heikel. 😃

    zB. "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)"



  • Nobuo T schrieb:

    Christoph:
    Habe leider gerade keine Linux shell am laufen, aber hast du es schon mal mit einem Windows-User-Agent probiert? Vielleicht ist Linux dem Script ja zu heikel. 😃

    zB. "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)"

    Hilft leider nicht. Ich habe vorhin noch probiert, Cookies zu akzeptieren, das hat aber auch nichts gebracht.



  • Marc++us schrieb:

    Nicht wirklich, der Ratschlag lautet: aktueller Virenscanner. Du kannst es ja an den beiden ersten Postings sehen, die Malware war offensichtlich bekannt, zwei Scanner sprangen an, ich würde also annehmen, daß das die Masse der Scanner detektiert hätte.

    Da bei Dir nichts angesprungen ist, würde ich davon ausgehen daß nichts passiert ist und es sich nicht um einen bisher völlig unbekannten Hack handelt, den noch kein Scanner erkennt.

    Ein vollständiger Systemscan sollte Dir diesbezüglich Sicherheit geben.

    Die sind nicht auf die Malware angesprungen (falls wirklich was heruntergeladen/installiert wurde). Das sieht nach heuristischer Erkennung von den eingeschleusten Exploitversuchen aus. Sprich die sind auf das was das iframe gemacht hat angesprungen.

    Edit: Und leider können das die wenigsten kostenlosen Anti-Malware Scannern erkennen.



  • Der TrendMicro Agent hatte ausserdem noch eine URL gesperrt die versucht wurde zu öffnen. Kann sein das es die im Post von Christoph beschriebene convart.com war, aber sicher bin ich mir nicht mehr.



  • Leider hab ich von sowas so gut wie keine ahnung.
    Ich meine, um eine Datei zu verändern, braucht man doch root zugang?!
    Und irgendwie muss der ja dann das Root-PW rausbekommen haben oder?

    Außerdem frag ich mich wie ihr sowas raus bekommt das es da angriffe gab.
    Da ich auch häufiger mit PHP arbeite, meist aber local, interessiert mich vorallem wie so ein angriff zu erkennen ist. Noch bin ich im Studium. Aber danach möchte ich in diesem bereich auch arbeiten. Vllt kann ja jemand der so richtig ahnung hat, und außerdem vllt noch ein bischen freizeit, im bereich Rund um den PC oder in Webzeugs mal ein Thema aufmachen und das alles erklären und ein paar muster-logs posten wie sowas aussieht??
    Und so neben bei auch mal kurz erklären, wo der unterscheid ist wenn ich php 5.2.xx oder PHP 5.3.x laufen habe. weil local merk ich da nichts...
    Ich denke das sprengt hier den rahmen, deshalb wäre ein extra thema vllt nicht schlecht...

    Wäre echt cool wenn da jemand mit richtig viel Ahnung mal was kleines verfassen könnte... Vllt auch so in schritten, wie dieses Betriebssystem-tut was hier entstanden ist. Denke hier wird das vllt noch mehr interessieren. Grade hinsichtlich der Aktuellen Situation hier im Forum.

    So long
    Sqwan



  • Sqwan schrieb:

    Ich meine, um eine Datei zu verändern, braucht man doch root zugang?!

    Nein, Zugang zum Ändern der Dateien reicht. Dafür braucht man keine root-Rechte, weil die Dateien normalerweise nicht nur von root änderbar sind.

    Sqwan schrieb:

    Und irgendwie muss der ja dann das Root-PW rausbekommen haben oder?

    Nein, das root-Passwort ist nur eine Möglichkeit von vielen, root-Zugang zu bekommen. Normalerweise bekommt ein Angreifer aber nicht root-Zugang, wenn er PHP-Lücken ausnutzt.



  • Es kommt natürlich auf die Lücke an. In den meissten Fällen wird es wohl PHP oder SQL sein das irgendwie zur Ausführung gebracht wird. Wie viel Schaden man dann damit anrichten kann hängt dann davon ab, welche Berechtigungen der Dienst bzw der aktive DB-User auf der Maschine hat.



  • Cpp_Junky schrieb:

    Es kommt natürlich auf die Lücke an. In den meissten Fällen wird es wohl PHP oder SQL sein das irgendwie zur Ausführung gebracht wird. Wie viel Schaden man dann damit anrichten kann hängt dann davon ab, welche Berechtigungen der Dienst bzw der aktive DB-User auf der Maschine hat.

    Klar. Aber Webservices mit root-Rechten laufen zu lassen ist seit gut einem Jahrzehnt auch unter drittklassigen Sysadmins nicht mehr üblich. 🙂



  • Auch die Rechte lassen sich exploiten 😉
    Wenn man den Exploit schon mal hat, kann man auch gleich die benötigten Rechte dazu sich zusammenklauen.
    Muss also garnicht sein, das der Wirtsdienst schon die Rechte hat, auch wenns dass natürlich einfacher macht.



  • phlox81 schrieb:

    Auch die Rechte lassen sich exploiten 😉
    Wenn man den Exploit schon mal hat, kann man auch gleich die benötigten Rechte dazu sich zusammenklauen.
    Muss also garnicht sein, das der Wirtsdienst schon die Rechte hat, auch wenns dass natürlich einfacher macht.

    Nur wenn der entsprechende Dienst Sicherheitslöcher hat, die nicht geschlossen sind. Das ist in 0815-LAMP-Setups mit Distributionen mit brauchbarem Qualitätsmanagement leicht auszuschließen.



  • Im laufe der letzten Woche habe ich mich daran gemacht den Exploit Vektor des iframes genauer unter die Lupe zu nehmen.

    Nach dem laden wird ein neues script HTML element erstellt und die attribute src und defer gesetzt. Danach wird das body element gesucht und das script element als Kind element angehängt. Danach wird neuer Javascript Code von dem issue.php script nachgeladen. Per Javascript werden sehr vielen Sicherheitslücken versucht auszunutzen. Darunter sind sehr viele alte Bekannte. Die exploits sind vornehmlich auf den IE ausgerichtet aber auch andere sind nicht gefeit wenn diese z.B. Adobe Acrobat für PDFs automatisch aufrufen.

    Am Ende läuft alles auf den selben payload (shellcode) hinaus welcher folgendes tut:

    • Lädt folgende funktionen aus DLLs:

    • kernel32:ExitThread

    • kernel32:GetModuleHandleA

    • kernel32:LoadLibraryA

    • kernel32:WinExec

    • urlmon:URLDownloadToFileA

    • Führt 'netsh.exe firewall set opmode disable' aus

    • Lädt 1 malware exe nach

    • Führt malware exe aus

    • Ruft ExitThread(0) auf

    Die malware exe die heruntergeladen wurde ist ein sogenanntes Rogue security software Programm. In dem getesteten Fall handelte es sich um 'AntiVirus XP 2010" und hat sich relativ gut im System versteckt.

    Im großen und ganzen kann man schon sagen das dies einer der 'Professionellen' Angriffe auf das Forum war.

    Es ist jedem mit Windows System zu raten sein System mit einem aktuellen Virenscanner zu scannen. Die erkennung des Schädlings ist leider recht miserabel.

    Hier ist eine Übersicht welche der aktuellen Virenscanner den schädling erkannt hat:
    http://www.virustotal.com/analisis/d27a1e9933da1741727f65499b10ee54edbb69fc9b26c1fb14288ff3a1f0230b-1270625856


Anmelden zum Antworten