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 »

Howto: Copy/Tee/Clone network traffic using iptables

Having to work with Netflow data for my Diploma Thesis I invested quite some time into the following challenge:
Our Routers export Cisco Netflow Data to HOST A, where we do accounting. I want to use HOST B for several Netflow-related tests. The Routers only support one target for their netflow export (as mentioned, this target is HOST A).

Problem: How is it possible to clone the incoming stream of packets at HOST A and forward one copy into HOST A’s userspace (for accounting applications) and the other copy to HOST B’s userspace (for testing purposes)?
The specific challenge is that I do not want a simple FORWARD to HOST B, but a FORWARD of a copy, so that I can work with the data on both machines. This leads to the next problem: Packets arriving at HOST B have the Destination IP address of HOST A in their IP header. We need to rewrite this IP at HOST B so that userspace applications are able to process these packets (which they are not, if the packets are not destined to HOST B’s address).

Read the rest of this entry »

Quadcore Q6600 Overclocking

Weil es bei dem Intel Core2 Quad (”Kentsfield”) angeblich so einfach sein soll, hab ich es auch mal versucht und eine Übertaktung vorgenommen. Multiplikator bei 9 gelassen, FSB von 266Mhz auf 333Mhz erhöht, VCore vom Mainboard (Gigabyte P35-DS3) automatisch einstellen lassen, Rest Default. Reboot! Und schon is meine Maschine um 25% übertaktet. Von 2,4GHz auf 3,0GHz - das war alles! Leider macht der Boxed-Lüfter dabei ein nicht all zu gutes Bild. Nach unter einer Minute Prime95 Lasttest gehen die Kerntemperaturen schon über die 80°, daher musste nun was neues her: Scythe Mine Rev B. 15cm hoch, mega großes Ding, passt gerade so ins Gehäuse, kühlt aber besser. Core-Temperaturen nach 30 Minuten Prime95 Small-FFT Lasttest bei 70/73/73/70 Grad, bei Large-FFT Tests bleibt es im Schnitt bei 69°. Beim Idlen sind’s um die 38°. Unter Last trotz allem noch etwas hohe Temperaturen, aber nicht weiter tragisch. Der Q6600 in der G0 Stepping Variante ist zwar nur bis 71° offiziell quälbar, bevor gethrottled wird, allerdings ist dies die Angabe der CPU Temperatur, die etwa 10° unter der Temperatur der Kerne liegt. Everest sagt unter Last: 61°. Die Temperaturen ausgelesen habe ich mit CoreTemp und Everest Ultimate. CPU-Z sagt, dass der Rechner auf den vollen 3GHz läuft, also nicht gethrottled wurde trotz hoher Kerntemperaturen. Und stabil läuft er auch nach über einer Stunde Vollast. Passt also - oder gibts Einwände?…

UPDATE: Nachdem ich den Rechner wieder in die Vertikale gestellt habe stiegen die Temperaturen unter Last auf einmal ins Unermessliche, yikes!! Was war passiert? ;) Die Pushpins saßen wohl nicht so fest… Naja, jedenfalls sitzt der Lüfter jetzt richtig und von den oben genannten Temperaturen könnt ihr nun ruhig ein paar Grad abziehen, nach 30 Minuten Last bleibe ich jetzt bei allen Kernen unter 60° (49° CPU Temperatur), beim Idlen bin ich bei 33-38°. Besser. Dafür rasselt der Lüfter ein bissl, aber das is mir jetzt erstmal egal, jetzt hab ich kein Bock mehr, das legt sich oder hört sich hoffentlich weg ;)

UPDATE: Lüfter eingeschickt und austauschen lassen :(

Google und der DAX

“DSL-Kunden der Deutschen Telekom klagen darüber, dass sie alle Dienste und Domains von Google seit etwa 16:00 Uhr am heutigen 6. März 2008 nicht mehr aufrufen können. Auch durch Eingabe der IP-Adresse sind die Google-Angebote derzeit nicht nutzbar. Aber auch einige andere Webseiten sollen von dem Problem betroffen sein.” –golem.de

Zur selben Zeit, 16 Uhr, schwankt der DAX nach unten. Zufall? Komisch allemal ;) Wo lag das Problem? Telekom sagt, dass “keine Störung in der eigenen Netzinfrastruktur erkennbar” war und Google’s Server liefen auch problemlos…

dax2.png