Web-Sicherheit

Januar 9, 2012

Shreeraj Shah präsentiert Angriffstechniken auf aktuelle Webtechnologien

Filed under: Allgemein — sebastiankuebeck @ 22:34
Tags: , , , , , , , , ,

Shreeraj Shahs Präsentation von der AppSecUS 2011 (die er auch auf der Blackhat- und OWASP-Konferenz gehalten hat) über Angriffstechniken auf aktuelle Webtechnologien HTML5, XHR and DOM Security ist nun online verfügbar, zusammen mit seinem Paper Reverse Engineering Browser Components – Dissecting and Hacking Silverlight, HTML 5 and Flex.

Wie der Titel schon andeutet, geht es dabei nicht um HTML 5 alleine sondern auch umd das Zusammenspiel von Browsern und Plugins wie Flash und Silverlight. Er beschreibt darin detailliert, wie man aktuelle Webanwendungen gezielt auf Schwachstellen untersucht und diese dann ausnutzt.

Es werden dabei kaum  grundsätzlich neue Angriffstechniken vorgestellt, sondern gezeigt, wie bestehende Angriffstechniken (Cross-Site Scripting, Cross-Site Request Forgery, Clickjacking) mit aktuellen Browsern und Plugins noch wirksamer eingesetzt werden können.

Januar 5, 2012

Cross-Site-Scripting-Angriffe auf Smartphone-Apps und Desktop-Applikationen

Filed under: Allgemein — sebastiankuebeck @ 09:13
Tags: , , , , , ,

Cross-Site-Scripting-Schwachstellen sind generell als Websiten- oder Browser-Schwachstellen bekannt. In heutigen Desktop-Anwendungen und Smartphone-Apps ist es allerdings nicht unüblich, Web-Technologien wie HTML und JavaScript in die Anwendung einzubinden, was diese Anwendungen wiederum anfällig für Cross-Site-Scripting-Angriffe macht. Im Gegensatz zu reinen Webanwendungen ermöglichen es diese „hybriden“ Anwendungen Angreifern in manchen Fällen direkt auf das Betriebssystem zuzugreifen.

In letzter Zeit wurden solche Schwachstellen in Skype und ICQ identifiziert und auch bereits für Angriffe ausgenutzt. In seiner Präsentation auf der Derbycon 2011 zeigt Kyle Osborne (kos), wie man diese Schwachstellen beispielsweise in Instant-Messaging-Clients findet und ausnutzt.

September 16, 2011

Wie man den Cross-Site-Scripting-Filter von Googles Chrome umgeht

Filed under: Allgemein — sebastiankuebeck @ 15:53
Tags: , , , , , , ,

Googles aktueller Chrome Browser hat standardmäßig einen Filter gegen Cross-Site-Scripting-Angriffe eingebaut. Nick Nikiforakis zeigt auf seinem Blog, wie einfach man diese Schutzfunktion umgehen kann.

Damit man die geschilderte Angriffstechnik gleich ausprobieren kann, hat er folgendes PHP-Skripft veröffentlicht, dass die Parameter a und b in der URL entgegennimmt und ohne weitere Kodierung ausgibt:  http://securitee.org/files/chrome_xss.php.

Um zu testen, ob überhaupt eine Cross-Site-Scripting-Schwachstelle vorliegt, probieren wir erst einmal aus, ob der Überschrift-Tag in der folgenden Anfrage vom Browser ausgeführt wird (die meisten Filter reagieren lediglich auf Inhalte, die JavaScript enthalten oder nachladen. Begnügt man sich erst einmal mit einem harmlosen Tag, kann man einfach herausfinden, ob sich ein Angriff prinzipiell möglich ist):

http://securitee.org/files/chrome_xss.php?a=<h1>HTML_INJECTION<h1>&b=bar

Das funktioniert augenscheinlich ohne Probleme:

Der „naive“ Versuch, einfach einen Script-Tag einzuschleusen, funktioniert hingegen nicht:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);</script>&b=bar

Chrome entfernt den Inhalt des Script-Tags bevor er die Seite anzeigt:

Als nächstes untersuchte Nick Nikiforakis was passiert, wenn man den Script-Tag nicht abschließt:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);&b=bar

Dabei zeigte sich, dass der Browser den Script-Tag nicht entfernte sondern automatisch schloss. Da allerdings alles, was nach dem Script-Tag kommt nun im JavaScript-Context ausgeführt wird, gibt der JavaScript-Interpreter auf und führt den Code nicht aus:

Was wir nun erreichen müssen ist, dass der Browser den HTML-Code zwischen den beiden Parametern ignoriert, die wir übergeben und das funktioniert, indem wir ihn in einen JavaScript-Kommentar einschließen:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);/*&b=*/</script>

Und das funkioniert auch, wovon man sich leicht überzeugen kann…

Nick hat das Problem dem Chrome-Team gemeldet, allerdings haben die Chrome-Entwickler noch keinen Weg gefunden, solche Angriffe zu verhindern. Dabei hat Nick nur an der Oberfläche gekratzt und bei weitem nicht alle bekannten Tricks, mit denen man solche Schwachstellen ausnutzen kann, ausprobiert (das „Standardwerk“ zu diesem Thema ist übrigens das XSS Cheat Sheet auf ha.ckers.org).

Es zeigt sich also einmal mehr, dass man um das Absichern der Webanwendung selbst nicht herumkommt. Auch nicht mit noch so gut gemeinten Technologien auf Client- und Serverseite. Microsoft hat sich bei diesem Thema voriges Jahr auch die Finger verbrannt, denn eine Schwachstelle im Cross-Site-Scripting-Filter des Internet Explorer 9 führte dazu, dass Seiten, die bislang nicht verwundbar waren, durch den Filter plötzlich verwundbar wurden.

August 29, 2011

Umgehen von PHPIDS

Filed under: Allgemein — sebastiankuebeck @ 11:43
Tags: , , , , , , , , ,

Michael Brooks beschreibt in seinem kürzlich erschienenen Paper Bypassing PHPIDS 0.6.5 wie man das Intrusion Detection System (kurz IDS)  PHPIDS in der Version 0.6.5 umgeht. Er hat dieses Produkt unter anderem mit dem statischen Analysetool RIPS PHP untersucht und einige gravierende Schwachstellen gefunden.

Firewalls und IDS verfolgen generell zwei unterschiedliche Ansätze: Firewalls reduzieren die Angriffsfläche indem sie den eingehenden Netzwerkverkehr analysieren und nur das durchlassen, was explizit erlaubt ist. IDS hingegen überprüfen den Netzwerkverkehr auf Anzeichen eines Angriffs. Haben sie einen solchen erkannt, generieren sie eine Warnmeldung oder blockieren die Anfrage. Anders ausgedrückt könnte man bei einer Firewall von einem White-List-Filter sprechen, der nur das durchlässt, was ausdrücklich erlaubt ist. IDS hingegen stellen einen Black-List-Filter dar, es wird also alles durchgelassen bis auf das, was als Angriff erkannt wird. Bei Web-IDS und -Firewalls verfolgen üblicherweise beide Ansätze, weshalb diese Begriffe häufig synonym gebraucht werden, daher teilen diese Techniken auch dieselben Schwächen.

Unzureichender Schutz vor ReDoS-Angriffen kann dazu ausgenutzt werden, die Angriffserkennung komplett zu umgehen

Die erste Schwachstelle ergibt sich aus einem Mechanismus, der das IDS vor ReDoS-Angriffen schützen soll.

	    /**
	     * Make sure the value to normalize and monitor doesn't contain
	     * possibilities for a regex DoS.
	     *
	     * @param string $value the value to pre-sanitize
	     *
	     * @static
	     * @return string
	     */
	    public static function convertFromRepetition($value)
	    {
	        // remove obvios repetition patterns
	        $value = preg_replace(
	            '/(?:(.{2,})\1{32,})|(?:[+=|\-@\s]{128,})/',
	            'x',
	            $value
	        );
	        return $value;
	    }

Der regulärte Ausdruck überprüft dabei einfach, ob sich irgendein Textmuster, das zumindest zwei Zeichen enthält, mindestens 33 mal wiederholt oder Ein Zeichen der Zeichenklasse [+=|\-@\s] zumindest 128 mal wiederholt. Ist dies der Fall, wird der ganze Ausdruck durch x ersetzt, bevor die eigentliche Angriffserkennung erfolgt.

Ein Ausdruck der Form:

abababababababababababababababababababababababababababababababababa!

Wird also schlicht in folgenden umgewandelt:

x!

Das Problem dabei ist, dass diese Funktion einerseits keinen Schutz gegen ReDoS-Schwachstellen darstellt (siehe meine Artikelserie darüber) und andererseits dazu missbraucht werden kann, die gesammte nachgeschaltete Angriffserkennung zu umgehen. Man brauch ja nur die Angriffssignatur mindestens 33 mal zu wiederholen, also beispielsweise folgende Anfrage absetzten:

<script>alert(1);</script><script>alert(1);</script><script>alert(1);</script> ... (insgesamt 33 mal wiederholen)

Diese Anfrage wird nicht auf Angriffe überprüft, da sie von der Funktion convertFromRepetition einfach in x umgewandelt wird, bevor sie auf Angriffe untersucht wird. So kann das IDS natürlich keinen Angriff erkennen und die Anfrage wird unverändert an die Anwendung weitergeleitet und damit eine eventuell in der Anwendung vorhandene Cross-Site-Scripting-Schwachstelle ausgenutzt!

Selbverständlich kann man so auch SQL-Injection-Schwachstelle ausnutzen. Man braucht lediglich dafür zu sorgen, dass die Wiederholungen in einem Kommentar münden. Dann wird nur der erste Teil des Musters ausgewertet und die Wiederholungen von der Datenbank ignoriert, da sie sich ja innerhalb eines Kommentars befiden, also beispielsweise:

' union select password from mySQL.user limit 1 /*' union select password from mySQL.user limit 1 /*
... (insgesamt 33 mal wiederholen)

Auch Directory-Traversal-Angiffe funktionieren, sofern die Eingabe irgendwo in einem Nullterminierten String landet.

../../../etc/passwd%00../../../etc/passwd%00... (insgesamt 33 mal wiederholen)

Das erste Null-Teuchen sorgt dann dafür, dass alles, was dahinter kommt, ignoriert wird (siehe auch HTTP-Parameterverunreinigung, Teil 2).

Die Annahme, man könne keine Angriffe ausschließlich mit alphanumerischen Zeichen durchführen, ist falsch!

Folgende regel filtert alle Parameter aus, die keine Sonderzeichen enhalten:

        // define the pre-filter
        $prefilter = '/[^\w\s\/@!?\.]+|(?:\.\/)|(?:@@\w+)/';

        // to increase performance, only start detection if value
        // isn't alphanumeric

Die Annahme ist, dass ein erfolgreicher Angriff nicht ohne Sonderzeichen funktioniert, was prinzipiell falsch ist. Um eine SQL-Injection-Schwachstelle wie die folgende auszunutzen braucht man keine Sonderzeichen, wie eine Schwachstelle im IG-Shop beweist:

"select type_id from catalog_product where product_id = "$HTTP_GET_VARS['id']

Hier genügt die Anfrage…

http://localhost/compare_product.php?id=0 union select password from users limit 1

…um das erste Passwort auszulesen. Im Übrigens ist der Filter nicht ganz „dicht“, denn folgende Zeichen /@!?.\r\n werden problemlos durchgelassen.

Die Annahme, Benutzerdaten können nur mittels $_GET, $_POST ,$_COOKIE und $_REQUEST übergeben werden, ist ebenfalls falsch!

Neben den genannten Quellen vergaßen die Schöpfer von PHPIDS die Quelle $_SERVER zu berücksichtigen. Schließlich wird der Eintrag $_SERVER[‚PHP_SELF‘] gerne für Cross-Site-Scripting-Angriffe ausgenutzt, denn dieser Eintrga wird vom Browser gesetzt!
Gibt beispielsweise ein Skript diesen Wert ohne weitere Kodierung aus, beispielsweise um das aktuelle Skript als Formular-Aktion anzugeben…

  <form action="$_SERVER['PHP_SELF']" method ="post">

…kann der Pfad, den der Angreifer übergibt, ohne weiters wie folgt aussehen…

  http://localhost/contact/myform.php/"><script>alert(1);</script>

Das Skript übernimmt dann diesen Pfad und baut ihn ins Formular ein und das ohne dass PHPIDS etwas davon bemerkt.

Die Directory-Traversal-Schwachstelle in PHPIDS, die in dem Paper beschrieben wird, ist der aktuellen Version offenbar bereits behoben. Das Projekt hat offenbar kreative Tester als Mitglieder (siehe Projektforum), wodurch PHPIDS in Zukunft hoffentlich sicherer und Treffsicherer im Aufspüren und Abblocken von Angriffen wird. Leider liegt es in der Natur der Sache, dass man unsichere Webanwendungen mit dieser Technik nicht in allen Fällen zuverlässig schützen kann.

August 24, 2011

Das Innenleben von Webbrowsern

Filed under: Allgemein — sebastiankuebeck @ 06:54
Tags: , , , , , ,

Tali Garsiel hat jahrelang das Innenleben von Webbrowsern analysiert, hat über dieses Thema in dieser Zeit alle verfügbaren Veröffentlichungen gelesen und die Millionen Quellcodezeilen C++ von WebKit (die Basis von Safari) und Gecko (die Basis von Firefox) analysiert, aus denen diese Software letztlich besteht. Die Ergebnisse dieser Arbeit hat Sie im Artikel How Browsers Work: Behind the Scenes of Modern Web Browsers veröffentlicht.

Der Artikel ist im Gegensatz zu fast allem, was ich bisher über dieses Thema gelesen habe, äußerst verständlich geschrieben, sodass ihn auch Leser, die sich noch nie mit diesem Thema beschäftigt haben, ohne Probleme verstehen können. Ein besseres Verständnis sollte Programmierern helfen, Kodierungsprobleme, die zu Sicherheitsproblemen (Cross-Site Scripting Schwachstellen) führen können, künftig zu vermeiden.

August 23, 2011

Unbekannte Hackergruppe stiehlt 840.000 Kundendaten bei K&M – Elektronik

Filed under: Allgemein — sebastiankuebeck @ 14:54
Tags: , , , , , , ,

Die bisher unbekannte Hackergruppe oxxo berichtete Sonntag Mittag, dass sie 840.000 Kundendaten von der Homepage der K&M – Elektronik entwendet hätte. Offenbar wollen die Hacker diese Daten allerdings nicht veröffentlichen. Laut eigenen Angaben wollten die Hacker die betroffenen Unternehmen lediglich auf Schwachstellen in deren Webseiten aufmerksam machen, jedoch hätten die betroffenen Unternehmen entweder gar nicht reagiert oder mit rechtlichen Schritten gedroht. Also haben die Hacker beschlossen, jede Lücke zu veröffentlichen. Bei den Schwachstellen auf der Seite der K&M – Elektronik handelt es sich um eine SQL-Injection- und drei Cross-Site-Scripting-Schwachstellen.

Leider hört man in letzter Zeit immer öfter von frustrierten Leuten, die in guter Absicht Schwachstellen melden und dann ignoriert oder bedroht werden. Man sollte allerdings als Hacker nicht vergessen, dass die Leute, die sich in diesen Unternehmen mit solchen Meldungen befassen, in der Regel mit der Situation vollkommen überfordert sind. Es ist daher oft sinnvoller, diese Schwachstellen einem CERT in der nähe zu melden. Generell gilt jedoch, dass solche „Überprüfungen“ ohne Zustimmung des betroffenen Unternehmens illegal sind, auch dann, wenn man dem Unternehmen eigentlich helfen will.

Als betroffenes Unternehmen sollte man solche Meldungen auf jeden Fall ernst nehmen und dem Überbringer danken. Danach sollte man sich schleunigst an ein erfahrenes Sicherheitsunternehmen wenden und den Vorfall untersuchen lassen.
Man sollte dabei nicht vergessen, dass zahlreiche Hacker da draußen sind, die niemanden informieren sondern gleich großen Schaden anrichten. Den Einzelhändler TJX hat ein solcher Vorfall immerhin 256 Millionen Dollar gekostet.

August 10, 2011

Schwerwiegende Sicherheitslücke bei eBay

Filed under: Allgemein — sebastiankuebeck @ 11:29
Tags: , , , , ,

Account-Diebstahl durch schwerwiegende Sicherheitslücke bei eBay:

Durch eine schwere Sicherheitslücke bei eBay konnten Angreifer Cookies anderer Nutzer stehlen und somit die Kontrolle über fremde Accounts übernehmen. Auf einer Unterseite des Onlineauktionshauses wurde ein URL-Parameter nicht ausreichend überprüft und als Teil der Webseite wiedergegeben. Dadurch war Cross-Site Scripting (XSS) möglich. Angreifer konnten eBay.de-Links generieren, bei deren Aufruf beliebiger JavaScript-Code im Kontext der eBay-Domain ausgeführt wurde. Auf diese Weise war es möglich, das Cookie auszulesen und an einen fremden Server zu übermitteln.

Offenbar hatte eBay die Warnungen eines Sicherheitsexperten ignoriert, bis der sich an Heise Security wandte. Dann  reagierte eBay und nahm die betroffene Seite vom Netz.

Auf der US-Seite von eBay gibt es die Möglichkeit, Sicherheitslücken zu melden. Hinweise auf Sicherheitsprobleme nimmt eBay in englischer Sprache unter securitydisclosure(at)ebay.com entgegen.

August 2, 2011

60 Schwachstellenscanner für Webanwendungen im Vergleich

Filed under: Allgemein — sebastiankuebeck @ 12:35
Tags: , , , , , , ,

Shay Chen hat 12 komerszielle und 48 freie Schwachstellenscanner für Webanwendungen (oder Web Application Security Scanner – das sind Werkzeuge mit denen man Webanwendungen automatisiert auf Sicherheitsprobleme überprüfen kann) verglichen und die Ergebnisse in einem Blogeintrag veröffentlicht. Alle Kandidaten wurden mit dem Werkzeug WAVSEP (version 1.0.3) getestet, einem freien Werkzeug zum Evaluieren von Schwachstellenscannern. Dieses Werkzeug ist nichts anderes als eine präparierte Webanwendung mit versteckten Schwachstellen. Folgende Schwachstellen mussten die Kandidaten erkennen:

  1. 66 Cross-Site-Scriping-Schwachstellen;
  2. 80 SQL-Injection-Schwachstellen, die sich anhand der Fehlermeldungen der Webapplikation zu erkennen geben – beispielsweise durch Ausgabe einer SQLException mit oder ohne Stack-Trace;
  3. 46 Blind-SQL-Injection-Schwachstellen;
  4. 10 Blind-SQL-Injection-Schwachstellen, die man nur mithilfe einer Timing-Attacke eindeutig identifizieren und ausnutzen kann;
  5. 7 Kategorien Falsch-Positive für Cross-Site-Scriping und 10 für SQL-Injection. Dabei verhält sich die Anwendung so, als wäre sie verwundbar, obwohl sie das in Wirklichkeit gar nicht ist.

Um ganz sicher zu gehen testete Shay Chen die Scanner noch gegen eine selbstentwickelte, verwundbare Webanwendung mit dem vorläufigen Namen „bullshit“.

Ergebnisse für die Erkennung von SQL-Injection-Schwachstellen

Die Ergebnisse für die Erkennung von SQL-Injection-Schwachstellen zeigen, dass die freien Werkzeuge Wapiti und arachni eine etwas bessere Erkennungsrate für diese Art Schwachstellen haben als der erste kommerzielle Verfolger Netsparker (das Ergebnis von arachni ist aber in Wirklichkeit besser als das von Wapiti, da arachni Falsch-Positive etwas besser erkennt):

Testergebnisse für die Erkennung von SQL-Injection-Schwachstellen. Blaue Balken zeigen gefundene Schwachstellen während der rote die Anzahl der Falsch-Positiv-Kategorien anzeigt, die vom jeweiligen Scanner erkannt wurden. Ein größerer Roter Balken ist also schlecht und daher stimmt die Reihenfolge auch nicht ganz.

Ergebnisse für die Erkennung von Cross-Site-Scripting-Schwachstellen

Bei der Erkennung von Croos-Site-Scripting-Schwachstellen hat hingegen IBM’s Rational AppScan knapp die Nase vor dem freien arachni da es Falsch-Positive deutlich besser erkennt, während wapiti mit knapp 17% erkannten Schwachstellen in dieser Disziplin weit zurückfällt.

Testergebnisse für die Erkennung von SQL-Injection-Schwachstellen.

Abschließende Bemerkungen

Wie bereits angedeutet gibt es Probleme mit der Gewichtung der Falsch-Positiven, weshalb das Ranking der Scanner mit etwas Vorsicht zu genießen ist – ein Werkzeug, dass in jedem Fall eine Schwachstelle meldet hat schließlich auch eine Erkennungsrate von 100%, also ist die Erkennung von Falsch-Positiven für die Qualität eines Scanners entscheidend.  So könnte man durchaus argumentieren, dass ParosPro und Netsparker Cross-Site-Scripting-Schwachstellen besser erkennen, da sie nicht auf Falsch-Positive hereinfallen.

Auch gibt es große Unterschiede zwischen den Produkten was die Ausstattung und die Bedienungsfreundlichkeit betrifft. So sind viele freie Werkzeuge oft nur für fortgeschrittene Tester zu bedienen währen die meisten kommerziellen auch von weniger erfahrenen Testern bedient werden können. All dass gilt es zu berücksichtigen, wenn man einen oder mehrere Schwachstellenscanner verwendet – egal ob frei oder kommerziell.

Die Werkzeuge Priamos und VulnerabilityScanner wurden übrigens nicht getestet, da es nach Shay Chen Anzeichen gibt, dass in die Webseiten, auf denen diese Werkzeuge angeboten werden, eingebrochen wurde, wodurch diese Werkzeuge möglicherweise mit Schadcode infiziert sein könnten.

Juli 27, 2011

Nun auch Cross-Site-Scripting-Schwachstelle in ICQ

Filed under: Allgemein — sebastiankuebeck @ 10:48
Tags: , , , ,

Nun wurde eine ähnliche Cross-Site-Scripting-Schwachstelle in ICQ entdeckt, wie sie bereits in Skype nachgewiesen wurde. Benutzer können auch hier JavaScript-Code in ihr Profil einfügen und da dieser im Client beim Anzeigen des Profils nicht richtig kodiert wird,  wird er ausgeführt und das offenbar im lokalen Kontext. Das heißt, dass es Angreifern so prinzipiell sogar möglich ist, fremden Code auf dem Rechner des Opfers auszuführen.

Ausnützen der Cross-Site-Scripting-Schwachstelle im ICQ-Client. Quelle: heise Security

Schützen kann man sich vor dieser Art Angriff nicht. Sobald man sich das Profil ansieht, ist es auch schon passiert. Man kann das Risiko reduzieren, indem man sich keine Profile von unbekannten Leuten ansieht, bis ICQ das Problem behebt.

Juli 17, 2011

Cross-Site-Scripting-Schwachstelle in Skype entdeckt

Filed under: Allgemein — sebastiankuebeck @ 12:53
Tags: , , , , ,

Wie es aussieht kann man bei Skype JavaScript-Code in das Benutzerprofil einschleusen (siehe Public Security Advisory). Dieser Code wird dann im Browser aller jener Benutzer ausgeführt, die ein derart präpariertes Skype-Profil angezeigt bekommen. Die Ursache dafür ist, dass Skype die Profildaten beim Anzeigen nicht richtig kodiert. So kann ein Angreifer alles, was der legitime Benutzer zu sehen bekommt, manipulieren und so allerlei Unfug anstellen wie beispielsweise Nachrichten im Namen des Benutzers verschicken. Im schlimmsten Fall könnte man – so die Entdecker – auch Schadcode auf dem Rechner des Opfers einschleusen. Diese Art Schwachstelle wird Cross-Site-Scripting-Schwachstelle (sie werden oft mit XSS abgekürzt) genannt, sie ist seit vielen Jahren bekannt und gehören zur Zeit zur zweithäufigsten Art von Schwachstellen in Webanwendungen (siehe die aktuelle WASC-Statistik) – deshalb habe ich ihr ein umfangreiches Kapitel in meinem Buch gewidmet.

Schützen kann man sich dagegen leider nicht, man muss also warten, bis Skype das Problem durch ein Update korrigiert, allerdings funktioniert ein Angriff – so ein Blog-Post von Adrian Asher von Skype – nur, wenn man den Benutzer mit dem manipulierten Profil als Kontakt bestätigt hat. Es empfiehlt sich daher, neue Kontakte sorgfältig zu prüfen (beispielsweise durch einen Anruf) bevor man sie bestätigt.

Cross-Site-Scripting-Schwachstellen im Zusammenhang mit Benutzerprofilen wurden in den letzten Jahren unter anderem auf Twitter und Facebook festgestellt und ausgenützt, daher ist wirklich traurig, dass Skype nichts aus diesen Vorfällen gelernt hat. Das folgende Video demonstriert, wie man diese Schwachstelle ausnutzen kann:

Nächste Seite »

Bloggen auf WordPress.com.