Archiv der Kategorie: Testlabor

Betreutes Denken

Geschäft, Security, Testlabor, , , , , , , , , ,

Mein Kollege Jörn Eichler sucht Studenten, die unter seiner Betreuung ihre Abschlussarbeit zu einem der folgenden Themen schreiben möchten:

  • Modellgetriebene, sichere Konfiguration von Laufzeitumgebungen für elektronischer Prozesse
  • Entwicklung eines Werkzeugs für die Sicherheitsmodellierung elektronischer Prozesse
  • Modellgetriebenes Testen elektronischer Geschäftsprozesse

The Point of Penetration Testing

English, Geschäft, IT, Security, Testlabor, Vulnerability, , , , ,

I’m glad to see that the community starts to acknowledge what penetration testing really means. We never encountered the empty hands issue as we never sold the let’s-see-if-we-can-hack-it kind of a penetration test. We carry out vulnerability assessments based on whichever information we can get about a system or product, the more the better, and use testing as a means of getting more, or clarifying information. The point of a penetration test is not to find and demonstrate one or a handful of arbitrary attacks, the point of a penetraion test is to identify vulnerabilities that need attention. Sure, it is fun to give an uberhacker demo after the test, and we do that, too, if we’ve found gaping security holes. But more important in a penetration test is good coverage of the potential vulnerabilities, and a sound assessment of their importance, relative to the purpose and risk profile of a system. I even remember pentesting projects where we found only a few relatively minor issues in a low-risk website – and made our clients happy by telling them just that. There is really no need to be disappointed if a penetration test ends without a root shell. There is no point in withholding information from testers, reducing their efficiency. And there is no point in testing just the infrastructure but not the applications.

Neat XSS Trick

English, Hackmeck, IT, Security, So geht das, Testlabor, , , , , ,

I just learned a neat XSS trick from a blog post by Andy Wingo. This is old news to the more proficient web application testers among my readers, but it was new to me and I like it. I wasn’t aware that one could redirect function calls in JavaScript so easily:

somefunction = otherfunction;

somewhere in a script makes somefunction a reference to otherfunction. This works with functions of the built-in API, too, so any function can become eval:

alert = eval;

or

window.alert = eval;

So if you can inject a small amount of script somewhere, and a function parameter elsewhere, you can turn the function that happens to be called into the eval you need. This PHP fragment illustrates the approach:

<?php
// XSS vulnerability limited to 35 characters
print substr($_GET["inject1"], 0, 35);
?>

<script>
// URL parameter goes into a seemingly harmless function - which we
// can redefine to become eval
<?php $alertparam = htmlspecialchars(addslashes($_GET["inject2"]), ENT_COMPAT ); ?>
alert('<?=$alertparam?>');
</script>

The first PHP block allows up to 35 characters to be injected into the page unfiltered through the inject1 URL parameter, just enough to add to the page this statement:

<script>alert=eval;</script>

or

<script>window.alert=eval;</script>

The second block embeds the value of the inject2 URL parameter in JavaScript as the parameter of alert() after some (imperfect) escaping. This one has unlimited length but goes into a seemingly harmless function – until somebody exchanges the function behind the identifier alert.

To see it work, put the PHP code on your web server and call it with a URL like this:

xss.php?inject1=<script>window.alert=eval;</script>&inject2=prompt('Did you expect this? (Yes/No)');

This works fine with Firefox 9 and, if XSS filter is disabled, IE 9. Safari 5.1.2 silently blocks the exploit, telling me about it only in debug mode. If you really need to, you’ll probably find an evasion technique against client-side XSS filters. IE seems to need window.alert, while Firefox is happy with just alert in inject1.

The German eID system explained and discussed

English, Forschung, ID, IT, Regierungsviertel, Security, Testlabor, , , , , ,

We just finished reviewing the final, ready-to-print version of our article Electronic Identity Cards for User Authentication—Promise and Practice, which will appear in the upcoming issue of IEEE Security & Privacy Magazine (vol. 10, no. 1, jan/feb 2012, DOI: 10.1109/MSP.2011.148). We outline how the German eID system works and discuss application issues. Here is our abstract:

Electronic identity (eID) cards promise to supply a universal, nation-wide mechanism for user authentication. Most European countries have started to deploy eID for government and private sector applications. Are government-issued electronic ID cards the proper way to authenticate users of online services? We use the German eID project as a showcase to discuss eID from an application perspective. The new German ID card has interesting design features: it is contactless, it aims to protect people’s privacy to the extent possible, and it supports cryptographically strong mutual authentication between users and services. Privacy features include support for pseudonymous authentication and per-service controlled access to individual data items. The article discusses key concepts, the eID infrastructure, observed and expected problems, and open questions. The core technology seems ready for prime time and government projects deploy it to the masses. But application issues may hamper eID adoption for online applications.

We think that eID functions of government-issued ID cards will not replace means of everyday online authentication. With eID, there will be few new use cases for ID cards, eID just supports online versions of the traditional use cases. Most of the traditional use cases in Germany involve bureaucracy or legal requirements: legal protection for children and young persons, required identification of mobile phone users or bank account holders, or procedures of administrative bodies involving »Ausweis bitte!« at some point. For those who followed the debate and rollout in Germany, there should be nothing new in our article, but the article may come in handy as a reference for international audiences.

Our article will be in good company as it will appear in a theme issue on authentication. If I read the preprints collection correctly, there will be a user study by Amir Herzberg and Ronen Margulies,  Training Johnny to Authenticate (Safely), and an article by Cormac Herley and Paul van Oorschot, A Research Agenda Acknowledging the Persistence of Passwords (authors‘ version). It seems sexy to many to call the days of the password counted—IBM just predicted password authentication would die out soon—but if I had to make a bet I would follow Cormac and Paul.

The final version of our article will be paywalled by IEEE, but you can find our preprint with essentially the same contents on our website.

Homecomputer im Test

Freundlich zum Nutzer, Gadget, IT, Nerds, Testlabor, Wahrnehmung, , , ,

Damals wusste man noch nicht so recht, was man mit einem Computer zu Hause anstellen soll, und arbeitete sich an offensichtlichen, aber nicht unbedingt nützlichen Anwendungen ab:

Wer beispielsweise die Bestände seines gut sortierten Weinkellers elektronisch speichern möchte, müßte – sobald ihm der Sinn nach einem edlen Tropfen steht – folgende Prozedur hinter sich bringen: Heimcomputer einschalten, Programmkassette in den Recorder einlegen, Programm laden, Kassette wechseln und »Weinkellerdaten« in den Rechner einlesen, Befehl zur Auswahl eines trockenen ’82er Württembergers eingeben, eintragen in den Daten bestand, dass die Flasche nun bald geleert sein wird. Schreiben der gesamten Daten zurück auf die Kassette. Wegräumen der Kassetten und Ausschalten des Rechners. Während der elektronisch ausgerüstete Weinkenner nun den Weg in den Weinkeller antritt. um die richtige Flasche zu suchen, hebt der technisch rückständige Bacchant gerade das weite Glas und trinkt auf die gute alte Zeit, als man Wein noch mit Kennerblick auswählte.

PIN-Gambit

Rechtsabteilung, Security, So geht das, Testlabor, Vulnerability, , , , ,

Wenn die Bankkarte weg ist und kurz darauf Geld vom Konto verschwindet, dann treffen Sie Ihre Bank wahrscheinlich bald vor Gericht. Sie werden Ersatz fordern, die Bank wird ihn verweigern. Für solche Situationen sind Gerichte da, aber wer dort Erfolg haben will, braucht die richtige Strategie. Die Bank hat eine Strategie,  sie wird das PIN-Gambit spielen. Das PIN-Gambit geht so: Die Bank behauptet, ihre Systeme seien sicher, das Abheben von Bargeld am Automaten nur mit Kenntnis der zugehörigen PIN möglich und diese PIN nicht aus der Karte zu ermitteln. Folglich weise eine erfolgte Abhebung kurz nach dem Diebstahl darauf hin, dass der Täter die PIN gekannt haben müsse. Da die Vertraulichkeit der PIN durch den Kunden zu gewährleisten sei, müsse dieser seine Sorgfaltspflichten verletzt und die PIN irgendwo aufgeschrieben haben. Klingt bizarr, aber Richter akzeptieren so etwas und nennen es Anscheinsbeweis.

Als Prozessgegner können und müssen Sie den Anschein erschüttern, aber das ist nicht leicht, denn dazu bedarf es konkreter Beweise. Vage Schilderungen denkbarer anderer Abläufe genügen nicht. Das aber ist sehr schwer, auch wenn Sie sich korrekt verhalten und die PIN weder auf der Karte noch sonst irgendwo vermerkt haben. Die Karte ist weg, fällt als Beweis also aus. Die technischen Systeme der Bank sind vielfältig und komplex, eine gründliche Analyse auf Sicherheitsmängel könnte mehrere Sachverständigenjahre verschlingen. Wenn Sie versuchen, den Anscheinsbeweis der Bank zu erschüttern, nehmen Sie das Gambit an. Das können Sie tun, aber dann wird die Sache mühsam. Im weiteren Verlauf wird sich alles um die Frage drehen, auf welche Weise der Täter an die PIN gelangt ist, und die Beweislast liegt bei Ihnen.

Stattdessen könnten Sie direkt zum Gegenangriff übergehen. Dazu rufen Sie Vertreter der Bank in den Zeugenstand und stellen ihnen Fragen:

  • Welche PIN wurde bei den missbräuchlichen Abhebungen verwendet?
  • Erfolgte die PIN-Prüfung anhand des Magnetstreifens oder unter Verwendung des Kartenchips?
  • Woran erkennt die Bank, wenn sie eine Buchung ausführt, dass die richtige PIN eingegeben wurde?
  • Falls die Abhebung am Automaten eines anderen Instituts erfolgte, woher weiß die Bank, dass dort alles mit rechten Dingen zugeht? Woran erkennt die Bank, dass dort eine korrekte PIN-Prüfung erfolgte?
  • Führt die Bank Aufzeichnungen über Fehlversuche bei der PIN-Eingabe? Welche Aufzeichnungen liegen der Bank für den fraglichen Zeitraum vor? Sind davon alle Anwendungen des Chips erfasst, die eine PIN-Prüfung erfordern oder ermöglichen?
  • Welche Anwendungen oder Funktionen des Kartenchips erfordern oder ermöglichen eine PIN-Prüfung? Verwenden diese Anwendungen alle dieselbe PIN? Verwenden sie einen gemeinsamen Fehlversuchszähler?
  • Gibt es technische Möglichkeiten, die PIN oder den Programmcode des Kartenchips zu verändern? (Tipp: Ja, die gibt es.)
  • Gibt es eine technische Möglichkeit, eine nach mehrfacher Fehleingabe der PIN gesperrte Karte zu entsperren?
  • Wird eine Karte nach Ablauf der Geltungdauer ausgetauscht, stellt die Bank dann eine neue Karte mit derselben PIN aus? Wie ist das technisch realisiert? Wo werden die erforderlichen Informationen aufbewahrt?

    • Um den Prozess zu gewinnen, genügen diese Fragen vielleicht nicht. Eine gute Grundlage für das Gutachten eines Sachverständigen liefern sie allemal, und vor allem ändern sie den Blick auf das Problem.

    * * *

    Wenn Sie eine Rechsberatung benötigen, konsultieren Sie bitte einen Rechtsanwalt Ihrer Wahl.

    Hacking als Beruf

    Events, IT, Propaganda, Security, Testlabor,

    Vortrag und Live-Demo zu Schwachstellensuche und –absicherung
    3. November 2010, 16:15-18:00 Uhr, TU Darmstadt | Gebäude S2/02 Raum C120

    Studierende und Interessierte können sich bei der Veranstaltung an der TU Darmstadt über Hacker-Methoden in der IT-Sicherheitsausbildung informieren.

    Im Anschluss an seinen Vortrag demonstriert Dr. Martin Mink vom Center for Advanced Security Research (CASED) in einer Live-Demo die (Un)Sicherheit von Webshops und Methoden zur Absicherung.

    Praktische IT-Sicherheit 2010

    Events, IT, Propaganda, Security, Testlabor, Unterwegs, , ,

    Das Rheinlandtreffen „Praktische IT-Sicherheit“ findet in diesem Jahr früher als gewohnt am 31.8. und 1.9. in der Hochschule Bonn-Rhein-Sieg statt. Ich bin mit einem Vortrag zum produktionssicheren Testen dabei, dessen Inhalt im Wesentlichen unserem Artikel in der <kes> 2010#2 folgt. Sicherheitstests sind ein Schwerpunkt der Veranstaltung, aber nicht das einzige Thema. Das komplette Programm gibt’s auf der Website bei unseren Kollegen vom Fraunhofer INT, wo man sich auch anmelden kann.

    Gezielte Verteidigung

    Forschung, Geschäft, Risiko, Safety, Security, Testlabor, , , , ,

    Ein gutes Bedrohungsmodell erleichtert die Verteidigung, indem es gezielte Sicherheitsmaßnahmen ermöglicht. Das demonstrieren uns Ladeninhaber, die ihre Alarmanlagen mit Nebelmaschinen koppeln. Diese Idee ist vermutlich gut: Einbrecher kommen mit dem Ziel, schnell und einfach eine gewisse Menge Waren mitzunehmen, ohne dabei gefasst zu werden. Dichter Nebel stört dabei. Er verhindert zwar nichts, verlangsamt aber Vorgänge: das Auffinden der Beute, das Heraustragen und gegebenenfalls auch die Flucht, was das Risiko der Täter erhöht. Außerdem kostet Nebel nicht viel, gewiss weniger als eine strikt präventive Ausstattung des gesamten Gebäudes mit einbruchshemmenden Maßnahmen. Alle Schäden verhindert er nicht, aber zur Reduktion taugt er allemal.

    Was macht ein Bedrohungsmodell brauchbar? Das ergibt sich daraus, wozu man dieses Modell braucht: man möchte im Modell die mutmaßliche Wirksamkeit und Eignung von Sicherheitsmaßnahmen diskutieren, einschätzen und vergleichen. Die so begründeten Entscheidungen sollen später mit hoher Wahrscheinlichkeit den Realitätstest überstehen.

    Gezielte Verteidigung weiterlesen →

    Unterschätzte Risiken: Testdaten

    IT, Testlabor, Unterschätzte Risiken,

    Die Geschichte endet etwas verworren, aber der Anfang passt als Fallstudie zum Thema produktionssicheres Testen:

    »Embarrassed cops on Thursday cited a „computer glitch“ as the reason police targeted the home of an elderly, law-abiding couple more than 50 times in futile hunts for bad guys.

    Apparently, the address of Walter and Rose Martin’s Brooklyn home was used to test a department-wide computer system in 2002.«

    (Computer snafu is behind at least 50 ‚raids‘ on Brooklyn couple’s home)

    Ob in diesem Fall wirklich Testdaten die Ursache sind, kann ich aus der Ferne nicht beurteilen. Plausibel ist es allemal.

    Patchday

    Events, Security, Testlabor, Unterwegs, , , ,

    Der Geldautomat hat gesagt, meine Karte sei nun wieder gesund. Die Sparkassen haben das Kartenupdate über die Geldautomaten also offenbar laufen und es scheint innerhalb der Sparkassenorganisation auch überregional zu funktionieren. Das ist technisch eh‘ kein Problem, verdient angesichts der organisatorischen Kleinstaaterei aber dennoch ein Lob. Ob die Volks- und Raiffeisenbanken das auch so hinkriegen?

    The Evil Jan Attack

    English, Hackmeck, IT, Security, Testlabor, Trusted Computing, Video, , , , , , , , , , , ,

    [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. The Evil Jan Attack weiterlesen →

    Production-safe Testing

    English, IT, Safety, Security, Testlabor, , , , , ,

    [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.