Epic Fail

Unter der Überschrift: Die Illusion von Safer-Shopping nimmt Heise gerade das Online-Gütesiegel eines bekannten Anbieters auseinander:

»Nach der Datenpanne im vom TÜV Süd zertifizierten Online-Shop-System von Libri.de fanden sich nun Sicherheitslücken auf weiteren Sites, die das Safer-Shopping-Siegel tragen – und sogar auf dessen eigener Homepage. Neben Safer-Shopping.de waren Audible.de, ReifenDirekt.de und weg.de betroffen.«

Über Zertifizierung, Gütesiegel und den TÜV gab es hier ja schon einiges zu lesen. Als Sekundärliteratur empfehle ich noch: 10 Things Your Auditor Isn’t Telling You.

The Cloud Computing Consultant

(video link)

White Hat Hacker Man

(video link, lyrics)

100 Dollar

Hundert Dollar lässt sich T-Mobile USA den Datenverlust durch Serverausfall pro Kunde kosten. Scheinbar zumindest, denn statt Bargeld gibt es einen Gutschein, einzulösen bei T-Mobile USA. Weiß jemand, wie man die realen Kosten so einer Gutscheinaktion kalkuliert?

1 Cent

Für 90 Dollar bekommt man 10.000 geklaute E-Mail-Accounts, ein einzelner Account ist also ungefähr einen Cent wert:

»Unterdessen rückt Rik Ferguson von Trend Micro den Vorfall in die richtige Perspektive. 10.000 gestohlene Account-Daten seien nichts Ungewöhnliches. Die würden auf dem freien Markt etwa 90 Dollar kosten – wenn man die üblichen 10 Prozent Rabatt abzieht.«

(heise Security: Test für kompromittierte E-Mail-Accounts)

Weiß jemand, wie hoch im Vergleich dazu der Schaden pro Account ist?

Digital Cold Reading: The CSS History Hack

[See only posts in English]

Cold reading is a technique used by mentalists to simulate psychic powers and impress people. Essentially, the cold reader is supplying words and the other person supplies their meaning as well as hints for the reader.

The CSS history hack, which seems to impress quite a few people, is nothing more than the Web’s version of cold reading. Your impression is that any Web site can read your browser history. Now there is indeed an information leak and no Web site should get access to history information. But this leak is very small. It doesn’t reveal the history altogether to anyone daring to ask. The CSS history issue only gives us an oracle. We can ask the oracle whether a particular URL is in the history or not. So to find out that you’ve read this blog post we would have to ask the oracle about the precise URL of this post.

Nonetheless demonstrations of the history hack impress people. The trick is simple and similar to the cold reading technique. History hack demos use a set of URLs that leads to a hit for almost every Internet user on the world: Google, YouTube, Microsoft, Wikipedia, Flickr, Apple, Slashdot, Amazon, and so on. A mentalist would guess and suggest these until you start giving feedback on which to hook. The CSS history hack replaces this interaction with asking the oracle to avoid wrong guesses. The trick is really to use a set of Web sites that guarantees a hit, and use a minor information leak to remove the wrong guesses from the set that would spoil the effect. This works well with the top 20/top 50/top 1000 sites on the Web, but it won’t scale to arbitrary URLs.

Häh?

Kann mir jemand sagen, ob ich das möchte? Oder weiß wenigstens jemand, unter welchen Umständen so eine Meldung typischerweise zustandekommt? Der Text klingt ein wenig schräg, und der Hilfe-Button ist nur Dekoration.

Schnäppchenpreis

»Ein Botnetz, das zwischen 5000 und 10.000 Bots kontrolliert, kann laut Wüest für 10 US-Dollar pro Woche gemietet werden.«

(Heise online: Spam-Bots werten soziale Netze aus)

Swiss Cheese Security

I’m off for the New Security Paradigms Workshop in Oxford, where I will present what I currently call the Swiss Cheese security policy model. My idea is to model security mechanisms as classifiers, and security problems in a separate world model as classification problems. In such a model we can (hopefully) analyze how well a mechanism or a combination of mechanisms solves the actual problem. NSPW is my first test-driving of the general idea. If it survives the workshop I’m going to work out the details. My paper isn’t available yet; final versions of NSPW papers are to be submitted a few weeks after the workshop.

In einem Wort

C-DLICE

Production-safe Testing

[See only posts in English]

Software testers increasingly have to deal with production systems. Some tests make sense only with production systems, such as Nessus-style vulnerability scanning. And an increasing number of systems is hard to reproduce in a test bed as the system is really a mashup of services, sharing infrastructure with other systems on various levels of abstraction.

Testing production systems imposes an additional requirement upon the tester, production safety. Testing is production-safe if it does not cause undesired side-effects for the users of the tested or any other system. Potential side effects are manifold: denial of service, information disclosure, real-world effects caused by test inputs, or alteration of production data, to name just a few. Testers of production systems therefore must take precautions to limit the risks of their testing.

Unfortunately it is not yet very clear what this means in practice. Jeremiah Grossman unwittingly started a discussion when he made production-saftey a criterion in his comparison of Website vulnerability assessment vendors. Yesterday he followed up on this matter with a questionnaire, which is supposed to help vendors and their clients to discuss production-safety.

The time is just right to point to our own contribution to this discussion. We felt a lack of documented best practice for production-safe testing, so we documented what we learned over a few years of security testing. The result is a short paper, which my colleague and co-author Jörn is going to present this weekend at the TAIC PART 2009 conference: Testing Production Systems Safely: Common Precautions in Penetration Testing. In this paper we tried to generalize our solutions to the safety problems we encountered.

The issue is also being discussed in the cloud computing community, but their starting point is slightly different. Service providers might want to ban activities such as automated scanning, and deploy technical and legal measures to enforce such a ban. They have good reason to do so, but their users may have equally good reason to do security testing. One proposal being discussed is a ScanAuth API to separate legitimate from rogue scans. Such an API will, however, only solve the formal part of the problem. Legitimate testing still needs to be production-safe.

Management ohne Metriken

Der eine oder andere dürfte es mitbekommen haben. Tom DeMarco, dem wir die Manager-Faustregel: “You can’t control what you can’t measure.” verdanken, macht einen Rückzieher. An Software Engineering will er nicht mehr so recht glauben, und an Metriken auch nicht. In seinem Artikel Software Engineering: An Idea Whose Time Has Come and Gone? erläutert er seinen Sinneswandel unter anderem an diesem Beispiel:

»Imagine you’re trying to control a teenager’s upbringing. The very idea of controlling your child ought to make you at least a little bit queasy. Yet the stakes for control couldn’t be higher.
(…)
Now apply “You can’t control what you can’t measure” to the teenager. Most things that really matter—honor, dignity, discipline, personality, grace under pressure, values, ethics, resourcefulness, loyalty, humor, kindness—aren’t measurable.«

Von der Vorstellung, wir könnten ausgerechnet in der IT-Sicherheit Risiken anhand von Metriken steuern, sollten wird uns schnell verabschieden. Zusätzliche Unbekannte und Rückkopplungen vereinfachen das Problem sicher nicht.

Ach ja, und hört nicht auf Gurus.

In einem Wort

cloudenfreude (via)

Internet helpdesk

(direct, via)

50 Ways to Inject Your SQL

(direct link, found here)

In einem Wort

Frustration Hacking

In einem Wort

touring test

Unterschätzte Risiken: Killerspiele

Wer solche Dienstleister beschäftigt (und kein Backup hat), der braucht keine Feinde mehr:

»Er hatte seinen Sohn mit zu einem Firmenkunden genommen. Während der Verurteilte seiner Arbeit nachging, machte sich sein Sohn an einem Kundenrechner zu schaffen und löschte dabei beim Versuch ein Computerspiel zu installieren, versehentlich wichtige Datenbestände.«

(Blog zur IT-Sicherheit: Sind Ihre Daten wirklich sicher?)

Mehr Spaß mit SSL (in Firefox 3)

Dieser Tipp ist nicht neu, aber mein Leidensdruck war nicht so groß, dass ich aktiv danach gesucht hätte. Das Verhalten von Firefox bei formal ungültigen SSL-Zertifikaten lässt sich etwas weniger nervig gestalten:

• about:config aufrufen
• browser.xul.error_pages.expert_bad_cert auf true setzen
• browser.ssl_override_behavior auf 2 setzen

(gefunden hier, Erklärung da).

Damit spart man sich ein paar unnötige Mausklicks.

Unterschätzte Risiken: Hackerwettbewerbe

Lehrreiches Scheitern:

»A Webmail service that touts itself as hack-proof and offered $10,000 to anyone who could break into the CEO’s e-mail has lost the challenge.
(…)
The hacking team of Aviv Raff, Lance James and Mike Bailey set up the attack by sending an e-mail to the company’s CEO Darren Berkovitz. When he opened the e-mail, the team exploited an XSS flaw to take control of the account.«

(Zero Day: StrongWebmail CEO’s mail account hacked via XSS)

Die 10.000 Dollar hätten sie auch gleich bei einem fähigen Security-Tester anlegen können, dann hätten sie für dasselbe Geld wahrscheinlich mehr über ihre Irrtümer gelernt. Allzu weit kommt man mit diesem Betrag zwar nicht, aber die Tester arbeiten wenigstens bis zum Ende des Geldes weiter, statt mit dem ersten gefundenen Problem den Preis abzuräumen. Damit sinkt auf lange Sicht der Preis pro gefunder Verwundbarkeit, während er bei einer Folge von Hackerwettbewerben vielleicht sogar steigen würde.

Digitalräuberpistole

Erinnert sich noch jemand an die Story von vor sechs Wochen, derzufolge es mit einem manipulierten Nokia 1100 möglich sei, Kurznachrichten an GSM-Teilnehmer abzufangen? Kriminelle würden bis zu 25.000 Euro für ein solches Gerät bieten, weil auf diese Weise mTAN-Sendungen abzufangen seien. Glauben wollte das keiner so recht.

Inzwischen macht die Meldung die Runde, der Firma UltraScan – die das Thema damals in die Nachrichten brachte – sei es gelungen, die Sache (ein einzges Mal) nachzuvollziehen. Von löschbarem ROM in einigen Modellen der Serie aus dem Bochumer Nokia-Werk ist die Rede und von Schlüsseln für eine verschlüsselte Firmware, die in falsche Hände geraten seien. Dann wird es wirr: man könne durch Firmware-Hacking neben der IMEI, die das Gerät identifiziert, auch die IMSI, die Identität der SIM-Karte, manipulieren – wozu man allerdings eine SIM-Karte klonen müsse, was aber trivial sei.

Alles verstanden? Ich auch nicht. Und die Websites von Ultrascan erwecken nicht gerade den Eindruck hoher Kompetenz und Seriosität.

Kurze Durchsage

Die Herren Isotopp, Knüwer und Vetter kommentieren die politische Lage.

Compliance leicht gemacht

Microsoft hat den .NET Messenger für Nutzer in Kuba, Syrien, Iran, Sudan und Nordkorea gesperrt. Diese Länder unterliegen einem Embargo der Vereinigten Staaten; US-Firmen dürfen mit ihnen keine Geschäfte machen. Manche finden das hirnrissig (das ist es auch, aber es ist Gesetz), während andere die Umsetzung für hirnrissig halten. Microsoft benutzt nämlich einfach die im Profil hinterlegte Landeseinstellung des Nutzers, und die ist frei wählbar.

Diese Implementierung ist aber nicht hirnrissig, sondern vollständig rational und typisch für Compliance-Probleme. Security dreht sich um die Lösung eigener Probleme, die Durchsetzung eigener Interessen mit technischen und organisatorischen Mitteln. Diese Mittel sollen – im Rahmen des jeweils vertretbaren Aufwandes – effektiv sein, also böswillige Angriffe tatsächlich abwehren. Dabei besteht ein direkter Zusammenhang zwischen den erwarteten Schäden durch Angriffe und dem vertretbaren Aufwand.

Compliance hingegen erfordert die Wahrung fremder Interessen, auferlegter Regeln und Anforderungen. Zu eigenen Interessen eines Unternehmens werden sie erst aufgrund angedrohter Zwangsmaßnahmen. Effektivität ist auch hier das Ziel, aber maßgeblich sind nun nicht mehr die direkten Auswirkungen, sondern die angedrohten. Die sind willkürlich festgelegt.

Ein Unternehmen, das Compliance erzielen möchte beziehungsweise muss, wird deshalb jeweils zum einfachsten und billigsten Mittel greifen, das die angedrohten Zwangsmaßnahmen genügend zuverlässig abwehrt. Dieses Mittel muss keinen realen Effekt haben. Es muss lediglich die Kontrolleure zufriedenstellen. Die Lösung von Microsoft für das Compliance-Problem des Messengers leistet dies vermutlich.

Das tatsächliche Problem ist damit vorerst gelöst. Ob Kubaner, Sudanesen oder Nordkoreaner mit dem .NET Messenger chatten, ist dagegen nur ein Scheinproblem. Ohne Compliance-Zwänge wäre es Microsoft einfach egal. Aus geschäftlicher Sicht gäbe es keinen Grund darüber auch nur nachzudenken.