scip ag

Transcrição

scip ag

scip ag
Contents
1.
Editorial
2.
scip AG Informationen
3.
Neue Sicherheitslücken
4.
Statistiken Verletzbarkeiten
5.
Labs
6.
Bilderrätsel
7.
Impressum
1.
Editorial
Falsche Akzeptanz eines möglichen Schutzes
scip monthly Security Summary 19.11.2009
Ich fahre täglich mit Bus, Bahn und Tram zur
Arbeit. Pro Arbeitsweg sitze ich knapp 45
Minuten in einem öffentlichen Verkehrsmittel.
Früher habe ich stets gelesen. Da kommen pro
Woche einige hundert Lesestunden zusammen.
Mittlerweile mag ich aber nicht immer lesen. Vor
allem am Abend bin ich zu müde, um abgesehen
von einer seichten Tageszeitung meine Nase
noch in ein technisches Buch oder einen
Klassiker der Literatur zu stecken.
Aus diesem Grund schaue ich unterwegs
meistens Filme, Serien oder Dokumentationen.
Bei längeren Reisen gerne auf meiner Sony PSP,
die
mit
einem
guten
Bildschirm
und
ausgezeichneter Akkulaufzeit überzeugen kann.
Seitdem ich jedoch ein iPhone besitze, bin ich
etwas faul darin geworden, ein zusätzliches
Gadget mit mir herumzuschleppen, so dass ich
die meisten Filme auf dem Handy schaue. (Oder
halt eben doch die neuesten Meldungen aus den
RSS/Twitter-Feeds auf durchgehe.)
Unter anderem habe ich den Video Podcast der
Wissenssendung "Galileo" von Pro7 abonniert. In
diesem werden in jeweils 15-minütigen Berichten
spezifische Themen behandelt. Einer der
Beiträge setzte sich mit "Sicherheitsprodukten"
auseinander. Dort wurden dann eine HandyOrtungs-Software, ein mit FingerabdruckScanner geschützter USB-Stick, eine auf Infrarot-
Schranken basierende Alarmanlage sowie ein
auf einem Lichtsensor basierende Alarmanlage
für Schubladen getestet.
Der dafür zuständige "Sicherheitsexperte" agierte
meines Erachtens jedoch ungeschickt, ja in allen
Fällen gar extrem unsystematisch. Obwohl dies
wohl auch grösstenteils mit dem Format des
Podcasts zusammenhängt, möchte ich dies zum
Anlass nehmen, um ein konkretes Problem von
Sicherheitsüberprüfungen zu illustrieren.
Der besprochene USB-Stick wies einen kleinen
Fingerabdruck-Scanner auf. Erst durch die
Authentisierung auf biometrischer Ebene sollte
der Zugriff auf die Daten durchgeführt werden
können. Das Test-Szenario eines Angriffs
bestand nun darin, dass der Stick entwendet und
am Rechner des Diebs ausprobiert werden
würde. Da sich dieser mit seinem eigenen
Fingerabdruck nicht authentisieren konnte, wurde
das Produkt als "sicher" eingestuft.
Wahrlich vermag der Fingerabdruck-Scanner vor
unerlaubten Zugriffen schützen. Doch nur vor
unerlaubten Zugriffen, die über den legitimen und
damit erwarteten Zugriffsweg geschehen wollen.
Der USB-Stick legt die Daten in verschlüsselter
Form ab und erst durch das Einlesen des
Fingerabdrucks findet eine Entschlüsselung des
Vaults statt. Dies geschieht durch eine zusätzlich
auf dem Rechner installierte Applikation. Der
Vault und damit die chiffrierten Daten sind jedoch
immer vorhanden. Der Angreifer kann also auf
anderen Wegen versuchen, an diese zu
kommen, ohne den Prozess der biometrischen
Authentisierung durchlaufen zu müssen.
Je nach eingesetzter Verschlüsselung liesse sich
diese selbst angreifen. Gerade proprietäre
Mechanismen neigen zu schwerwiegenden
Fehlern, die ein erfahrener Kryptologe eruieren
kann. Spätestens mit einer Chosen-PlaintextAttacke liesse sich das Grundprinzip des
Mechanismus bestimmen und mit diesem die
möglichen Angriffspunkte.
Ich selbst würde jedoch einen anderen Weg
bevorzugen. Ich gehe davon aus, dass eine
halbwegs intelligente Lösung den OriginalFingerabdruck nicht speichert, sondern mit einem
Einweg-Mechanismus die Korrektheit dessen
feststellt: Das Einlesen des Fingerabdrucks wird
1/15
s c i p
a g
© scip AG
voraussichtlich einen Bitstream generieren, der
als "Passwort" verwendet wird. Dieser Bitstream
wird dann in einem Prozess einer klassischen
Entschlüsselung auf die Daten des Vaults
angewendet. Durch eine stupide BruteforceAttacke liessen sich nun alle Varianten dieses
Bitstreams generieren und damit auch ohne den
dazugehörigen
Finger
die
Originaldaten
wiederherstellen.
Der Aufwand und mit ihm der Erfolg dieser
Angriffstechnik ist massgeblich von der
Komplexität der als Passwort verwendeten
Bitstreams abhängig. Durch API Call Interception
liessen
sich
die
Bitstreams
eines
Authentisierungsversuchs mitlesen und dadurch
die Komplexität ableiten (oder durch ein
Deadlisting der jeweiligen Codeteile). Da der
Hersteller des Produkts voraussichtlich stark
darauf bedacht ist, dass nicht versehentlich zwei
unterschiedliche Fingerabdrücke den gleichen
Bitstream generieren, werden wohl eine hohe
Anzahl an Prüfpunkten und damit ein langer
Bitstream verwendet werden.
Das Problem hierbei ist, dass nur selten
Bitstreams variabler Länge zum Einsatz
kommen. Wird also stets eine 16 Bit lange
Zeichenkette eingesetzt, so kommen nur 65'536
= 2^16 Varianten zum Einsatz (ebenso viele
unterschiedliche Fingerabdrücke könnten erkannt
werden). Eine Bruteforce-Attacke auf einen solch
begrenzen Schlüsselraum ist überschaubar und
wird in wirtschaftlich vertretbarer Zeit zum Ziel
führen. Die Sicherheit eines durch einen
Fingerabdruck geschützten USB-Sticks ist also
nicht zwingend von der Verfügbarkeit des
richtigen Fingers abhängig. Viel mehr gibt es
auch noch andere Angriffsflächen, die das
biometrische Merkmal als solches gänzlich
vernachlässigen lassen. Dann wird das Ganze zu
einem klassischen Angriff, der nur noch mit Bits
und Mathematik zu tun hat.
Marc Ruef <maru-at-scip.ch>
Security Consultant
Zürich, 12. Oktober 2009
2.
scip AG Informationen
2.1 Source Code Analysis
Das Ziel unserer Dienstleistung Source Code
Analysis ist die Identifikation ineffizienter und
fehlerhafter Codebereiche sowie die Definierung
der Tragweite dadurch möglicher erfolgreicher
Attacken durch Angreifer oder allfälliger Stabilitätsprobleme.
Der Kunde stellt uns den unkompilierten und
nach Möglichkeiten dokumentierten Quelltext der
zu untersuchenden Applikation zur Verfügung.
Die optionale Abgabe eines Handbuchs sowie ein
Code Walkthrough durch die Entwickler helfen
dabei, das Produkt zu verstehen.




Kritische Funktionen finden: Identifizieren
problematischer und fehlerhafter Funktionen
(z.B. strcpy() in C/C++ oder file() in PHP).
Programmflussanalyse: Bestimmen des Programmablaufs anhand der Conditionals und
genutzter Prädikatenlogik.
Datenpfadanalyse: Verfolgen der Datenverarbeitung von Eingaben/Ausgaben, Variablen
und Konstanten im Programm.
Slicing: Eingrenzung affektierter und tangierter Codeteile zur Reduzierung der determinierten Probleme.
Die Source Code Analysis (SCA) gilt als akademisch mächtigstes und wirtschaftlich effizientestes Werkzeug zur Identifikation von Schwachstellen in einer Software-Lösung. Sehr schnell und
akkurat können etwaige Fehlerquellen in Anwendungen ausgemacht und die Tragweite derer
bestimmt werden. Aus diesem Grund werden
Quelltext-Analysen je länger je mehr komplementär zu einem Application Penetration Test eingesetzt.
Dank unserer langjährigen Erfahrung und unserem ausgewiesenen Expertenwissen haben wir
als scip AG bereits eine Vielzahl von Source
Code Analysen Projekte durchgeführt.
Zählen auch Sie auf uns!
http://www.scip.ch/?firma.referenzenalle
Zögern Sie nicht und kontaktieren Sie unseren
Herrn Chris Widmer unter der Telefonnummer
+41 44 404 13 13 oder senden Sie im eine Mail
an [email protected].
2/15
s c i p
a g
© scip AG
3.
Neue Sicherheitslücken
Die erweiterte Auflistung hier besprochener Schwachstellen sowie weitere
Sicherheitslücken sind unentgeltlich in
unserer
Datenbank
unter
http://www.scip.ch/?vuldb einsehbar.
Die Dienstleistungspakete)scip( pallas
liefern Ihnen jene Informationen, die
genau für Ihre Systeme relevant sind.
Expertenmeinung:
Auch wenn derzeit kein öffentliches Exploit zur
Verfügung steht, so ist diese Schwachstelle
tendentiell eher als kritisch zu betrachten, zumal
hier Code im Kernel Mode zur Ausführung
gebracht werden kann, was in einem gezielten
Angriff
nahezu
in
jedem
Fall
zur
Kompromittierung des Systems führen dürfte.
Das zeitnahe Einspielen des entsprechenden
Patches ist angeraten.
16
14
12
10
8
6
4
2
0
Okt 09
Nov 09
sehr kritisch
3
1
kritisch
15
3
problematisch
3
2
Contents:
4060
4059
4058
4057
4056
4054
4053
4052
Microsoft Windows Win32k KernelMode Driver mehrere Schwachstellen
Apple Mac OS X mehrere
Schwachstellen
Microsoft Windows Active Directory
Denial of Service
Microsoft Excel verschiedene
Schwachstellen
Microsoft Office Word File Information
Block Parsing Pufferüberlauf
Wireshark verschiedene Denial of
Service Schwachstellen
VMware verschiedene Produkte Host
Privilege Escalation
Mozilla Firefox mehrere Schwachstellen
3.1 Microsoft Windows Win32k KernelMode Driver mehrere
Schwachstellen
Risiko:
Remote:
Datum:
scip DB:
Entwicklungszweig zu Gunsten der Windows-NTProduktlinie
aufgegeben
und
Windows
bezeichnet das Betriebssystem als Ganzes.
Tavis Ormandy des Google Security Teams
identifizierte verschiedene Schwachstelle in der
Datei win32k.sys, die beim Parsen von FontCode ausgelöst wird. Dadurch kann im Kernel
Mode beliebiger Code zur Ausführung gebracht
werden, was die Kompromittierung des Systems
zur Folge haben kann.
kritisch
Ja
10.11.2009
http://www.scip.ch/?vuldb.4060
Microsoft Windows ist ein Markenname für
Betriebssysteme des Unternehmens Microsoft.
Ursprünglich war Microsoft Windows eine
grafische Erweiterung des Betriebssystems MSDOS (wie beispielsweise auch GEM oder
PC/GEOS),
inzwischen
wurde
dieser
3.2 Apple Mac OS X mehrere
Schwachstellen
Risiko:
Remote:
Datum:
scip DB:
problematisch
Ja
10.11.2009
Mac OS X ist eine proprietäre Darwin-Distribution
des Unternehmens Apple und setzt die
Produktlinie Mac OS als Betriebssystem der
hauseigenen Macintosh-Computer fort. In einem
kumulativen
Patchpaket
adressiert
Apple
insgesamt 37 Schwachstellen in verschiedenen
Applikationen und Betriebssystemkomponenten.
Expertenmeinung:
Mit gut drei Dutzend Patches ist dieser
kumulative Patch diesen Monat klar der
Spitzenreiter, was ganze Ansammlungen von
Updates angeht. Auch hier gilt: Die Installation
dieser
Patches
ist
aufgrund
der
zugrundeliegenden, oft eher kritisch veranlagten
Sicherheitsprobleme, stark empfohlen und sollte
zeitnah durchgeführt werden.
3.3 Microsoft Windows Active Directory
Denial of Service
Risiko:
Remote:
Datum:
scip DB:
kritisch
Ja
10.11.2009
Microsoft Windows ist ein Markenname für
Betriebssysteme des Unternehmens Microsoft.
Ursprünglich war Microsoft Windows eine
grafische Erweiterung des Betriebssystems MS-
3/15
s c i p
a g
© scip AG
DOS (wie beispielsweise auch GEM oder
PC/GEOS),
inzwischen
wurde
dieser
Entwicklungszweig zu Gunsten der Windows-NTProduktlinie
aufgegeben
und
Windows
bezeichnet das Betriebssystem als Ganzes.
Durch einen Fehler im Active Directory, Active
Directory Application Mode (ADAM) und im
Active Directory Lightweight Directory Service
(AD LDS) kann ein Angreifer einen Denial of
Service verursachen.
Expertenmeinung:
Active Directory Systeme nehmen in Windows
Netzwerken einen essentiellen Platz ein und sind
daher als sensitiv zu betrachten. Aus diesem
Grund ist diese Schwachstelle grundsätzlich als
kritisch zu betrachten und sollte zeitnah
adressiert werden.
3.4 Microsoft Excel verschiedene
Schwachstellen
Risiko:
Remote:
Datum:
scip DB:
kritisch
Ja
10.11.2009
Microsoft
Excel
ist
ein
Tabellenkalkulationsprogramm. Es ist heute die
meistverbreitete Software für Tabellenkalkulation.
Excel gehört zur Microsoft-Office-Suite und ist
sowohl für Microsoft Windows als auch für Mac
OS verfügbar. Excel entstand als Nachfolger von
Microsoft Multiplan. Die aktuell verfügbare
Version ist für Windows Microsoft Excel 2007
(seit 30. November 2006 für Firmenkunden bzw.
seit 30. Januar 2007 für Privatkunden) sowie für
Mac OS Microsoft Excel 2008 (seit Januar 2008).
In einem Advisory beschreibt Hersteller Microsoft
insgesamt acht Schwachstellen, deren mögliche
Implikationen meistens einen Pufferüberlauf
enthalten.
Expertenmeinung:
Insgesamt acht Schwachstelle fixt Microsoft mit
diesem kumulativen Update und eliminiert damit
eine Vielzahl von Schwachstellen. Anwender und
Admininstratoren sollten zeitnah um die
Verteilung dieses Updates auf allen relevanten
Systemen bemüht sein.
3.5 Microsoft Office Word File
Information Block Parsing
Pufferüberlauf
Risiko:
Remote:
Datum:
scip DB:
sehr kritisch
Ja
10.11.2009
Microsoft Word (oft auch kurz MS Word oder
Word
genannt)
ist
ein
Textverarbeitungsprogramm der Firma Microsoft
für die Windows-Betriebssysteme und Mac OS.
Es ist Teil der Office-Suite Microsoft Office sowie
der auf
private Nutzer zugeschnittenen
Programmsammlung Microsoft Works Suite, wird
aber auch einzeln verkauft. Jun Mao fand eine
Schwachstelle in aktuellen Word Versionen, bei
denen durch einen Missbrauch des FIB (File
Information Block) in einem manipulierten Word
Dokument durch einen Stack Overflow beliebiger
Code zur Ausführung gebracht wird.
Expertenmeinung:
Die vorliegende Schwachstelle ist als kritisch zu
betrachten und dürfte in kürze auch landläufig
ausgenutzt werden. Verwundbare Installation
sollten daher binnen kürzest möglicher Zeit auf
einen aktuellen Stand gebracht werden.
3.6 Wireshark verschiedene Denial of
Service Schwachstellen
Risiko:
Remote:
Datum:
scip DB:
problematisch
Ja
28.10.2009
Wireshark (engl. „wire“: Draht, Kabel; „shark“:
Hai; alte Bezeichnung: Ethereal) ist ein freies
Programm
zur
Analyse
von
NetzwerkKommunikationsverbindungen.
In
einem
aktuellen Advisory beschreibt der Hersteller
verschiedene Möglichkeiten, einen Denial of
Service durch verschiedene Schwachstellen
herbeizuführen.
Expertenmeinung:
Auch hier handelt es sich lediglich um eine relativ
unkritische Schwachstelle. Anwender sollten
dennoch zeitnah eine neue Version einsetzen,
sofern möglich.
3.7 VMware verschiedene Produkte
Host Privilege Escalation
Risiko:
Remote:
Datum:
scip DB:
problematisch
Ja
28.10.2009
VMware, Inc., ist ein US-amerikanisches
Unternehmen, das Software im Bereich der
Virtualisierung entwickelt. Das Unternehmen
wurde 1998 mit dem Ziel gegründet, eine Technik
zu entwickeln, virtuelle Maschinen auf StandardComputern zur Anwendung zu bringen. Das
bekannteste Produkt ist VMware Workstation.
Durch einen Fehler in aktuellen Versionen
4/15
s c i p
a g
© scip AG
verschiedene VMware Produkte kann ein
Angreifer erweiterte Rechte innerhalb einer
VMware Instanz erhalten.
Expertenmeinung:
Während der vorliegende Fehler nicht als kritisch
zu betrachten ist, sollten betroffene Systeme
dennoch zeitnah durch das Einspielen der
entsprechenden Patches auf einen aktuellen
Stand gebracht werden.
3.8 Mozilla Firefox mehrere
Schwachstellen
Risiko:
Remote:
Datum:
scip DB:
kritisch
Ja
29.10.2009
Mozilla
Firefox
(amerikanisch-englische
Aussprache) ist ein freier Webbrowser des
Mozilla-Projekts. Der seit Mitte 2002 entwickelte
Open-Source-Webbrowser bietet die Möglichkeit,
eine breite Palette an Erweiterungen zu
implementieren. Firefox ist nach dem Internet
Explorer der am zweithäufigsten genutzte
Webbrowser. Ein Patch des Herstellers schliesst
rund 15 Schwachstellen, deren Auswirkungen
teilweise unbekannt. Diverse Schwachstellen
erlauben erwiesenermassen die Ausführung
beliebigen Programmcodes im Kontext der
Applikation.
Expertenmeinung:
Insgesamt 15 Schwachstelle fixt das Mozilla
Projekt mit dem neusten Release 3.5.4 und
eliminiert damit eine Vielzahl von Schwachstellen,
die teilweise in junger Vergangenheit besprochen
wurden. Anwender und Admininstratoren sollten
zeitnah um die Verteilung dieses Updates auf
allen relevanten Systemen bemüht sein.
5/15
s c i p
a g
© scip AG
4.
Statistiken Verletzbarkeiten
900
Die im Anschluss aufgeführten Statistiken basieren auf den Daten der
deutschsprachige
Verletzbarkeitsdatenbank der scip AG.
800
700
600
http://www.scip.ch/?vuldb
500
Zögern Sie nicht uns zu kontaktieren. Falls Sie
spezifische Statistiken aus unserer Verletzbarkeitsdatenbank wünschen so senden Sie uns
eine E-Mail an mailto:[email protected]. Gerne nehmen wir Ihre Vorschläge entgegen.
400
300
200
Auswertungsdatum:
19. November 2009
100
0
2003
2004
2005
2006
2007
2008
2009
sehr kritisch
56
15
15
6
11
11
18
kritisch
214
314
402
442
229
140
66
problematisch
170
287
423
396
419
176
66
Verlauf der Anzahl Schwachstellen pro Jahr
20
25
18
16
20
14
12
15
10
8
10
6
4
5
2
0
0
2009 - Sep
sehr kritisch
2009 - Okt
2009 - Nov
3
1
2009 - Okt
2009 - Nov
3
1
1
2
2
5
18
1
Denial of Service (DoS)
Designfehler
Directory Traversal
kritisch
5
15
3
Eingabeungültigkeit
problematisch
6
3
2
Fehlende
Authentifizierung
Verlauf der letzten drei Monate Schwachstelle/Schweregrad
2009 - Sep
Cross Site Scripting
(XSS)
Fehlende
Verschlüsselung
Fehlerhafte Leserechte
Fehlerhafte
Schreibrechte
Format String
Konfigurationsfehler
Pufferüberlauf
Race-Condition
4
1
Schw ache
Authentifizierung
Schw ache
Verschlüsselung
Verlauf der letzten drei Monate Schwachstelle/Kategorie
6/15
s c i p
a g
© scip AG
Registrierte Schwachstellen by scip AG
25
21
20
17
16
15
16
15
13
12
11
11
11
10
6
2009 - Dez
2009 - Okt
2009 - Sep
2009 - Aug
2009 - Jul
2009 - Jun
2009 - Mai
2009 - Apr
2009 - Mrz
2009 - Feb
2009 - Jan
0
2009 - Nov
5
Verlauf der Anzahl Schwachstellen pro Monat - Zeitperiode 2009
25
20
15
10
5
0
2009 - Jan 2009 - Feb 2009 - Mrz 2009 - Apr 2009 - Mai 2009 - Jun 2009 - Jul 2009 - Aug 2009 - Sep 2009 - Okt 2009 - Nov 2009 - Dez
6
2
3
1
kritisch
9
1
4
1
4
7
10
3
5
5
15
3
problematisch
6
11
11
7
7
3
3
6
6
3
2
sehr kritisch
5
Verlauf der Anzahl Schwachstellen/Schweregrad pro Monat - Zeitperiode 2009
7/15
s c i p
a g
© scip AG
20
18
16
14
12
10
8
6
4
2
0
2009 - Jan 2009 - Feb 2009 - Mrz 2009 - Apr 2009 - Mai 2009 - Jun 2009 - Jul
Cross Site Scripting (XSS)
2
2
2
8
Designfehler
1
2
2
4
1
2009 Aug
2
2
1
12
12
2009 - Sep 2009 - Okt 2009 - Nov 2009 - Dez
1
1
3
1
3
2
2
5
5
18
1
Directory Traversal
1
1
Fehlende Authentifizierung
Fehlende Verschlüsselung
Fehlerhafte Schreibrechte
Format String
Pufferüberlauf
9
5
4
6
8
4
1
Race-Condition
1
Schw ache Authentifizierung
Schw ache Verschlüsselung
SQL-Injection
Symlink-Schw achstelle
2
Umgehungs-Angriff
Unbekannt
1
1
1
5
1
1
2
Verlauf der Anzahl Schwachstellen/Kategorie pro Monat - Zeitperiode 2009
8/15
s c i p
a g
© scip AG
Registrierte Schwachstellen by scip AG
120
111
103
100
98
94
85
83
80
80
77
79
76
70
70
70
62
60
62
55
77
71
68
65
68
55
54
51
48 47
44
5152
49
40
77
52
45
42
40
32
27
27
30
2726
23
20
37
35
26
23
20
21
1716
1516
13
12
111111
7
6
2009 - Nov
2009 - Sep
2009 - Jul
2009 - Mai
2009 - Mrz
2009 - Jan
2008 - Nov
2008 - Sep
2008 - Jul
2008 - Mai
2008 - Mrz
2008 - Jan
2007 - Nov
2007 - Sep
2007 - Jul
2007 - Mai
2007 - Mrz
2007 - Jan
2006 - Nov
2006 - Sep
2006 - Jul
2006 - Mai
2006 - Jan
2006 - Mrz
2005 - Nov
2005 - Jul
2005 - Sep
2005 - Mai
2005 - Jan
2005 - Mrz
0
Verlauf der Anzahl Schwachstellen pro Monat seit Januar2005
120
100
80
60
40
20
0
sehr kritisch
kritisch
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
05 05 05 05 05 05 05 05 05 05 05 05 06 06 06 06 06 06 06 06 06 06 06 06 07 07 07 07 07 07 07 07 07 07 07 07 08 08 08 08 08 08 08 08 08 08 08 08 09 09 09 09 09 09 09 09 09 09 09
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1
2
1
1
1
2
1
25 33 38 58 47 20 46 20 26 42 37 10 30 38 27 37 33 44 41 42 52 27 27 43 49 23 9 15 24 14 18 11 15 15 17 19 10 20 13 31 4
1
2
2
2
3
1
2
1
1
1
1
1
1
1
1
1
2
1
2
1
4
1
1
1
7
8 12 7
6
4 18 9
4
problematisch 51 49 32 51 56 18 46 26 28 26 24 16 48 13 25 32 44 35 21 42 24 38 40 34 49 47 16 36 31 34 25 36 39 51 34 22 31 11 9
1
6
2
4
7 10 3
5
5 15 3
7
6
6
4 22 17 28 7 19 16 3 10 6 11 11 7
5
3
3
3
3
1
2
Verlauf der Anzahl Schwachstellen/Schweregrad pro Monat seit Januar 2005
9/15
s c i p
a g
© scip AG
50
45
40
35
30
25
20
15
10
5
0
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Cross Site Scripting (XSS)
1 3 1 20 3 2 10 4 5 6 5 1 3 4 3 6 3 8 6 4 6 3 2 2 7 2 2 3 4 6 4 7 11 8 5 11 4 1 3 2 3 1 5 1 1 2 1 1 2 2
15 6 12 19 30 6 25 4 12 15 24 4 25 10 10 9 12 14 13 16 20 24 15 21 32 11 10 11 14 4 5 5 8 12 7 3 9 3 1 1 6 3 6 3 3
Designfehler
29 44 16 30 36 14 15 18 12 13 12 7 15 12 12 27 23 13 14 19 7 12 19 11 7 3 1 1
2 1 1 2
Directory Traversal
1
1
Fehlende Authentifizierung
1
2 1
1 2
1 1 1
2
2
1
1 2 4 2 1
6
1 2
Fehlerhafte Schreibrechte
1 2 2 1
1
Format String
2
3 2 1 1
1
4 1
2
2 1
3
2
2 1 1
1
2
1
6 1
2
1
3
1 2
4
1 2
2 2
1 1
3 1
1
Fehlende Verschlüsselung
1 1 3
1
8 1 7
6 3 6 10 2 3 1 2
1
2 2
8 4 1 2 1
2
1
1 3 1 1
3 2 2
1
11 4
3 3 3
6 2 4
2 1
1 1 1 2 1
1 1
1
1 3
4
2 3
2 1
3 1 1 1 1 1
3 1 1 1
1 1 3 1 2
1
1
1
3 1
2
4 1 2
1
3 4 1 7 6
1 2
6 3
1 3
1
1 1
1
1
1
1
1
1
2 1
1
1
Pufferüberlauf
19 14 20 26 22 6 14 15 16 19 12 8 18 17 13 17 20 20 17 19 27 12 17 23 24 24 4 19 27 20 24 24 16 28 23 17 18 16 10 25 10 14 12 13 14 15 4 26 9 5 4 6 12 12 8 5 5 18 4
Race-Condition
2 2 3 3
Schw ache Authentifizierung 1
Schw ache Verschlüsselung 1
1
SQL-Injection
1
1 1
Symlink-Schw achstelle
1
5
1
1
1 6 2 2
2
1 1
2
2
1
1 1
Umgehungs-Angriff
5
Unbekannt
1 8 7 2 2 2 6
1
1 1 1
1 1 2 2 4 1
1 1
2 2 1 1 2
1 1 1 1
1 1 1 1
1 2
2 1 1
4 1 4 2
1 1
1
1 1 1 1
1 1
1
1
1
1
1
1
1
1
2 1
3 4
1
1
1
1
1
2 1 3
2
1 2 2
1
1
3
1 5 1 1 3
2
4 3 4 2 4 2 2 4 2 4
1 6 1 1 5 2 4 1 5 7 4 10 4 6 6 7 11 5 1 3 2 2
3 1 3 4 2 2 3
3
1 1 1
1 2
1
2
1 1 1 1 5 1
1 2
Verlauf der Anzahl Schwachstellen/Kategorie pro Monat seit Januar 2005
10/15
s c i p
a g
© scip AG
5.
Labs
Auf
der
scip
Labs
Webseite
(http://www.scip.ch/?labs.archiv) werden regelmässig Neuigkeiten und Forschungsberichte
veröffentlicht.
5.1 Grundlegende Javascript Malware
Analyse: Ein Beispiel
27.10.2009, Stefan Friedli, [email protected]
Für die Sicherheit der eigenen Web Applikation
zu sorgen, ist die Verantwortung jedes Webseitenbetreibers. Doch wird eine Seite kompromittiert, so muss adäquat reagiert werden. Gerade
wenn eine Webpräsenz dazu missbraucht wird,
deren Benutzer mit Schadsoftware oder Exploits
zu attackieren, ist eine Klärung der Umstände
unabdinglich, um eine professionelle Reaktion zu
gewährleisten und den schier unabwendbaren
Reputationsschaden möglichst gering zu halten.
Wie soll man jedoch im Detail herausfinden, was
der auf der eigenen Seite befindliche Schadcode
tut und dies auch noch in einer nachvollziehbaren
und sicheren Weise? Der Ansatz, der hier in der
Regel gewählt wird, ist eine strukturierte Analyse
des Schadcodes, den ich im Folgenden an einem
konkreten Beispiel erklären möchte.
Schritt 1: Re-Formatierung
Was im ersten Moment verwirrend aussieht, entsteht in erster Linie durch die (bewusste) Abwesenheit sämtlicher, der Übersicht dienlichen
Massnahmen der Codeformatierungen, wie zum
Beispiel Zeilenumbrüche oder Einrückungen von
Codeblöcken. Javascript schert sich herzlich
wenig um diesen Mangel an Sauberkeit, wir dagegen schon. Allerdings geht es dabei nicht um
die Ästhetik, sondern die logische Verteilung des
Codes auf einzelne, klar identifizierbare Linien.
Das erleichtert das exakte Setzen der
Breakpoints später enorm und erleichtert natürlich das Lesen des Codes.
Achtung: Es handelt sich hierbei um einen realen Fall mit realem Schadcode der unter Umständen ebenso realen Schaden auf Ihrem System anrichten kann. Bitte besuchen Sie die genannten URIs nicht und betrachten Sie sämtliche
Scripts ausschliesslich in einem Texteditor und
Rhino, nicht in einem Webbrowser. Es besteht
kein Haftungsanspruch.
Ausgangslage
Es wurde beobachtet, dass die Datei counter.js
von einem Server mit russischer Domänenendung überdurchschnittlich oft in eine kompromittierte Seite eingebunden wird – teils mehrmals
auf der selben Seite (Danke an Andreas für den
Hinweis). Alle Dateien, die im Rahmen dieses
Beitrages verwendet werden, stehen unter
http://www.scip.ch/labs/files/20091027_jsmalware
.zip zum Download bereit. Auch hier gilt die oben
genannte Warnung.
Schritt 2: Analyse
Nachdem der Code allein durch eine etwas sauberere Formatierung bereits viel lesbarer ist, ist
die weitere Bearbeitung geschmackssache.
Während einige die “Trockenanalyse” im Texteditor vorziehen (Deadlisting), werden wir in an dieser Stelle den freien Javascript Debugger Rhino
des Mozilla Projektes nutzen, um das File weiter
zu analysieren.
Rhino wird im Hinblick auf derartige Use-Cases
in der Regel missverstanden. Rhino ist eine
komplett eigenständige, in Java gehaltene, Javascript Implementierung. Das heisst konkret:
Die Syntax, wie sie unser Script verwendet, wird
11/15
s c i p
a g
© scip AG
komplett verstanden. Rhino ist aber kein FirefoxEmulator, wodurch gewisse DOM-Objekte wie
document, window oder ähnliches nicht von Haus
aus verfügbar sind.
So kommt es denn auch, dass Rhino bereits in
der ersten Zeile unseres Scripts seinen Dienst
verwehrt, weil ihm document.cookie unbekannt
ist.
var $a = document.cookie;// Lese
Cookie
var $b = $a.indexOf("opt=");//
Prüfe ob das Cookie String "opt="
enthält
if ($b != -1) {// Prüfe, ob Suche
erfolglos war
} else {
var $c = new Date;// Generiere
Datum
$c.setTime($c.getTime() +
3600000);// Generiere Timeout
document.cookie =
"opt=update;expires=" +
$c.toGMTString(); // Cookie
2. Dadurch, dass das Objekt document.cookie
im Regelfall in Sandbox Umgebung, wir der
von uns angestrebten, nicht existiert, wird die
automatisierte Analyse z.B. durch Web Gateways erschwert. Es existieren zwar weitaus
perfidere Methoden, derartige Fallen zu implementieren, weshalb wir hier nicht im Detail
darauf eingehen wollen.
Stattdessen ist unser Ziel, die Ausführung des
Codes zu ermöglichen. Das erreichen wir sehr
einfach, indem wir das gewünschte Objekt selber
bauen. document.cookie ist ein String Wert, der
im Falle eines Webbrowsers sowohl lesend wie
auch schreibend genutzt werden kann. Wir fügen
daher folgende Definition zu Beginn des Scripts
ein:
// Emulate document.cookie behaviour
function dummyStruct() {
this.cookie = "Foo";
}
document = new dummyStruct();
Durch diese Änderung wird unser Script weitgehend lauffähig. $a wird der Wert Foo aus unserer
Dummy-Struktur zugewiesen. Darin ist der String
opt= natürlich nicht enthalten, weshalb b den
Wert -1 erhält und das Script weiter ausgeführt
wird. $c wird anschliessend als Datumsobjekt
erstellt und document.cookie wird neu gesetzt.
Nach der Ausführung des initialen Codeblocks
folgt der Hauptteil des Scripts, der in einem tryBlock enkapsuliert ist, um keine auffälligen Meldungen im Falle eines Fehlers während der Ausführung zu generieren. Die zahlreichen Funktionsdefinitionen, die folgen, sind für uns im Moment nur reduziert relevant, wie widmen uns daher direkt der nächsten Zeile, die direkt ausgeführt werden soll:
Der erste Teil des Skripts ist sehr einfach verständlich. Der Autor liest die Cookiedaten der
geladenen Seite aus und prüft, ob die Variable
opt gesetzt ist. Wenn dies der Fall ist, so gibt die
Funktion indexOf in der zweiten Zeile einen positiven Integer Wert, nämlich die Position des
Strings opt= im Cookiestring aus. Der Autor des
Scripts war aber darum bemüht, dass der weitere
Verlauf des Scripts nur zur Ausführung kommt,
wenn opt nicht bereits gesetzt wurde. Ist dies der
Fall, so setzt er in den nächsten Zeilen des Cookie selber, versehen mit einem Timeout von einer
Stunde.
Dieser erste Codeblock erfüllt mehrere Zwecke:
1. Das Script wird auch bei mehreren Injektionen nur einmal binnen einer gewissen Zeitspanne ausgeführt, nämlich bei der ersten
Instanzierung wenn kein Cookie existiert.
document["w4151r4772i8362t4773e89191
269".replace(/[0-9]/g,
"")](SPyDgNA("CgTm"),
cues("YwUqxSVvI"));
Auch hier bedient sich der Autor wieder mehrerer
Tricks, um seinen Code möglichst immun gegenüber automatisierten Analysen zu machen. Verschiedene Punkte sind auffällig:
1. Die übliche, allgemein verbreitete Syntax, um
eine Funktion eines Objektes aufzurufen,
verwendet Punkte als Delimiter. Zum Beispiel
wird mit window.close() die Funktion zum
Schliessen eines Browserfensters aufgerufen. Alternativ könnte diese Funktion aber
auch über die weitaus seltenere Syntax
window["close"] aufgerufen werden.
12/15
s c i p
a g
© scip AG
2. Der Autor will also eine Funktion des DOM
Objektes document ansteuern, aber der Name
der
Funktion
("w4151r4772i8362t4773e89191269")
erscheint seltsam. Allerdings wird auf diesen
String direkt die Funktion replace(/[0-9]/g angewendet, die alle numerischen Zeichen aus
dem String entfernt. Das ergibt, was der eine
oder andere mittlerweile bereits selber entdeckt hat: document["write"] – die übliche
Funktion, die verwendet wird, um direkt in
das geladene HTML File zu schreiben.
Wie vorgängig erwähnt, dienen auch diese Mechanismen dem Aushebeln von automatisierten
Filtermechanismen. Im Regelfall suchen selbige
nach
auffälligen
Patterns,
wie
eben
document.write oder ähnlich. Durch das Nutzen
der sprachlichen Logik, wird eine musterbasierte
Erkennung nahezu verunmöglicht, der Code
muss interpretiert werden, um den verdächtigen
Code zu identifizieren. Diese Funktionalität ist
aber bislang nur sehr wenigen Content Filtern
und vergleichbaren Gerätschaften vergönnt, was
den Einsatz an dieser Stelle erklärt.
Wir wissen mittlerweile, dass es offensichtlich
das primäre Ziel der Applikation ist, Daten zur
Laufzeit in die geladene Seite zu injizieren. Die
Frage ist nun, um was für Daten es sich handelt.
Schauen wir uns noch einmal die Funktion an,
wie wir sie vorgängig aufgeschlüsselt haben:
document["write"](SPyDgNA("CgTm"),
cues("YwUqxSVvI"));
Es sollen die Rückgabewerte der Funktionen
SPyDgNA und cues, jeweils mit einem vordefinierten String als Parameter, ausgegeben werden. Die beiden Funktionen werden im Script
definiert und beinhalten – beide – eine liebevoll
verkomplizierte Reihe von Umwandlungen, die
letzten Endes zu den gewünschten Endresultaten
führen, die ausgegeben werden sollen.
Während ich dem geneigten Leser nicht vorenthalten möchte, diese beiden Funktionen im Detail
auseinanderzupflücken, um die genaue Funktion
nachzuvollziehen, können wir es uns an dieser
Stelle durch den Einsatz unseres Debuggers
deutlich bequemer machen. Wir könnten in der
oben dargestellten Zeile des document.write
Aufrufes einfach einen Breakpoint setzen und
danach über die Evaluate-Funktion in Rhino die
beiden Funktionen manuell aufrufen. Diese Methode ist adäquat, um die Ausgabe von
document.write hier zu eruieren, allerdings hat
sie den entscheidenden Nachteil, dass wir den
weiteren Verlauf des Scripts nicht mehr nachvollziehen können, weil Rhino mangels Kenntnis der
Funktion document.write gegen die Wand läuft.
Wir entscheiden uns daher für die nachhaltigere
Methode und implementieren in unserer bereits
existenten Dummy-Klasse die Funktion write.
// Emulate document.cookie behaviour
function dummyStruct() {
this.cookie = "Foo";
this.write = function(str, str2) {
var output = ""
for (var n = 0; n < arguments.length; n++) {
output += arguments[n];
}
print(output);
}
}
document = new dummyStruct();
Die Funktion write emuliert die Ausgabe im
Browser, schreibt aber die jeweiligen Strings statt
in ein Browserfenster in die Funktionsvariable
output und anschliessend mittels der Funktion
print() in die Debugging Konsole (Window ->
Console) von Rhino. Der Umweg über die outputVariable ist nötig, weil print() standardmässig
einen Zeilenumbruch (\n) anfügt, was die Ausgabe bei Verwendung mehrerer Argumente unerwünschterweise verändert.
Da wir nun alle Fallstricke umgangen und unseren Ausgabekanal definiert haben, lassen wir
Rhino durch das Script laufen. Es empfiehlt sich,
am Ende der Funktion cues() einen Breakpoint
zu setzen, um das Verhalten nach dem initialen
document.write zu beobachten, falls weitere Aktionen angestrebt werden. Im vorliegenden Fall
scheint sich die Funktionalität aber, zumindest
zum Zeitpunkt des ersten Ladevorgangs, auf den
analysierten Funktionsaufruf zu beschränken.
Nachdem das Script vollständig durchgelaufen
ist, können wir über die Konsole den HTML Code
betrachten, den das Script via document.write in
die betroffene Webseite zu schreiben versucht:
Schlussfolgerung
13/15
s c i p
a g
© scip AG
Betrachten wir nun die Ausgabe, so wird schnell
klar, dass es sich beim Script um einen klassischen Loader für Drive-by Angriffe handelt. Die
geladene Seite enthält weitere Scripts, die durch
das geschriebene iFrame nachgeladen und ausgeführt werden. Die Domäne yahoosite . ru, die
wir an dieser Stelle bewusst weder korrekt ausschreiben noch verlinken möchte, ist übrigens
eine bekannte FastFlux Ressource und scheint,
zumindest den 1,6 Millionen Google Resultaten
zu Folge, schon länger verwendet zu werden.
14/15
s c i p
a g
© scip AG
6.
Impressum
Herausgeber:
scip AG
Badenerstrasse 551
CH-8048 Zürich
T +41 44 404 13 13
mailto:[email protected]
http://www.scip.ch
Zuständige Person:
Marc Ruef
Security Consultant
T +41 44 404 13 13
mailto:[email protected]
scip AG ist eine unabhängige Aktiengesellschaft
mit Sitz in Zürich. Seit der Gründung im September 2002 fokussiert sich die scip AG auf Dienstleistungen im Bereich Information Security. Unsere Kernkompetenz liegt dabei in der Überprüfung
der implementierten Sicherheitsmassnahmen
mittels Penetration Tests und Security Audits
und der Sicherstellung zur Nachvollziehbarkeit
möglicher Eingriffsversuche und Attacken (LogManagement und Forensische Analysen). Vor
dem Zusammenschluss unseres spezialisierten
Teams waren die meisten Mitarbeiter mit der
Implementierung von Sicherheitsinfrastrukturen
beschäftigen. So verfügen wir über eine Reihe
von Zertifizierungen (Solaris, Linux, Checkpoint,
ISS, Cisco, Okena, Finjan, TrendMicro, Symantec etc.), welche den Grundstein für unsere Projekte bilden. Das Grundwissen vervollständigen
unsere Mitarbeiter durch ihre ausgeprägten Programmierkenntnisse. Dieses Wissen äussert sich
in selbst geschriebenen Routinen zur Ausnutzung
gefundener Schwachstellen, dem Coding einer
offenen Exploiting- und Scanning Software als
auch der Programmierung eines eigenen LogManagement Frameworks. Den kleinsten Teil
des Wissens über Penetration Test und LogManagement lernt man jedoch an Schulen – nur
jahrelange Erfahrung kann ein lückenloses Aufdecken von Schwachstellen und die Nachvollziehbarkeit von Angriffsversuchen garantieren.
Einem konstruktiv-kritischen Feedback gegenüber sind wir nicht abgeneigt. Denn nur durch
angeregten Ideenaustausch sind Verbesserungen möglich. Senden Sie Ihr Schreiben an [email protected]. Das Errata (Verbesserungen,
Berichtigungen, Änderungen) der scip monthly
Security Summarys finden Sie online. Der Bezug
des scip monthly Security Summary ist kostenlos. Anmelden! Abmelden!
15/15

scip ag

Transcrição

Documentos relacionados

2014: Jahr des Aufbruchs

scip ag

scip ag

Meetup gewinnt gegen Hacker

scip ag

scip ag

scip ag

Facebooks dunkle Seite

scip ag

scip ag

IT-Sicherheit in der Praxis