2008: G-Archiver Autor sammelt Benutzernamen und Passwörter von Google Mail Nutzern
I was looking for a way to back up my gmail account to a local drive. I’ve accumulated a mass of important information that I would rather not lose. During my search I came across G-Archiver, I figured what the heck I’ll give it a try.
It didn’t really have the functionality I was looking for, but being a programmer myself I used Reflector to take a peek at the source code. What I came across was quite shocking. John Terry, the apparent creator, hard coded his username and password to his gmail account in source code. All right, not the smartest thing in the world to do, but then I noticed that every time a user adds their account to the program to back up their data, it sends and email with their username and password to his personal email box! Having just entered my own information I became concerned.
I opened up a browser and logged in to gmail using his account information. It still worked.
Dieses Spionage-Programm wurde schon 2008 enttarnt; der Autor behauptet inzwischen auf seiner Homepage es hätte sich lediglich um eine Debug-Funktion gehandelt, die vergessen wurde.
Das Programm gibt es inzwischen – wenigstens unter diesem Namen – nicht mehr.
via Jeff Atwood
Flattr ist unsicher
Die Theorie hinter dem Angriff ist relativ einfach erklärt: Damit Flattr wirklich sinnvoll genutzt werden kann, muss man permanent eingeloggt sein. Es wird wohl kaum Nutzer geben, die sich jedes Mal erst einloggen wollen, bevor sie einen Flattr-Button drücken können. Diesen permanenten Login kann man nun missbrauchen, um Webnutzer dazu zu bringen, den Flattr-Button (bzw. den Link, der sich dahinter verbirgt) anzuklicken.
via [Update] Flattr-Manipulation ist (nicht mehr?) möglich! | WeizenSpr.eu.
Gumblar: JavaScript / Java Virus
The virus is split into two parts. There’s a javascript version, which
infects websites, and the actual virus itself which infects computers.
Whenever a browser executes the javascript on a website, it runs a Java
applet and (through a Java exploit or two) installs the virus onto your
computer. The virus, once warm and snug on a computer, looks for any FTP
details you may have stored (In dreamweaver, filezilla, pretty much any
FTP application) and makes a copy of them.
For every FTP it manages to get, it attempts to make a connection and
then infects the website with the javascript. It does this by opening
.js/.html/.php files and attaching a unique version of itself to a
position inside the file, usually at the end. This new code is unique
per website, not per file, so removing it isn’t as daunting as it
sounds.
In addition to spreading itself to every website it can get its claws
on, the virus also reprises its role as a traditional Trojan and
attempts to install other spyware onto your computer, including
redirecting popular websites (such as Google) to its own unsafe
alternative.
Lücke in Datenverschlüsselung des iPhones
Ein verlorenes iPhone stellt ein größeres Problem dar, als bisher gedacht. Denn trotz Verschlüsselung kann der Finder ganz einfach auf Daten wie Fotos oder Audioaufnahmen zugreifen. Das geht selbst dann, wenn der Besitzer sein iPhone mit einem Pass-Code gesperrt hat – und zwar ausgerechnet mit dem Betriebssystem, dem Apple normalerweise nur die kalte Schulter zeigt: Linux!
viaheise online – Lücke in Datenverschlüsselung des iPhones.
Malware auf der Spur
Während man sich früher Viren und Trojaner über den Browser hauptsächlich nur beim Besuch dubioser Webseiten einfangen konnte, reicht dazu heute die Morgenlektüre auf einer populären News-Seite. Zuletzt installierten infizierte Werbebanner auf Handelsblatt.de und zeit.de über Browser-Lücken sogenannte Scareware. Dabei versteckten Kriminelle in Werbebannern ein spezielles JavaScript, die in einem Iframe weiteren Code nachluden, der seinerseits wieder auf eine andere Seite zeigte, wo dann letztlich das Exploit-Toolkit Neosploit verschiedene Lücken in den Plug-ins für QuickTime, Java und den Adobe Reader durchprobierte.
Vorgehensweise “Hacker” auf Shared Hosting Server
Bei einem Webhosting Anbieter wurde ein Shared Hosting Server gehackt. In seinem Blog veröffentlicht er – vorbildhaft – wie die Hacker auf den Rechner eindringen konnten:
- Upload einer PHP-Shell via FTP, das Passwort des Kunden-Accounts wurde vermutlich extern ausgespäht: der Kunde wurde inzwischen gesperrt
- Verwenden eines Kernel-Exploits, um die Rechte des System-Accounts “root” zu erlangen: leider ermöglichte der eingesetzte Kernel den Exploit und war nicht dagegen geschützt
- Ausführen eines “Defacement”-Skriptes, um die ebenfalls hochgeladene index.html auf alle Accounts zu übertragen: dies geht soweit, dass die Partition, die die Dovecot-Indizes zur Performance-Steigerung enthält, ebenfalls überschrieben wurde
- Löschen aller auffindbaren Log-Files und Rückschlüsse auf den Angreifer
Da wir jedoch zusätzliche Logs führen, die speziell geschützt sind, sowie das Skript des Angreifers nur Log-Dateien in einem bestimmten Schema gelöscht hat, konnten wir den Weg wie oben beschrieben einigermaßen nachvollziehen. Der Angreifer hat dabei eine IP-Adresse eines türkischen DSL-Anbieters verwendet, wodurch Strafanzeige o.ä. unsinnig ist – der Täter kann niemals ermittelt werden.
