Datenleck bei Saturn: Alles nur eine Frage der Technik?

Die geflügelten Sprüche von Saturn, die man zu genüge aus Funk und Fernsehen kennt, werden mit dem aktuellen Datenleck im MP3-Shop ad absurdum geführt. So war es durch einfaches Surfen auf den Seiten des MP3-Shops möglich, auf die Daten von Dritten zuzugreifen – ohne irgendwelche Eingriffe in URL oder ähnlichem. Das ist ein klares Zeichen für einen Bug im Session Management der Applikation, einem Aspekt, der bei jedem ordentlich ausgeführten Web Application Penetrationstest eigentlich überprüft werden müsste. Durch den Fehler in der Web Applikation kam es nun also zu ungewolltem Session Hijacking durch Dritte.

  • Geiz ist geil?
  • Alles nur eine Frage der Technik?

Zumindest wenn es um die Sicherheit der Kundendaten geht, ist Geiz zumindest nicht so geil. Lustig, dass Saturn trotzdem verspricht: “Ihre bei uns gespeicherten Daten schützen wir und unsere Partnerunternehmen durch technische und organisatorische Maßnahmen, um einem Missbrauch durch Dritte wirkungsvoll vorzubeugen“.

Datenklau ganz leicht gemacht

Der große Datenklau-Skandal bei der Telekom ist noch nicht lange her. Dass ein solches Fiasko ein Unternehmen in schlechtes Licht rücken kann, ist jedermann klar. Trotzdem ist es immer wieder erschreckend, auf welch leichte Schulter einige Unternehmen ihre Datensicherheit nehmen. Naivität ist hier ganz groß geschrieben – erst recht, wenn eine Lücke bekannt ist, aber sich einfach keiner darum kümmern mag/darf/soll.

Vor ein paar Jahren hatte ich mich bei einer Agentur eingeschrieben, die Hochschulabsolventen, Young Professionals und Studierende in Teil- oder Vollzeit an Unternehmen vermittelt. Nachdem ich nun (auf anderen Wegen) einen Job gefunden habe, wollte ich meine Daten dort löschen (lassen). Zugriff auf sein eigenes hinterlegtes Profil in der Datenbank (für Updates) erlangte man über einen einfachen Link der Form

http://www.firma.xx/xxxxxxxx/xxxxxx.php?id=<userID>&hash=<someHash>

Verdächtig genug – keinerlei weitere Authentifikation. Der Hash, als Mapping auf die ID, sollte wohl Verifikation genug sein, um nicht auf andere Daten zugreifen zu können. Eine Art Passwort also, das der User jedoch nicht kennen muss, außer er will seine eigenen Daten updaten. Dann bekommt er den Link über die Firma zugeschickt. Um die Daten zu löschen fand man im eigenen Bestand jedoch keine Möglichkeit, also bat ich darum per e-mail. Long story short: Trotz Versicherung, dass die Daten gelöscht würden, geschah lange nichts und ich musste die Jungs dort vier Mal anschreiben – eigentlich unverschämt. Irgendwann wurde es mir zu viel und ich begann, das oben genannte Mapping über den Hash auf Sicherheitstauglichkeit zu überprüften. Die Sicherheitslücke, die ich dort fand, war gravierend. Letzendlich wurde der Raum, den der Hash bot, nicht einmal voll ausgenutzt, was es prinzipiell ermöglicht, über einfachste Brute-Force Techniken Nutzerdaten auszulesen. Eine kleine Hochrechnung zeigte, dass nur wenige Trial & Error Requests zur vollkommenen Entblößung des Datenbestandes weiterer Nutzer führte. Das Krasse an der Geschichte ist jedoch, dass das Unternehmen trotz meiner sofortigen Alarmierung mit der dringenden Bitte, diesen Security-Fauxpas zu fixen, bis heute (drei Wochen später) nichts dergleichen unternommen hat. Nicht einmal ein Statement wurde dazu abgegeben, ich bekam keine Antwort auf den Sachverhalt. Aber wenigstens habe ich erreicht was ich eigentlich wollte: Meine Daten sind gelöscht und damit erstmal sicher…

Cutwail and Rustock/Costrat: Same Command-and-Control Network

Yesterday I posted an analysis of Cutwail, today, while analyzing a Rustock/Costrat binary, I found something interesting:

Cutwail issued the following command to 208.66.194.232:80 (hosted by McColo, known for hosting nefarious stuff)
GET /40E80010484449525657494F5357594C49584F456C000000066600000000760000046BEB000530CDE1E7ED HTTP/1.0

receiving the answer from the web server

HTTP/1.0 200 OK
Date: Fri, 29 Aug 2008 18:21:44 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch9
Last-Modified: Fri, 29 Aug 2008 18:21:44 GMT
Cache-Control: no-cache
Content-Length: 326160
Connection: close
Content-Type: application/octet-stream

followed by an encrypted/encoded binary. I have not been able to check that file out by now, but I might provide it to the interested reader upon request. The Rustock/Costrat binaries connect to the same network. These connections by Rustock to 208.66.194.0/24 are verified by Symantec and ThreatExpert.

Yet another proof that the top spam botnets are linked together in certain ways, this time in command-and-control.

A little Cutwail spambot analysis on network traffic

Recently, while analyzing network traffic of a Cutwail binary (a spambot commonly installed by a trojan of the Pushdo family), I found some interesting behavior in its command-and-control communication. Although I expected some encrypted HTTP communication on port 4080 as stated in the recent research about the TOP Spam Botnets from April 2008, I found a completely different setup. First, there have been over a dozen backend nodes (motherships) all in the 216.195.[52-63] range. Analyzing the binary revealed more hard-coded IP addresses in Russia and the US: Read the rest of this entry »

New Fast-Flux Domains served by Warezov/Stration

Quick and dirty: Some new domain names (most of them created end of last week (7th-9th of August)) found during my analysis of a Warezov/Stration Binary. All of them are fast-fluxed. Expect some spam with these domains pretty soon. It probably already started, as my Honeypot served a lot of DNS Queries. Some domains already work (“European Pharmacy“, see screenshot), others still don’t. Domain Name List:
Read the rest of this entry »

New Storm Campaign and Domains

Now I am not a tracker of storm campaigns nor binaries, I am just a casual binary analyst, but today while running a storm gateway for research purposes, I found some new domains going along with the revisited love theme and its postcard.exe.

worldpostcardart.com
superlettercard.com
yourlettercard.com
freepostcardonline.com
digitalaudiopostcard.com
lettercardadvertising.com
bestlettercard.com
audiopostcardmail.com
supergreetingcard.com
oldpostcardshop.com

While all the above domains have been created on August, 2nd, the following domain offers the Nameservers and has been created on July, 28th

brprbgok6.com

Diging these domains returns one IP with a TTL of 60 seconds, indicating Fast-Flux. I have not investigated earlier campaigns, but I wondered why only one IP was returned; typically for Fast-Flux, there is a whole bunch of short-lived IPs returned for one domain name.

The campaign’s website is kept simple:
Your download will start shortly. If you are unable to see your postcard, save it in and run on your computer.

The Binaries’ AntiVir Detection Rate is 19/36 (52.78%)

As I am the first to blog this and as I am currently not running a Storm Spambot, I guess we need to wait for Jeremy to fire up his automated extraction scripts for more insight on the respective spam messages ;)

Update Aug 6th: Today I found more information on the spam messages at the Trend Micro Blog: http://blog.trendmicro.com/storm-uses-old-bait/.
Took them some time though…

Interesting Pattern in Storm Worm Traffic

Thorsten Holz kindly offered to blog my findings in Storm Worm Traffic for a larger readership. Maybe there will be some ideas on the mentioned patterns…

Forensics: Anatomy of a Drive-by-Download Attack

The other day I checked a rarely used website of mine for its its source, where I found some suspicious code. It seemed to be some kind of malicious iframe code for drive-by downloads, so I started my investigation on it. Be alarmed: I will NOT censor any of that code, so be sure NOT to visit these websites unless you know what you are doing.
Read the rest of this entry »

Cross Site Scripting (XSS)

Wer sucht, der findet. Es ist unglaublich, wieviele große Websites mit einem anerkannten Unternehmen dahinter heute noch für XSS (Was ist XSS? Man konsultiere Wiki oder Heise) anfällig sind. Dabei kann es echt gefährlich werden obwohl es so leicht zu umgehen ist.

Angefangen hat alles damit, dass der Karlsruher Stadtblog meinen BjOG verlinkt hat. Allerdings nicht freiwillig. Was man hier sieht ist eine einfache XSS-Attacke gegen die Website des Stadtblogs, die dann (across-sites) meinen Blog in einem iframe lädt. Das kann böse ausgenutzt werden, wie das Beispiel von Saturn zeigt (Notiz: Hier muss man zunächst auf Saturn.de gehen um sich ein Cookie abzuholen (wenn man noch keines hat), indem man eine Filiale auswählt.) Der Elektronikkette habe ich auch eine bösartige Seite untergejubelt, mehr schlecht als recht an deren Design angepasst und könnte somit z.B. leicht Kreditkarteninformationen von Usern ergattern oder Cookies und damit Usersessions hijacken.
Auch die Frankfurter Allgemeine Zeitung (FAZ) ist vor XSS-Attacken nicht gefeit. Das Unterjubeln gefälschter Seiten oder der Diebstahl von Cookies und das damit verbundene Account Hijacking durch komplettes Umgehen des Authentication Prozesses sind so kein Problem mehr, wie man auch bei Die Welt sehen kann. Die dort gezeigten Cookie Credentials hätte ich ohne Probleme an mich senden lassen können. Hier war der Aufwand jedoch etwas größer, da die Welt den User-Suchstring augenscheinlich nur per POST übermittelt, was auch gut so ist, denn das verhindert zumindest URL-basierte XSS-Attacken. Leider kann man das bei der Welt jedoch auch umgehen, indem man aus dem Code die nötigen POST Variablen extrahiert und über die URL als GET interpretieren lässt. Bugfix: Clientinformationen nur als HTTP POST annehmen…

Wie man sieht ist XSS ein seriöses Problem, dem leider nicht so viel Aufmerksamkeit zukommt wie es sollte. Dabei reicht es doch schon, die Inputdaten von Usern entsprechend zu filtern. Die oben genannten Beispiele sind bei weitem nicht die einzigen, viele weitere große Betreiber, die ich hier jedoch nicht liste, sind davon betroffen. Dies soll nur ein kleiner Warnschuss sein. Nach der Veröffentlichung dieses Beitrages habe ich umgehen die Websitebetreiber informiert. Ich bin mal gespannt, wielange es braucht, bis die ersten reagieren.

edit: Falls die Lücken geschlossen werden sollten, hier die Beweis Screenshots:

xss_stadtblog.jpgxss_saturn.jpgxss_faz.jpgxss_welt.jpg

edit: Wow, das ging schnell, der stadtblog is schon gefixt!

Advanced Packet Capturing Howto: PF_RING, NAPI and extended libpcap on Debian Sarge

Working on my student research project, I have to monitor a quite large network. Therefore, I have configured one of the main switches to mirror the traffic to my hi-end sniffing machine. Trying to capture the traffic with software depending on libpcap, I encountered massive packet loss almost immediately using libpcap-0.8 on Debian (which is version 0.9.5-1). Now I have commited a whole day in trying to decrease the amount of dropped packets. There are some promising solutions, namely mmap’ed libpcap, NAPI (polling-enabled Network Driver) and PF_RING, the latter being the most promising, after having read “Improving Passive Packet Capture: Beyond Device Polling“. Now theory sounds great and is one thing, but getting it to run without any useful documentation almost killed me. Now here is how I finally did it…
Read the rest of this entry »