Klingt doch interessant. Hat schonmal wer eine VM damit infiziert?
MfG
MfG
-
Neuer Gutscheincode unseres Partners Schutzfolien24:
DSLR-Forum2025
Dauerhaft 10% Rabatt auf alle Displayschutzfolien und Schutzgläser der Eigenmarken
"Upscreen", "Screenleaf", BROTECT" und "Savvies".
Der Code ist für alle Geräteklassen gültig. -
Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs September 2025.
Thema: "Straßenfotografie s/w"
Nur noch bis zum 30.09.2025 23:59!
Jeder darf abstimmen!
Zur Abstimmung und Bewertung hier lang -
Ich freue mich bekannt geben zu können, dass das DSLR-Forum einen neuen Aktionspartner gewinnen konnte.
Saal Digital bietet Fotoprodukte in HighEnd-Qualität.
Alle Informationen dazu gibt es demnächst hier. -
In eigener Sache!
Liebe Mitglieder, liebe Besucher und Gäste
ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
Bitte hier weiterlesen ... -
Nicht erreichbare Adressen im Benutzerkonto
Wir bekommen zurzeit eine große Anzahl an E-Mails, die das System zum Beispiel als Benachrichtigungen an Nutzer verschickt,
als unzustellbar zurück, weil z.B. die Adressen nicht erreichbar sind oder das Postfach gar nicht existiert.
Stellt doch bitte sicher, dass die Benachrichtigungen, die ihr vom System erwartet, auch zugestellt werden können.
Nicht erreichbare E-Mail-Adressen sind dazu wenig hilfreich.
Danke!
WERBUNG
Virus Alert bei Bannerwerbung
- Themenersteller castle-of-teck
- Erstellt am
Dazu müsste man wissen unter welchen Umständen genau eine Infektion erfolgen kann (genaue Kombination aus Java-Version und browser)...
Ich bin immernoch am grübeln über dem ca. 1kb grossen Exploit-Code... kein Disassembler kann damit etwas anfangen... der Code scheint sich erst bei Ausführung selbst zu dekomprimieren oder sogar zu entschlüsseln... wäre typisch für einen Exploit-Generator wie Metasploit...
Ich schau mal weiter, aber ich befürchte fast da steigen meine Reverse-Engineering-kenntnisse leider langsam aus...
4.0. Dass es einen Update gab hab ich erst im Laufe des Sonntags, nach dem Schädlingsbefall, erfahren. Das Problem war, dass ich seit Karfreitag auf Reisen war (Hotel) und der Internetzugang naturgemäß eingeschränkt war.
Von den setup1234567890.exe hatte ich auch zwei auf dem Rechner. Filedatum exakt die gleiche Zeit wie Seitenaufrufe im Forum. Die Popup-Fenster hab ich geschlossen und sie wurden von Avira erkannt. Trotzdem mag ich nicht ausschliessen, dass dadurch die Infektion erfolgte.
Also ich krieg nicht mehr raus, ausser dass der Exploit Daten in ein File schreibt, und zwar linkt er auf Windows Kernelfunktionen.. nicht wie erwartet auf irgendwelche Adressen in jre... was genau dahintersteckt kann ich leider nicht rausbekommen, auch existieren offenbar wohl keine Scans auf bestimmte Softwareversionen o.ä. was ich eigentlich erhofft hatte...
Es gibt eine geringe Menge von Daten die herumgeschoben werden, ich kann mit den Werten allerdings nichts anfangen... die ergeben weder als Opcodes noch als Adressen Sinn....
Hier mal das Disassembly falls jemand anderes daraus noch etwas mehr schliessen kann als ich...
Kurze Erklärung: alle db,dw und dd-Zeilen stellen reine Daten dar, keinerlei funktion oder prozedur... das ganze scheint also nichts zu tun, ausser wiederum Daten in den Speicher zu laden und anschliessend in ein File zu schreiben...
Kurioserweise weist nichts drauauf hin, dass dieses File dann auch wieder ausgeführt wird
Fazit: Leider kann ich nicht bestimmen, WER sich nun Sorgen machen muss (aufgrund bestimmter OS/Browser/Java-Versionen) und wer nicht... hatte mir eigentlich mehr Information aus den Files erhofft...
Es gibt eine geringe Menge von Daten die herumgeschoben werden, ich kann mit den Werten allerdings nichts anfangen... die ergeben weder als Opcodes noch als Adressen Sinn....
Hier mal das Disassembly falls jemand anderes daraus noch etwas mehr schliessen kann als ich...
Code:
; Disassembly listing generated by PE Explorer version 1.99
; Heaventools Software (http://www.heaventools.com)
;
;------------------------------------------------------------------------------
;
; Name: .text (Code Section)
; Virtual Address: 00401000h Virtual Size: 0000002Eh
; Pointer To RawData: 00000200h Size Of RawData: 00000200h
;
db 6Bh; 'k'
db 63h; 'c'
db 75h; 'u'
db 46h; 'F'
db 00h;
db 00h;
db 00h;
db 00h;
;------------------------------------------------------------------------------
EntryPoint:
push 00000000h
call jmp_kernel32.dll!ExitProcess
retn
;------------------------------------------------------------------------------
db 90h; '?'
db C3h; 'ƒ'
db E8h; '¨'
db 0Bh;
db 00h;
db 00h;
db 00h;
db E8h; '¨'
db 00h;
db 00h;
db 00h;
db 00h;
jmp_kernel32.dll!CloseHandle:
jmp [kernel32.dll!CloseHandle]
jmp_kernel32.dll!CreateFileA:
jmp [kernel32.dll!CreateFileA]
jmp_kernel32.dll!ExitProcess:
jmp [kernel32.dll!ExitProcess]
;------------------------------------------------------------------------------
000001D2h DUP (??)
;
;
;------------------------------------------------------------------------------
; Name: .rdata (Data Section)
; Virtual Address: 00402000h Virtual Size: 00000080h
; Pointer To RawData: 00000400h Size Of RawData: 00000200h
;
kernel32.dll!CreateFileA:
dd ??
kernel32.dll!ExitProcess:
dd ??
kernel32.dll!CloseHandle:
dd ??
dd 00000000
dd 00002038h
dd 00000000h
dd 00000000h
dd 00002072h
dd 00002000h
dd 00000000h
dd 00000000h
dd 00000000h
dd 00000000h
dd 00000000h
dd 00002056h
dd 00002064h
dd 00002048h
dd 00000000h
dw 0023h
db 'CloseHandle',0
dw 003Dh
db 'CreateFileA',0
dw 009Bh
db 'ExitProcess',0
db 'kernel32.dll',0
db 00h
;------------------------------------------------------------------------------
00000180h DUP (??)
;
;
;------------------------------------------------------------------------------
; Imports from kernel32.dll
;
extrn CreateFileA
extrn ExitProcess
extrn CloseHandle
;
;------------------------------------------------------------------------------Kurioserweise weist nichts drauauf hin, dass dieses File dann auch wieder ausgeführt wird
Fazit: Leider kann ich nicht bestimmen, WER sich nun Sorgen machen muss (aufgrund bestimmter OS/Browser/Java-Versionen) und wer nicht... hatte mir eigentlich mehr Information aus den Files erhofft...
Zuletzt bearbeitet:
Nein.... wie weiter oben schon erwähnt speichert vBulletin keinerlei Accountpasswörter ab, sondern nur gesalzene Hashes davon, aus denen unmöglich auf das Passwort geschlossen werden kann.
Ein Hash kann man sich ähnlich einer Quersumme bei zahlen vorstellen:
Angenommen das Passwort bestünde nur aus Ziffern, dann würde das Forum z.B. nur deren Quersumme speichern und auf diese abprüfen:
Dein Passwort ist 59834 --> Das Forum merkt sich nur die Quersumme 29.
Loggst du dich nun ein, wird aus deinem eingegebenen Passwort wieder die Quersumme berechnet und mit der gespeicherten verglichen. passen die beiden zusammen darfst du rein.
Ein Hacker könnte nie dein Login bekommen, da nur "29" gespeichert wäre...
So, nur wäre bei einer einfachen Quersumme jede Ziffernkombination gültig, die 29 ergibt... das wäre natürlich blöd...
Daher verwendet man entsprechende Hashverfahren. Diese Zeichnen sich durch folgende Eigenschaften aus:
- Es gibt idealerweise keine zwei Zeichenkombinationen, die dn selben Hash ergeben
- Ein Hash lässt sich mathematisch niemals in seinen Ausgangstext zurückführen
- Der Hash lässt keine Rückschlüsse auf Länge, Zeichenverteilung, etc des Ausgangstextes zu
Die einzige Möglichkeit einen Hash schnell zu knacken ist die, bereits im Voraus für jedes mögliche Passwort den Hashwert zu errechnen und dann quasi eine Datenbankabfrage auf den Hash durchzuführen...
Solche Datenbanken werden aber selbst für nur kurze Passwörter mehrere Terabyte gross... und man kann auch dieses Verfahren gegen die Wand laufen lassen:
Hashes werden im algemeinen "gesalzen". D.h. dem Hashalgorithmus wird eine benutzerdefinierte Variable mitgegeben, die er bei der Berechnung einbezieht.
Dadurch ist jedes Hashverfahren quasi einzigartig: Eine komplette Hashtabelle wie oben genannt ist immer nur für ein bestimmtes "Salt" gültig...
Kurz:
Selbst mit Zugriff auf die Datenbank könnte ein Angreifer nur Hashwerte stehlen, könnte daraus aber nicht ohne gigantische Rechenpower und mehreren Jahren Zeit Passwörter ableiten.
Um anders an die Passwörter heranzukommen (z.B. bei der Usereingabe), müsste der Angreifer den Webservice auf dem Server kompromittieren. Das ist normalerweise schon aufgrund der Rechtesituation auf dem Server unmöglich (der "webuser" unter dem der Webservice und alles was über ihn hereinkommt läuft hat keine Rechte Systemdateien zu ändern), sofern kein Privilege-Escalation-Exploit für den Webservice selbst existiert (unwahrscheinlich... ein solcher Exploit hätte einen RIESIGEN Medienwirbel verursacht, da mit einem Schlag Millionen von Webseiten betroffen wären...).
Zuletzt bearbeitet:
)Was haben denn nun aufgrund dieser doch recht dramatischen Erkenntnisse die Recherchen der Boardleitung ergeben? Und was sagt vBulletin dazu?
Gruß
thommy
Gruß
thommy
Seid ihr bzw. vBulletin denn weiter dran? Denn das ganze schreit schließlich nach Aufklärung!
Gruß
thommy
Gruß
thommy
Gast_285548
Guest
Auf jeden Fall ist das "F*ck" schon mal eine schöne ID.
Hast Du mal bitte das Binärfile, damit ich die Hexes nicht abtippen muss?
WERBUNG