Glorf.it

Glorf IT

Bedenkliches aus dem IT-Alltag

26. Januar 2013 um 15:06

Umgang mit der Meldung von Sicherheitslücken

SecurityAuch in unserer Firma ist niemand erfreut, wenn eine Sicherheitslücke von Außen gemeldet wird. Dann geht bei uns nämlich richtig die Post ab: Alarmstufe rot, Test, Reproduktion, Beseitigung und ein neues Release, dass die Lücke stopft. Also jede Menge Stress. Besser ist es, wenn wir die Lücken selber finden, dennoch ist es am zweitbesten, wenn wir die Probleme mitgeteilt bekommen. Am schlimmsten wäre es, wenn die Lücke ohne vorherigen Hinweis an uns anderen mitgeteilt würde.
Daher hat der Umgang mit den Findern entsprechend zuvorkommend zu sein: Dialog, Prüfung, Dank und Information, wann das Release mit der Beseitigung kommt. Dann kann man die Veröffentlichung mit dem Finder koordinieren. Ob das immer so gelingt, kann ich nicht beurteilen. Der Wille ist jedenfalls da.

Wegen des entstehenden Aufwandes kann ich schon verstehen, wenn jemand nicht gerade erfreut darüber ist, wenn ihm ein Problem gemeldet wird. Leider scheinen aber auch noch ganz andere Reaktionen üblich zu sein:

  1. Leugnen/Verdrängen: Das ist kein Problem. Wir haben alles im Griff. So einen Angriff sind utopische Voraussetzungen nötig.
  2. Kleinreden: Es gab noch nie eine Angriff, der die Lücke ausnutzt. Das ist nur eine theoretische Lücke. Alles halb so wild.
  3. Kriminalisieren: Wer so eine Lücke findet, muss ein Krimineller sein. Er verhält sich nicht konform. "Wehe Dir, oh, Finder der Lücke."

Der Anlass meines Schreibens ist der Umgang mit dem Studenten Hamed Al-Khabaz: er wurde der Hochschule verwiesen. Die Hochschule widerspricht zwar der Version des Studenten, aber unstrittig ist wohl, dass er eine Sicherheitslücke fand, sie meldete und ein paar Tage nach der Rückmeldung die Lücke werde behoben, mal nachschaute, ob das auch wirklich durchgeführt wurde. Was für eine Lücke das ist, ist nicht von Belang. Es ist nur wichtig, dass es um die personenbezogenen Daten aller Studenten ging: also die schlimmste anzunehmende Sicherheitslücke einer Universität.

Leider hat die Hochschule hier den nötigen Mentatiltätswandel noch nicht vollzogen: Den Melder eines Sicherheitsproblems zu kriminalisieren, weil er weiterhin nach Lücken suchte, wirft ein sehr schlechtes Licht auf die Hochschule. Anstatt ihm dankbar zu sein und ihn auch offiziell damit zu beauftragen, dass er die eigenen Systeme testet und Probleme meldet, wird verletzt reagiert. Da er so großes Interesse an dem Thema hat, hätte er es möglicherweise sogar im Rahmen eines Seminars (also kostenlos) gemacht. Eine Win-Win-Situation: der Student hat ein interessantes Seminar mit einer vermutlich guten Note und die Hochschule einen kostenlosen Penetrationstest für das wichtigste System.

Ich finde es ein Zeichen von fehlendem Problembewusstsein, wenn offizielle Stellen oder Firmen mit Sicherheitsproblemen und der Meldung von Lücken nicht professionell umgehen. Ob es nun daran liegt, dass manche Menschen keine Fehler zugeben können, sich einfach nur belästigt fühlen, sich rächen wollen oder andere Gründe haben, wird man wohl nie erfahren. Zum Glück werden solche deplatzierten Reaktionen heute manchmal bekannt.

Ich kenne die Hintergründe nicht, aber von ganz weit weg gesehen, setzt sich die Universität in ein sehr unprofessionelles Licht. Dem Studenten hilft das wohl nicht: seine Laufbahn ist ruiniert, wenn es ihm nicht gelingt, das Kollege zum Einlenken zu bewegen. Er wurde kriminalisiert, sein Stipendium ist weg und sein Studienplatz ebenso. Es klingt so als würde ein Exempel statuiert. Armer Kerl.

Details zum aktuellen Stand bei Heise.de: Geschasster Campus-Hacker: College widerspricht

26. Januar 2013 um 12:27

ReFS – Resilient File System

Im Zusammenhang mit Windows Server 2012, der im Gegensatz zu Windows 8 eher wegen seiner Features diskutiert wird und nicht wegen irgendwelcher Kacheln, ist das neue Dateisystem sicher eines der High-Lights. Es gab seitens Microsoft schon etliche erfolgreiche Versuche Dateisysteme zu verbessern:

  • FAT (File Allocation Table) wurde schon zu DOS-Zeiten verwendet (FAT12, ab 1980) und 1983 von Microsoft zu FAT16 weiterentwickelt. Da letzteres immer noch eingesetzt wird, z.B. auf kleinen USB-Sticks, ist das wohl das bisher erfolgreichste Dateisystem.
    Es unterstützt maximal 4 GB große Partitionen.
  • FAT32 wurde von Microsoft 1997 eingeführt, um größere Partitionen zu unterstützen. Es hat sich aber nicht wirklich durchsetzen können. Es wurde vorwiegend mit Windows Millenium genutzt.
  • NTFS (New Technology File System) wurde 1993 mit Windows NT 3 veröffentlicht. Das Dateisystem ist mittlerweile in der Windows-Welt standard. Es dauerte aber bis zum Jahr 2001 bis mit Windwows XP auch in der Standard-Installation für die Boot-Partition NTFS eingerichtet wurde. Zuvor verwendete Microsoft dafür sicherheitshalber FAT16 oder später FAT32. Das lag daran, dass Windows95/98/Me seltsamerweise kein NTFS unterstützen. Microsoft wollte das ausschließlich im Business-Bereich platzieren.
    Auch NTFS erlaubt größere Partitionen als 4GB und ist deutlich robuster. Eine Datei kann hier bis zu 17 TB groß werden (1 Tera-Byte sind 2^12 Bytes).
  • ReFS (Resilient File System). Resiliency bedeutet Elastizität und soll ausdrücken, wie robust und vielseitig das neue Dateisystem sein soll. Hier geht es beispielsweise um richtig große Datenmengen: Eine Datei kann 2^64 Bytes groß werden (gibt es dazu schon eine Abkürzung). BigData kann kommen…

Wer sich über ReFS informieren möchte, der findet hier sehr qualifizierte Artikel:

ReFS und SQL Server

Unglücklicherweise unterstützen die Microsoft SQL Server das neue Dateisystem (noch) nicht. Details hier und bei sqlmag.com. Microsoft hält sich verdächtig bedeckt. Offenbar haben sie das komplett verbockt bzw. verschlafen. Dabei wäre eine Zusammenarbeit der Windows-Devision mit der SQL-Server-Division an der Stelle durchaus nötig gewesen…

Man munkelt, dass Microsoft hektisch daran arbeitet mit SQL Server 2012 SP1 dann auch ReFS zu unterstützen. Wenn man sich die gravierenden Unterschiede zwischen NTFS und ReFS anschaut, dann weiß man, dass Microsoft auf viele Strategien zurückfallen muss, die mit FAT genutzt werden mussten. Daher kam mir zu Ohren, dass Microsoft derzeit keine Unterstützung mit SQL Server 2008 (R2) oder 2005 plant. In meinen Augen wäre es wohl auch eine Alternative ReFS einfach noch um ein paar Features aufzurüsten. Mal abwarten…

16. Januar 2013 um 18:01

Fies oder dumm?

Heute bekam ich gleich auf mehreren meiner Mail-Adressen diese plumpe Verführung zum Phishing: Die Sprache deutet auf eine automatische Übersetzung hin. Der Link (im untigen Beispiel zwar unterstrichen, aber *kein* Link) https://eu.battle.net/support/en/games/diablo3 leitete in Wirklichkeit auf: http://www.loruws-foruas.tk/ um. Dort erwartet einen sicher eine Seite, die Passwörter erbittet und als Dank gleich die aktuellste Schadsoftware auf den Rechner spielt. Den Link bitte nicht ausprobieren.

Betreff: verstößt gegen unsere Richtlinien für Battle.net und Diablo III
Datum: Wed, 16 Jan 2013 20:20:00 +0800
Von: donotreply@blizzard.com <Darkfixius@yahoo.com>
An: <…>

Sehr geehrter Kunde,

Weil du in den Handel mit Gold und Ausrüstung beteiligt sind, rechtmäßig ein Spiel mit einem unveränderten Spiel-Client. Doing anderweitig gegen unsere Richtlinien für Battle.net und Diablo III, und es geht gegen den Geist des Fairplay, dass alle unsere Spiele auf beruhen. Wir empfehlen dringend, dass Sie keine Hacks, Cheats, Bots oder Exploits zu vermeiden. Sperren und Verbote von Spielern, die verwendet haben oder beginnen mit Cheats und Hacks.

Sie können bestätigen, dass Sie der ursprüngliche Besitzer des Kontos, auf dieser sicheren Website mit, sind:
https://eu.battle.net/support/en/games/diablo3 [Anmerkung von TG: War ein Link. in Wirklichkeit auf: ]

Anmeldung zu Ihrem Benutzerkonto, gemäß nach Vorlage auf Ihr Konto zu überprüfen.

* Account Name und Passwort
* Vor-und Zuname
* Geheime Frage und Antwort

Show * Bitte geben Sie die richtigen Informationen

Wenn Sie diese E-Mail ignorieren Ihr Konto kann und wird dauerhaft geschlossen werden.
Konto Sicherheit ist unglaublich wichtig für uns, und wir hoffen, dass es für Sie wichtig ist. Wenn Sie irgendwelche zusätzlichen Sicherheitsempfehlungen zu dieser Liste hinzufügen möchten, wenden Sie sich bitte frei, um sie in den Kommentaren!

Konto Administration Team
http://www.blizzard.com/support/
Diablo III, Blizzard Entertainment 2012

Wer auf den Link klickt, der hat doch sicher die Mail nicht gelesen, oder? Aber das ich bereits früher ähnliche Mail bekam, deutet darauf hin, dass die Masche funktioniert.

Besser gemacht, aber auch nicht perfekt, fand in den Versuch von gestern Nacht, den ich ebenfalls mehrfach bekam. Hier ist die Sprache etwas besser und nur der mittlere Link http://eu.blizzard.com/support/article/securitywebform auf eine verseuchte Seite: http://www.streas-manage.tk/

Betreff: World of Warcraft – Account Untersuchung
Datum: Wed, 16 Jan 2013 02:31:08 +0800
Von: WoWAccountReviewEU@blizzard.com <super_cacat_monkey@yahoo.com>
An: <…>

Begruessung!

Wir haben bemerkt, dass Sie versuchen Ihre persoenlichen World of Warcraft-Account zu verkaufen.
Nutzungsbedingung

http://www.worldofwarcraft.com/legal/termsofuse.html [Anmerkung: Link führte tatsächlich auf das angegeben Ziel]
Die Blizzard Entertainment Mitarbeiter werden weiter untersuchen.
Wenn Sie nicht moechten, dass Ihren Account blockiert werden. Bitte ueberpruefen Sie sofort Ihren Accountsbesitzanspruch. Sie muessen die folgenden Schritte durchfuehren, um die Sicherheit Ihres Accounts und Computer zu gewaehrleisten.

Schritt 1. Account Untersuchung
Wir bieten Ihnen jetzt eine sichere Webseite, dadurch Sie ueberpruefen zu koennen, ob Sie die entsprechenden Massnahmen ergriffen, um die Sicherheit Ihres Accounts, Computers und E-Mail-Adresses zu gewaehrleisten. Bitte melden Sie sich auf der Web-Seite und bestaetigen Sie nach den Anweisungen:
http://eu.blizzard.com/support/article/securitywebform [Anm.: Link führte in Wirlichkeit nach ]

Schritt 2. Stellen Sie sicher,dass die gegebene Informationen eingenommen ist.
Sobald verarbeiten wir Ihre gegebenen Informationen nach dem Empfang. Und kontaktieren Wir mit Ihnen um weitere Anweisung zu geben. Wenn Sie nach dem Absenden dieses Formulars innerhalb von 48 Stunden keine Antwort erhalten, bitte senden Sie nochmal das Formular an die oben angegebene Web-Seite.

Bitte beachten Sie! Wenn Ohne Akkreditierung dies Account zu besuchen, werden wir weitere Massnahmen zu ergreifen.

Begruessen Sie!

Kundenservice
Blizzard Entertainment
http://www.blizzard.com/support [Anmerkung: Link führte tatsächlich auf das angegeben Ziel]

Vier solche Mail an einem Tag sind schon auffällig und dürften mit den aktuell bekannt gewordenen Problemen im Internet-Explorer zu tun haben.

12. Januar 2013 um 12:02

Wie kritisch ist es, wenn eine Anwendung mit dem SA arbeitet?

SecurityIm Zusammenhang mit meinem Posting "JTL-Wawi und das veröffentlichte SA-Passwort" stellte Ralph die Frage, wie kritisch es ist, wenn ich eine Anwendung nutze, die immer mit dem Sysadmin arbeitet. In dem Posting habe ich schon beschrieben, warum es für einen Angreifer ein so großes Geschenk ist an das SA-Passwort zu kommen. Kurz gesagt, er kann sich damit bislang meistens zum Administrator am Server machen.

Im konkreten Fall kann zunächst jeder Depp einen Angriff durchführen solange das im Internet veröffentlichte Default-Passwort nicht geändert wird. Gehen wir also mal davon aus, ein Admin ändert das SA-Passwort. Wie gefährdet bin ich dann als Nutzer so einer Software?

Wenn man einschätzen will, wie kritisch eine Lücke ist, dann muss man zwei Fragen beantworten:

  • Wie schlimm ist es, wenn jemand die Lücke ausnutzt?
  • Wie schwierig ist es, die Lücke auszunutzen?

Wie lauten die Antworten in diesem konkreten Fall, wenn die Software als Prozess am Arbeitsplatz ausgeführt wird?

Wie schlimm ist es, wenn jemand die Lücke ausnutzt?

Worst Case! Weil der SQL-Server-Dienst im Systemkontext läuft, ist der Server kompromittiert oder der Einzelarbeitsplatz kann komplett aus der Ferne übernommen werden, ja nachdem wo der SQL Server installiert wurde. Nichts ist mehr sicher, dem Angreifer ist nichts unmöglich.

Wie schwierig ist es, die Lücke auszunutzen?

Es sind mehrere Lücken, die beide damit zu tun haben, dass die Anwendung am Arbeitsplatz ausgeführt wird und damit im Kontext des Benutzers:

  • Das SA-Passwort wird beim Einrichten an eine Stelle geschrieben, die jeder Benutzer lesen kann. Die verwendete Verschlüsselungsmethoden sind leicht protokollierbar, der Schlüssel ist ebenso zugänglich. Das ist für einen ernsthaften Angreifer die einfachste Methode: Die Software bei sich installieren, in aller Ruhe ausspähen und einen Exploit schreiben, der anderen zur Verfügung gestellt werden kann.
  • Während des Zugriffs kann jeder Prozess, der im gleichen Benutzerkontext läuft wie das JTL-WAWI, den JTL-WAWI-Prozess ausspähen: er kann den Hauptspeicher durchwühlen, die von der Anwendung verwendeten Schnittstellen sniffen oder sich sogar als Debugger an den Prozess hängen. Wenigstens seit Windows-XP hat jeder Windows-Benutzer das Recht die "eigenen" Prozesse derart zu untersuchen. Viele Entwickler glauben offenbar dazu wären Admin-Rechte nötig. Daher habe ich beschlossen für diese Zielgruppe ein Buch zur Sicherheit von Anwendungen mit SQL-Server zu schreiben. Mal schauen, ob es auf Interesse stößt.

Als Angreifer haben wir also zwei Angriffspunkte, um an das begehrte SA-Kennwort zu bekommen. Wie man das ganz konkret macht, beschreibe ich hier absichtlich nicht. Angehende Skript-Kids möchte ich nicht zu unüberlegten (weil kriminellen) Handlungen verleiten. Aber seien Sie sicher, dass die bösen Jungs wissen wie das funktioniert. Jeder Fachinformatiker im ersten Lehrjahr sollte dazu in der Lage sein. Ebenso reichen die im Informatikunterricht vermittelten Kenntnisse, um sich da einzulesen.

Es ist nur die Frage, ob Angreifer sich die Mühe machen. Das hängt davon ab, was zu holen ist und wie verbreitet die Software ist und wo der Angreifer sitzt?

Wo sitzt der Angreifer?

Falls mein Geschäft eine Oneman-Show ist und die Software nur auf einem Einzelarbeitsplatz läuft, dann dürfte der Angriff am ehesten über das Internet erfolgen, z.B. durch Ausnutzen einer bekannten, noch ungelösten Lücke (z.B. Internet-Explorer oder Flash) oder einfach per Mailanhang z.B. (präpariertes PDF). Der Schädlich könnte schauen, ob er in der Registry das SA-Kennwort findet, anhand des ebenfalls dort stehenden Schlüssels entschlüsselt und ggf. via SQL Server sein schändliches Werk tun.

Falls der SQL-Server im Netzwerk auf einem Server installiert ist, dann dürften mehrere Mitarbeiter vorhanden sein. Für jeden Arbeitsplatz gilt die gleiche Angriffsmöglichkeit wie beim Einzelplatz. Zugleich kommt noch hinzu, dass ein Mitarbeiter anhand einer der vielen Anleitungen einen Sniffer startet (sehr einfach, auch für absolute Laien), das SA-Kennwort erspäht (dito) und dann die Grenzen der Möglichkeiten erprobt (mit Excel zum SQL Server verbinden ist nicht schwer, über SQL Server andere Dateien auslesen erfordert schon mehr Skills). Je nach Motivation des Mitarbeiters kann er sich dann austoben: Die Möglichkeiten reichen vom Stillen der Neugier (steht dort auch, was die Kollegen verdienen) und Kundendaten mitnehmen (um den geplante Start in sie Selbstständigkeit zu erleichtern) bis hin zur Rache (Festplatte formatieren, weil Gehaltserhöhung nicht bekommen, MS fühlt sich ungerecht behandelt, ihm wurde gekündigt, …)

Weil es geht…

In den letzten Jahren kam ein Trend auf, der alle obigen Ausführungen relativiert. Mit den sogenannten Skript-Kids kamen Angriffe hinzu, wo die Angreifer keine wirtschaftlichen Betrachtungen anstellen: Lohnt sich der Aufwand, was ist zu holen, … ? Gerade weil es so einfach ist, werden von meist Jugendlichen Angriffe ausgeführt, einfach nur weil es geht und sie Grenzen austesten wollen. Die Motivation ist hier der Spaß am Knobeln und vielleicht der Prestige-Gewinn im Freundeskreis. Weil es ihnen nicht darum geht damit Geld zu machen, ist es ihnen egal wie lange sie dafür brauchen, sie haben ja nach der Schule meist viel Zeit. Viele der besonders populären Angriffe der letzten Jahre auf Sony etc. waren so motiviert. Die öffentliche Bestrafung einiger der Skript-Kids führte aber in meinen Augen nicht dazu, dass weniger Angriffe durchgeführt werden. Die Kiddies prahlen damit halt nicht mehr so öffentlich.

Und die benötigte Kenntnisse? SQL lernen bayerische Gymnasiasten in der 9ten Klasse…

Update 3.2.2013: Zuschriften entnahm ich, dass einige nicht glauben, dass auch mit normalen Benutzerrechte die beschriebenen Spionageaktionen möglich sind. Daher können interessierte Entwickler anhand dieser Anleitung die benötigten Rechte selber überprüfen.

|