Designkantine zu ‘Mobile First’ – Besser Abspecken mit Design

Veröffentlicht am von

Vorbei sind die Zeiten,  in welchen man für das Surfen noch auf einen Rechner mit Telefonleitung oder WLAN Verbindung angewiesen war. Gemäss einer Studie von Chitika (iOS passes Mac OS in Share of Web Traffic Propelled by Sales for Mobile and Tablet Devices) überstieg der Datenverkehr in den USA über iOS Geräte (also iPhone, iPad, etc.) denjenigen von Mac OSX Systemen. Abgesehen davon, dass sich die Erhebung  auf Zahlen stützt, die über das Chitika Ad Network erfasst wurden, lässt sich ein klarer Trend erkennen. Das Mobile Internet wird immer populärer und dementsprechend werden sich auch die darin angebotenen Inhalte verändern.

Zwei weitere Zahlen unterstreichen diesen Trend: Bis Ende 2012 gibt es mehr Mobiltelefone als Menschen (More Mobiles Than People Worldwide by the End of 2012). Samsung rechnet für 2012 ebenfalls damit, dass 29% aller Mobiltelefone Smartphones sein werden, das sind über 500 Millionen! (Samsungs says smartphones will make up 29 percent of the market in 2012)

Anbieter von Internetseiten stehen also vor zwei grossen Herausforderungen:

  1. Sind meine Inhalte fit für mobiles Surfverhalten?
  2. Ist meine Website fit für mobile Endgeräte?

Wir gewähren Ihnen deshalb in unserer Designkantine einen Einblick in die Stossrichtung “Mobile First” und wenden das Wissen gleich mit Ihnen in einem kleinen Workshop an.

Am 15. März 2012 von 12.00 – 14.00 Uhr servieren Ihnen Claus Medvesek , Philipp Flunkert und Björn Amherd im Namics Office in Zürich ein Menü mit vier unschlagbaren kulinarischen Höhepunkten.

Melden sie sich gleich an! (die Plätze sind beschränkt)

Agile Migration

Veröffentlicht am von

Auch für Migrationsprojekte ist klassische Projektplanung mit Meilensteinen, Aktivitäten und deren Abhängigkeiten unerlässlich. Man sollte sich jedoch bewusst machen, dass hier ein neues System entwickelt wird, während das Alte noch läuft und Veränderungen unterworfen ist. Da i.d.R. das neue System mindestens Funktionen und Inhalte des alten Systems bieten soll, muss das Projektteam in der Lage sein, auf Änderungen zu reagieren. Erschwerend hinzu kommt, dass zwar durch Einsatz von erfahrenen Experten viele erforderliche Maßnahmen im Vorfeld identifiziert und eingeplant werden können, jedoch ergeben sich im Rahmen der zahlreichen Probeläufe der Migration weitere Aufgabenstellungen. Daher sollte neben der Planung auch ein agiler Projektbetrieb gebildet werden.

Vom Plan zum Projektbetrieb.

Bewährt hat sich hierbei eine zyklische Ausarbeitung bestehend aus den Schritten Analyse, Code-Änderung, Content-Änderung, Probelauf und Test. Um diesen Projektbetrieb überwachen und steuern zu können, ist der Einsatz eines Ticketsystems sehr wichtig. Denn nur somit kann gewährleistet werden, dass alle Beteiligten unmittelbar neue Aufgaben erfassen können und alle wichtigen Aufgaben auch rechtzeitig erledigt werden. Dies beschleunigt auch die Durchführung der Migrationsprobeläufe, denn der jeweilige Lauf kann oftmals mit Hilfe eines Workarounds fortgesetzt werden, während die Analyse und Behebung des Tickets parallel erfolgen kann, z.B. auch gemeinsam mit dem Produkthersteller.

Parallelisierung der Migrationsprobeläufe.

Ebenfalls wichtig ist, dass es eine Ablage gibt, wo die Migrationsschritte kontinuierlich erfasst und gepflegt werden können. Sie dient als Anleitung, die stets auf dem aktuellen Stand ist und für Probeläufe genutzt wird. Werden Fehler oder Lücken festgestellt, müssen sie unmittelbar vom jeweiligen Mitarbeiter erfasst werden können. In der Vergangenheit haben sich Ticket-Systeme und Wikis hierfür als sehr geeignet erwiesen. Für den GoLive kann dann hieraus eine Checkliste erstellt werden.

Fehler beheben und Migrationsanleitung anpassen.

Die Anleitung und Hilfsskripte sind die Ergebnisse, die für den GoLive erarbeitet werden müssen. Gemeinsam mit dem neuen Standardprodukt, auf das migriert wird, bilden sie die Grundlage für die erfolgreiche Inbetriebnahme.

 

Weitere Artikel dieser Blog-Serie

A Study in … Viagra

Veröffentlicht am von

Sherlock Holmes zum Zweiten. Der Blogpost von Jürg über gehackte TYPO3-Seiten hat viel Staub aufgewirbelt worauf mehrere SOS-Rufe von betroffenen Seitenbetreibern bei uns eingetroffen sind. Das Problem war, dass einige ältere TYPO3 Betreiber plötzlich unwissentlich potenz-steigernde Pharmazeutika verkauften. Seit wir auf dieses Problem aufmerksam geworden sind, stossen wir regelmässig auf neue Opfer des “Pharmahacks”. TYPO3 ist dabei übrigens bei weitem nicht das einzige geplagte System. Perfiderweise ist der Hack auf den ersten Blick nicht sichtbar – er wird nur wirksam, wenn der Surfer via Google auf die Seite stösst. Dann wird server-seitig neuer Text in die Webseite gerendert und beim Klick auf den Link von Google aus, gelangt der Kunde nicht auf die eigentliche Seite, sondern wird auf eine (meist russische) Seite weitergeleitet. Die verkauft Viagra – oder etwas anderes blaues.
Neulich erhielten ich erneut den Auftrag, den Verkauf blauer Pillen auf der Seite eines Dritten zu unterbinden. Diesmal wurde das Problem mit “Medikamentenhack” beschrieben.

Hier folgt ein Bericht meiner Spurensuche in der Hoffnung, dass Anderen mit den selben “Krankheitssymptomen” geholfen werden kann.
Als erstes habe ich mich auf dem System, im TYPO3 Backend und auf dem Server etwas umgesehen. Dabei handelte es sich nicht um eine “verwahrloste” Webseite sondern um eine recht gut ausgebaute Plattform mit einem relativ aktuellen TYPO3 Core und einem sauberen Aufbau und umfangreicher Funktionalität. Ein eher grosser Auftritt.

Gefährliche Extensions

Auf Anhieb sind mir jedoch einige potenziell (sehr) gefährliche Extensions aufgefallen, die auf einem Live-System nichts verloren haben: “t3quixplorer” – erlaubt die Navigation auf dem Filesystem mehr oder weniger uneingeschränkt und ermöglicht das Bearbeiten von PHP-Scripts direkt über das Webinterface – der reinste Security-Alptraum. Es ist nicht auszuschliessen, dass diese Extension von einem der Angreifer installiert wurde. “devlog” ist eine Extension welche zu Entwicklungszeiten nützlich sein kann – jedoch nicht in einem Live-System. Ein anderer Kandidat, welcher jedoch nicht installiert war, ist die “phpmyadmin” Extension, welche oft aus Bequemlichkeit installiert wird. Auch diese Extension stellt ein beträchtliches Sicherheitsrisiko dar. Im übrigen beinhaltete das System einige “handgemachte” Extensions – schnell zu erkennen an fehlenden Icons und der aussagekräftigen Versionsnummer 0.0.0 – Stable? Ja genau!

Backend-User

Ich habe ausserdem alle Backend-User überprüft und mit dem Kunden zusammen sichergestellt, dass keine unbekannten Nutzer registriert waren. Sollte dies der Fall sein, würde ich empfehlen, alle User neu anzulegen und neue, sichere Passwörter zu vergeben.

Spurensuche im Dateisystem

Danach habe ich mich etwas vertieft auf die Spurensuche gemacht. Aus Erfahrung weiss ich mittlerweile, wonach ich suchen muss. Eine Suche im Filesystem nach “base64_decode(” führt meist zu verdächtigen Code-Zeilen oder Dateien:

find . -name "*.php" -print | xargs grep "eval(base64_decode("

Meist sind infizierte Dateien im Ordner typo3conf/ zu finden. Darin befinden sich die von TYPO3 auszuführenden Extensions. Der Code darin kann potenziell schädlich sein.
Auf diese Weise bin ich auf zwei verdächtige Dateien gestossen. Eine Datei war in einer nicht öffentlichen, für Kundenbedürfnisse entwickelten Extension enthalten. Die andere im ./uploads/ Ordner der bekannten Newsletter-Extension tx_directmail.

./uploads/tx_directmail/trololo.php:<?php eval(base64_decode("ZXZhbChiYXNlNjRfZGVjb2RlKCJaWFpoYkNoaV
lYTmxOalJmWkdWamIyUmxLQ0phV0Zwb1lrTm9hVmxZVG14T2FsSm1Xa2RX
YW1JeVVteExRMHBoVjBad2IxbHJUbTloVm14WlZHMTRUMkZzU20x…

In beiden Fällen war es dem Angreifer möglich, über ein ungenügend geschütztes Formular PHP-Dateien auf das System zu laden. Geschieht dies, und sind diese Dateien auch ausführbar, hat man verloren.
Bei genauerem Hinsehen habe ich in der handgestrickten Extension gleich noch mehr zerstörerische Dateien gefunden welche die unscheinbaren Namen “class.php” und “footer.php” trugen. Ich musste erst beim Dienstleister des Kunden nachfragen, um sicher zu stellen, dass es sich wirklich um bösartige Dateien handelte. In diesen Fällen hatten die Angreifer ganze Arbeit geleistet – auch das Erstelldatum war ein weit zurückliegendes. Oft kann man im System auch einfach nach Files suchen, die im Zeitraum des Hacks verändert wurden. Ich konnte diesen durch verdächtige Files auf etwa 76 Tage zurückliegend vermuten und bin mit dem Befehl

find . -iname "*.cache" -mtime -77 -mtime +75 -type f

auf weitere verdächtige Dateien gestossen. Da im Ordner typo3conf während dem Betrieb eigentlich keine Dateien geändert werden sollten, sind dies zumindest dort, nur eine Hand voll. Mein Tipp: in typo3conf/ext/ darf auf einem Live-System gar nichts geändert werden können. Dem Server (Apache) sollen also alle Schreibrechte auf typo3conf/ext/ entzogen werden. Auch localconf.php darf nie verändert werden – damit wird es für einen Angreifer sehr schwer, nachträglich Extensions zu installieren, ohne dass er Serverzugriff hat.

Bereits erwähnte class.php war mehrfach base64 encoded und nachdem ich diese mehrfach decodiert hatte wurde ihr Zweck offensichtlich. Sie leitet die Benutzer welche von viagra-verseuchten Google-Resultaten kommen auf die russischen Verkaufsseiten weiter:

Ja ist denn heut’ schon Weihnachten?

Bei der Analyse von ./uploads/tx_directmail/trololo.php wurde ich leicht überrascht. Ebenfalls nach mehrmaligem encoden kam folgendes zum Vorschein:


Ein ausgewachsenes Backdoor! Inklusive Passwortschutz. Klar russischen Ursprungs. Mit diesem Tool kann man auf einem Server so ziemlich alles machen. Dateien erstellen, löschen, bearbeiten, Rechte setzen. Damit kann man die localconf.php auslesen – dort steht (meist) der MySQL User und das Passwort im Klartext. Somit kann der Angreifer auch auf die Datenbank zugreifen. Doppelt dumm, wenn der gleiche User auf mehrere Datenbanken Zugriff hat. Wenn man localconf.php nicht schreibgeschützt hat, kann er ausserdem ein neues Install-Tool Passwort erstellen. Damit kann er sich dann einen Backend-Administrator erstellen – etwas einfacher als direkt über die DB. Netterweise nennt TYPO3 bei einer missglückten Anmeldung am Install-Tool auch gleich den dazu benötigten MD5 Hash den man dann nur noch im localconf.php eintragen braucht.
Das Backdoor in Action:

Und weiter geht’s…

Nachdem ich die Suche bereits abbrechen wollte – es war mittlerweile schon spät – bin ich im fileadmin/ in den Templates der Webseite auf eine weitere mysteriöse Datei gestossen – eine PHP Datei unter den CSS Files; en.php
Diese enthielt neben den verdächtigen base64 Codes auch noch folgenden aufschlussreichen Text:

Codz by angel(4ngel)
Make in China
Web: http://www.4ngel.net

Die Chinesen waren also auch am Werk! Nach erneut mehrmaligem Encodieren und Entfernen eines Passwortschutzes wurde offensichtlich, dass die Chinesen den Russen mittlerweile – zumindest im Design – voraus sind. Ebenfalls eine mächtige Hintertüre – einmal in schön.

Fazit, Suche, Massnahmen

Abschliessend konnten wir den Grossteil des Hacks wohl innerhalb einiger Stunden finden und entfernen. Nach dem der übliche Selbstheilungsprozess von Google eingesetzt hatte sind nun die Suchresultate wieder frei von Viagra. Für die Suche nach infizierten Files benutzen wir die Dateisystemsuche nach den Begriffen eval() und base64_decode(), Datumsangaben, verdächtige PHP-Dateien an unüblichen Orten – PHP-Files im uploads Ordner oder in andern Ordnern mit normalerweise statischen Inhalten. Auch eine Hilfe für das schnelle Finden von Schadcode kann sein, wenn die TYPO3 Temp-Files im typo3conf/ Ordner nach base64_decode durchsucht werden. Diese Dateien werden von Typo3 geladen und enthalten einen Zusammenzug vieler ausgeführter Dateien. Oft sieht man dort schnell, ob, und wo ungefähr, ein System vom “Pharmahack” befallen ist. Handgemachte Extensions die nie den Weg ins TYPO3 Repository gefunden haben sind ein erhöhtes Sicherheitsrisiko. Alle Formulare mit Upload-Funktionalität sind ein möglicher Angriffspunkt. Auch in die Datenbank sollte man einen Blick werfen. Es kann sein, dass in den Tabellen von RealURL unerwünschte Weiterleitung enthalten sind. Auch in tt_content oder in der pages Tabelle kann nach Viagra gesucht werden. Ausserdem sollte man alle Cache-Tabellen leeren.

Die befallenen Dateien und Extensions werden gesäubert oder entfernt. Nicht (mehr) benötigte Extensions sollten vom System gelöscht werden – nicht nur deaktiviert! Unnötige Backend- und Frontend-User sollten ebenfalls gelöscht und die Passwörter sicherheitshalber angepasst werden.
Alle Schreibrechte für den Server sollten auf typo3conf/ext und auf der localconf.php entfernt werden. Dies gilt selbstverständlich auch für den ganzen TYPO3-Core. Sicherheitshinweise von TYPO3 sollten ernst genommen werden:

Das Install-Tool kann auf dem Live-System entfernt werden und der Zugriff auf das Backend nur für einen bestimmten IP-Range, vielleicht über eine spezielle Sub-Domain und zusätzlich mit einem .htaccess Schutz, versehen werden. Auch HTTPS für das Backend schadet kaum.
Natürlich sollte darauf geachtet werden, dass TYPO3 und verwendete Extensions auf einem aktuellen Stand sind. TYPO3 Bug-Fix Releases sollten wenn möglich immer installiert werden da diese Security-Fixes enthalten und normalerweise problemlos zu installieren sind.

Ready for TakeOff: Das Namics Performance Dashboard

Veröffentlicht am von

Das Namics Performance Dashboard ist ein Management-Dashboard, welches eine langfristig stabile ROI-Betrachtung der wichtigsten, geschäftsrelevanten Online-Kennzahlen (KPI’s) einfach und schnell zulässt.

Im obigen Beispiel ist die KPI-Struktur für eine Bank mit den entsprechenden Segmenten abgebildet. Natürlich ist dann pro Segment ein DrillDown möglich, z.B. zu

  • Anzahl bestellte Karten (Maestro, Kreditkarten, etc.)
  • Anzahl Kontoeröffnungs-Beantragungen (Privatkonto, Sparkonto, etc.)
  • Anzahl Beratungsanfragen (Allgemein, Hypotheken, etc.)

Die Segmentierung resp. Kategorisierung kann absolut frei definiert werden und damit eignet sich das Dashboard natürlich auch für alle anderen Branchen, welche Leads und/oder Conversions über die Online Kanäle generieren.

Warum dieses Dashboard?

Im Kern geht es darum, auf die geschäftsrelevanten Zahlen zu fokussieren, welche über den Online-Kanal reinkommen. Diese werden gemessen und zuverlässig in einem einfachen, management-tauglichen Frontend dargestellt - ohne die ganzen SchnickSchnack-Zahlen wie Browser-Verteilung, Geräteverteilung, etc.. Denn unter dem Strich gehts auch im Online-Bereich immer um dasselbe: Umsatz und Ertrag. Und da zählen halt nur konkrete Leads & direkte Conversions.

Wenn sie also für das Management ein Performance Dashboard mit den wichtigsten Online KPI’s brauchen und das in Ihrem AnalyticsTool nicht so einfach management-tauglich umsetzbar ist – können wir ihnen das Namics Performance Dashboard gerne näher vorstellen. Als Ansprechpartner stehen ihnen Emanuel Bächtiger, Martina Klose oder ich jederzeit zur Verfügung.

PS: Für die speziell Interessierten gibt es ein internes Video zum Performance Dashboard – nicht perfekt gemacht, aber es gibt einen detaillierteren Einblick.

 

White Hat Bug Bounty bei Facebook

Veröffentlicht am von

“Die Community” bei der Fehlersuche resp. der Qualitätssicherung einzubeziehen ist nicht wirklich neu und bis jetzt die “geekigste” Geschichte dazu lieferte wahrscheinlich Donald Knuth, der sowohl für seine Bücher wie auchfür die Programme TeX und METAFONT Prämien in der Höhe von mathematischen Konstanten bezahlte. Und auch andere Firmen wie Mozilla oder auch Google tun es — häufig auch mit geekigen Prämienbeträgen beispielsweise in leet speak.

Facebook macht es nun noch ein bisschen netter: Mit einer exklusiven Club und der folgenden “White Hat Bug Bounty” Visa Karte:

Für jeden gefundenen Fehler gibt es eine Gutschrift von mindestens USD 500 auf die Karte, auf Wunsch eine Nennung auf https://www.facebook.com/whitehat/ und die Aussicht auf eine Einladung an eine exklusive Party. Die Jungs verstehen Community.

Eine ziemlich coole Idee und extrem kosteneffizient wenn man dran denkt, was ein publiziertes Sicherheitsproblem -Fehler kosten kann. Und hier noch die anderen Spielregeln der Aktion.