marderh.blog

…sorgt dafür, dass Festplattenverschlüsselungssysteme (z.B.: Truecrypt oder dm-crypt), unter Idealbedingungen, geknackt werden können:

The root of the problem lies in an unexpected property of today’s DRAM
memories. DRAMs are the main memory chips used to store data while the
system is running. Virtually everybody, including experts, will tell you that DRAM contents are lost when you turn off the power. But this isn’t so.(Introductory blog post – Freedom to Tinker)

Das ganze Research-Paper, ein Video und mehr gibts auf der Seite der Forschungsgruppe. Der gebräuchlichste Nutzen von Festplattenverschlüsselung, wie z.B. die Daten auf einem gestohlenen/verlorenen Notebook zu schützen, ist damit allerdings zum Glück weitgehend nicht dahin. Ausser man trägt das Teil die ganze Zeit im Suspend-Mode herum. Hab ich aber bisher nur bei Mac-Usern gesehen. SCNR

Schon lang nicht mehr angesehen…
Die Sammlung von Google-Suchstrings, die Informationen zutage fördern, die eigentlich nicht öffentlich sein sollten ist ziemlich angewachsen (siehe die Google Hacking Database von johnny).
Wars auch bisher keine Hexerei die URLs oder Suchstrings von dort in den Browser zu kopieren, haben Cult of the Dead Cow (cDc) mit Goolag (hier die Ankündigung) das ganze wirklich Massen- und somit auch DAU-kompatibel gemacht. Selbige haben ja vor x-Jahren mit Back Orifice ähnliches vollbracht.

(via Google-Hacking Deluxe – heise Security)

In aller Kürze: Jikto ist ein Vulnerability-Scanner der komplett in JavaScript geschrieben ist und somit auch einfach in eine Webseite eingebettet, oder per CrossSiteScripting (XSS) ausgeführt werden kann. Und das im Browser des (ahnungslosen) Benutzers der Seite. Vorgestellt wurde das Ding von Billy Hoffman auf der Shmoocon vor ein paar Tagen:

” The masses desire the sweet taste of 0-day? No problem.
I’ll give a live demo of Jikto, a complete web application vulnerability scanner written entirely in JavaScript. Jikto silently crawls and audits any public website and sends the results to a 3rd party. Jikto can be embedded into any website or XSS payload turning website visitors into accomplices that will scan and attack webservers on the Internet.”

Die Slides zu dem Vortrag gibt es hier.

Soweit so gut, den Sourcecode dazu hat er allerdings damals für sich behalten. Von anderen Fällen dieser Art ist eh hinlänglich bekannt wie lange sich so etwas geheimhalten lässt…

Jikto ist somit irgendwie veröffentlicht und findet sich zumindest derzeit noch auf business.name.

Obwohl:

“ It appears that the source code to Jikto is in the wild. I suppose it was only a matter of time, even though as you will see SPI to extreme steps to prevent this from happening.” (aus dem Blog der Firma des Autors)

Ja klar, BRUHAHAHA

Also viel Spass mit dem Source und auf das mir keiner blind wird bei soviel JavaScript.

War wohl ziemlich daneben, der Griff nach dem Rechner seiner eigenen Kundschaft.

Eine schön ausführliche Chronologie der Ereignisse findet sich im Blog von soryelectronics.com:

Die Geschichte war für mich persönlich ja die Hauptbelustigung der vergangenen Tage:
Sony lässt von eine (offenbar) mässig kompetenten Softwarebude, ein Kopierschutzsystem für ihren Audio-Content (sprich CDs) entwickeln. Dieses nistet sich gleich einem Rootkit unsichtbar in den Rechner des Kunden ein und erzeugt so natürlich ein massives Sicherheitsproblem für die Betroffenen.
Zuerst stellt sich Sony natürlich dumm und leugnet diese Probleme, in weiterer Folge hält man die eigenen Kunden für zu blöd um diese ach so komplexe Problematik zu verstehen. Ein Uninstaller wird angeboten. Der verhindert allerdings dann das Abspielen der CDs und öffnet dafür andere Hintertüren.
Der öffentliche Druck steigt und Sony beschliesst offenbar doch die CDs zurückzurufen.
Dank des grossen Rummels, beschäftigen sich mittlerweile viele begabte Leute mit der Thematik und finden so noch diverse Verletzungen von offenen Lizenzen (LGPL, GPL) in dem Kopierschutz.

Hut ab, Sony, das war eine saubere Leistung.
Irgendwie kommt mir das so vor, wie wenn ich mich gegen das Danebenpinkeln wehren will und gleich neben die Muschel sch…
Solange die Gier der Contentmafia weiter so exponentiell steigt, kann man sich ja durchaus auf weitere Gustostückerln dieser Arf freuen.

Wenn man vom Teufel spricht…

Offenbar haben bereits ein paar findige WoW (World of Warcraft) Spieler, das Sony XCP-Rootkit verwendet um die Herumschnüfflei der Spielefirma Blizzard Entertainment, die die lokalen Prozesse auf dem Rechner checkt, damit bei dem Onlinespielchen nicht gecheated werden kann.

Siehe securityfocus.com
World of Warcraft hackers using Sony BMG rootkit:

Blizzard Entertainment, the maker of World of Warcraft, has created a controversial program that detects cheaters by scanning the processes that are running at the time the game is played. Called the Warden, the anti-cheating program cannot detect any files that are hidden with Sony BMG’s content protection, which only requires that the hacker add the prefix “$sys$” to file names.

Ist ja ganz einfach und billig is das Rootkit ausserdem
Wohl noch eine der harmloseren Möglichkeiten, die XCP bietet…
Die grossartige Entdeckung findet sich hier :

For only $14.99 you get a well done RING0 rootkit that is able to hide vs Warden/Hackshield. I have not tested if the rootkit works vs Gameguard as well but its very likely.

1] Buy the CD
2] Run the CD
3] rename myhack.exe to $sys$myhack.exe

Danke SONY…

Eben jenes installiert sich (relativ ungefragt -> EULA) auf Windows-Rechnern und versucht das unbotmässige Kopieren und Rippen der zu schützenden CDs zu verhindern, imdem es ständig nachschaut ob böse Prozesse auf dem Rechener werken. Dadurch erzeugt das Ding schon eine gewisse Verminderung der Performance. Ist ja ned schlimm, der typische DAU braucht sowieso nicht soviel Rechenleistung.

Sony stellt das selbst entsprechend positiv dar:

6. I have heard that the protection software is really malware/spyware. Could this be true?

Of course not. The protection software simply acts to prevent unlimited copying and ripping from discs featuring this protection solution. It is otherwise inactive. The software does not collect any personal information nor is it designed to be intrusive to your computer system. Also, the protection components are never installed without the consumer first accepting the End User License Agreement.

Problematischerweise versucht sich dieser Kopierschutz sich selbst zu verbergen, und zwar auf ähnliche Weise, wie das “normale” Rootkits tun. Hier beginnen die Probleme. Es wäre z.B. relativ lustig einen Virus/Wurm/etc… zu produzieren, der sich genau an das “naming” des Sony-Kopier”schutzes” hält und somit unerkannt sein Unwesen treiben kann.

Die (IMHO spannende) Geschichte der Entdeckung gibts bei
Mark’s Sysinternals Blog: Sony, Rootkits and Digital Rights Management Gone Too Far.

Weiters lässt sich das Ding nicht so einfach entfernen. Löscht man die “verborgenen” Files, die sich auch u.A. als Teil des Treibers für CR-ROM Laufwerke einbinden, etwa weil ein Rootkit-Scanner sie bemängelt, ist das CD-Laufwerk (unter Windows) nicht mehr nutzbar und fix weg vom Desktop/Arbeitsplatz.

Natürlich ist es möglich XPC zu entfernen, aber dann kann man halt die CDs nicht mehr (unter Windows) verwenden.
Ausserdem ist eh alles ned wahr und wir sind eh alle lieb zueinander:

November 2, 2005 – This Service Pack removes the cloaking technology component that has been recently discussed in a number of articles published regarding the XCP Technology used on SONY BMG content protected CDs. This component is not malicious and does not compromise security. However to alleviate any concerns that users may have about the program posing potential security vulnerabilities, this update has been released to enable users to remove this component from their computers.

Meines Erachtens ist das ein weitgehender Eingriff in meine Privatsphäre. Also Digital Rights Management (DRM) entgegentreten heisst derzeit simpel:

Keine CDs kaufen!

oder anders gesagt:

Ein Typ hat mittels einer CrossSite-Scripting (XSS) Attacke einen Wurm geschaffen, der ihm beim (Teenie-)Portal Myspace.com einen Haufen “friends” beschert, und das ohne deren Zutun. Heise nennt das den ersten “Web 2.0 Wurm”, da er das AJAX-Framework verwendet.
Die ganze Web 2.0 Gschicht is ja ned wirklich neu und eh nur ein weiterer Hype.
Nichtsdestotrotz saubere Arbeit das Würmchen, und es zeigt wenigstens gleich von Anfang an eines der Probleme dieses Javascript-Hypes auf. Populär ist der Typ jetzt jedenfall auch und das nicht nur bei mMyspace.com:

But it wasn’t enough. I needed more. So I went deeper. A Chipotle burrito bol and a few clicks later, anyone who viewed my
profile who wasn’t already on my friends list would inadvertently add me as a friend. Without their permission. I had
conquered myspace. Veni, vidi, vici.
[...]
5 hours later, 6:20 pm: I timidly go to my profile to view the friend requests. 2,503 friends. 917,084 friend requests.
I refresh three seconds later. 918,268. I refresh three seconds later. 919,664 (screenshot below). A few minutes later, I refresh. 1,005,831.

Der Rest steht bei Samy
Technische Erklärung & Code zum Exploit

Ein passendes T-Shirt gibts jedenfalls auch schon.

Jeder der einen, zwei, viele … (Linux/Unix-)Rechner am Netz hängen hat , kennt die, seit ca. einem Jahr sehr massiv auftretenden, Dictionary-basierten Versuche einen funktionierenden SSH-Zugriff zustandezubringen. Bei vernünftig gewählten User/Passwort Kombinationen ist das ja im Prinzip problemfrei.

Mich persönlich stört das nicht sehr und ausserdem kann ich so aus den netfiter-Logs schöne Listen mit Benutznamen generieren, sollt ichs je brauchen

Um Ruhe in die Logs zu bringen und sowas

Oct 11 22:01:24 xx sshd[00000]: Illegal user staff from ::ffff:200.245.xx.xx
Oct 11 22:01:24 xx sshd[00000]: Failed password for illegal user staff from ::ffff:200.245.xx.xx port 39070 ssh2

aus den Logfiles rauszuhalten, würd mir ja als erstes einfallen, den sshd auf einem anderen Port laufen zu lassen. Damit wären die automatisierten Verbindungsversuche futsch…

Andere Menschen machen sich da positiverweise viel mehr Gedanken:
Protecting Linux against automated attackers

Die meisten Tips (Unnötige Dienste deaktivieren, starke Passwörter etc…) sind wichtig aber “eh kloa”.
Die Softwarelösungen (BlockHosts, Daemonshield und sshdfilter) hams aber in sich.

Im Prinzip beobachten alle drei den sshd (BlockHosts und Daemonshield via syslog und sshdfilter startet den sshd und liest dessen stdout) und wenn (natürlich konfigurierbar) zu viele “böse” Verbindungsversuche aufschlagen, dann wird mittels iptables (bei den ersten beiden) oder hosts.deny (sshdfilter) der schlimme Schurke ausgesperrt.

Im konkreten Fall bringt das IMHO nicht sonderlich viel. Zum einen hab ich bis jetzt, weder beruflich noch privat, erlebt, dass wirklich viele Verbindungen von einer IP-Adresse kommen. Das ist im Zeitalter von grossen Botnets auch kein Wunder. Zum anderen muss man beim Konfigurieren von Zeitfenstern u.ä. ziemlich aufpassen um sich nicht selbst gehörig in den Fuß zu schiessen.

BTW:
Warum ist unnötiges Zeug in letzter Zeit fast immer in Python verfasst und hat die Sprache das verdient?
Wahrscheinlich schon!