TR-Mail

E-Mail vom Staat, das löst hierzulande einiges Misstrauen aus. Woanders fragt man gar nicht erst:

»Ab nächstem Jahr bekommen alle türkischen Neugeborenen eine E-Mail-Adresse vom Staat. Diese Adresse wird von einer Behörde verwaltet und in den Pass gedruckt. Zugleich soll die Verwendung ausländischer Dienste wie Google und Yahoo verboten werden. Das Projekt dient der nationalen Sicherheit.«

(Welt Online: Nationale Sicherheit: Jeder Türke erhält eine E-Mail-Adresse vom Staat)

The Evil Jan Attack

[See only posts in English]

Microsoft’s BitLocker is, for all we know, a proper disk encryption software. It encrypts data at rest against attacks originating outside the running system. If you use BitLocker and your computer is stolen while turned off, there is essentially no way of reading data from the disk without having the proper key(s)—your BitLocker PIN, a key file on a USB stick, or both. If an attacker gets access to the machine while it is running, there may be ways of compromising it through Windows or in other ways, but such attacks are clearly outside the scope of disk encryption.

We know, however, another class of attacks against disk encryption: evil maid attacks. This term describes a general strategy rather than a particular implementation. If you leave your computer unattended, let’s say in a hotel room, an attacker, let’s say an evil maid, might manipulate it such that your data will be compromised as soon as you return and provide it with your encryption keys. There are various ways of doing so, for instance installing a hardware keylogger if your keys are based on passwords, or altering the unencrypted boot code to install a Trojan horse that will leak your keys later.

Herr, schmeiß Hirn vom Himmel!

Nach der WAF nun also die Datenbank-Firewall. Weil dämliche PHP-Programmierer nicht in der Lage sind, sicher auf Datenbanken zuzugreifen, soll GreenSQL zwischen Anwendung und Datenbank heuristisch SQL Injection erkennen. Die Idee ist so blöd, dass ich nicht mal beim szenetypischen Herumalbern darauf gekommen wäre.

Kernproblem bei Injection-Lücken ist die ungenügende Trennung zwischen Daten und Code in Verbindung mit dem Impedance Mismatch zwischen Programmier- und Datenbanksprache. Die kanonische Lösung besteht darin, eben diese Trennung zuverlässig aufrechtzuerhalten. Das lässt sich recht einfach bewerkstelligen, indem man eine geeignete Programmierschnittstelle − Prepared Statements statt Stringverkettung zu SQL-Statements − verwendet. Das kann zwar auch noch schiefgehen, wenn die Bibliotheksfunktion Fehler hat, aber wenigstens kann man sich selbst nicht mehr in den Fuß schießen.

Ist die Grenze zwischen Code und Daten einmal verwischt, steht die Datenbankfirewall vor exakt demselben Problem wie die Datenbank selbst: sie kann diese Grenze nicht mehr zuverlässig bestimmen. Konzeptionell ist die Datenbankfirewall deswegen genauso machtlos wie die Zugriffskontrolle der Datenbank. Sie versucht es nur mit einer anderen Strategie. Klüger wäre es, den Entwicklern ausschließlich sichere Schnittstellen zur Verfügung zu stellen.

Als Security-Theater allerdings dürfte so eine Datenbankfirewall hervorragend funktionieren, spuckt sie doch am laufenden Band Meldungen aus, die MovieOS alle Ehre machen würden: Hilfe, wir werden angegriffen!

In einem Wort

Panic Password

Gewagt

IT-Sicherheit auf einem Bierdeckel. Am schönsten finde ich Aufpassen. Dieser Empfehlung kann nun wirklich niemand widersprechen.

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?)