Archiv 2012

Labs: Archiv 2012

Inhaltsverzeichnis

► 30.12.2012 – Videos zu Hashdays 2012 Talks

Diese Tage sind die Videos zu den Talks der Hashdays 2012, die zum dritten Mal in Folge in Luzern stattgefunden haben, online gestellt worden.

Darunter finden sich auch der Lightning Talk von Sean Rütschi zu Holistic Server Security und der Talk von Marc Ruef mit dem Titel Firewall Rule Reviews – Methodologies and Possibilities (weitere Informationen zum Thema).

Marc Ruef | G+ (96 Wörter)

► 27.12.2012 – Blog Digest Dezember 2012

10 security stories that shaped 2012 (zdnet.com)
Blackberry OS 10 BlackLists Batman and PoohBear (blog.spiderlabs.com)
Brute Force Attack With Burp (pentestlab.wordpress.com)
China tightens ‘Great Firewall’ internet control with new technology (guardian.co.uk)
Domain theft and the possibilities for recovery (resources.infosecinstitute.com)
Experimenting with Your Privacy, Facebook Begins Selling Access (eff.org)
Fake AV 3 years later: still there, still not blocked (research.zscaler.com)
Fortinet’s FortiGuard Labs Reveals 2013 Threat Predictions (blog.fortinet.com)
Hiding files in GIF comments (floyd.ch)
HTML5 Definition Complete, W3C Moves to Interoperability Testing and Performance (w3.org)
Internet Explorer Data Leakage (spider.io)
LazyMap – Lazy Nmap Scanning Script (commonexploits.com)
Malicious Apache module used for content injection: Linux/Chapro.A (blog.eset.com)
My 5 Top Ways to Escalate Privileges (blog.spiderlabs.com)
Researchers find crippling flaws in global GPS (scmagazine.com.au)
Securing a tablet for web browsing in six easy steps (nakedsecurity.sophos.com)
Security Features vs. Securing Features (blogs.cisco.com)
Skynet, the potential use of Tor as a bulletproof botnet (infosecisland.com)
The 30-year-old prank that became the first computer virus (theregister.co.uk)
The Basics of IDA Pro (resources.infosecinstitute.com)
This $299 tool is reportedly capable of decrypting BitLocker, PGP, ... (thenextweb.com)
Trojan bypasses two-factor authentication, steals $46.5 million (techspot.com)
Using Penetration Tests To Gauge Real Risk (darkreading.com)
Virtualization Security (resources.infosecinstitute.com)
Website Malware – Reality of Cross-Site Contaminations (blog.sucuri.net)
Whose bug is this anyway?!? (codeofhonor.com)
Why Anti-Virus is not a waste of money (blog.eset.com)
Windows 8 ASLR Internals (blog.ptsecurity.com)

Marc Ruef | G+ (439 Wörter)

► 20.12.2012 – scip IT Security Forecast 2013

Wie jedes Jahr möchten wir auch zum Ende von 2012 einen IT Security Forecast für das kommende Jahr 2013 machen. Nachfolgend eben jene Themen – nach Möglichkeiten in der Reihenfolge absteigender Priorität -, die sich unseres Erachtens manifestieren oder gar noch weiterentwickeln werden:

Ganzheitliches Risikomanagement etabliert sich: Die letzten Jahre haben grössere Unternehmen Holistic Risk Management vorangetrieben und damit aufgezeigt, dass sich sowohl auf strategischer als auch auf taktischer Ebene nachhaltige Vorteile etablieren lassen. Auch kleinere Unternehmen werden nachziehen wollen, um die gelebte Informationssicherheit optimieren zu können.

Cloud und BYOD beginnen sich zu normalisieren: Nach rund zwei turbulenten und chaotischen Jahren bezüglich der Sicherheit von Cloud Computing und BYOD (Bring Your Own Device) beginnt sich mittlerweile soetwas wie Best Practice für diese Themen einzuspielen. Verschiedene Firmen konnten mittlerweile Erfahrungen in diesen Bereichen sammeln und dadurch die ersten Kinderkrankheiten adressieren.

Cloud-Mechanismen im privaten Bereich etablieren sich: Viele Benutzer werden im privaten Umfeld ganz selbstverständlich auf cloud-basierte Dienste, die teilweise schon standardmässig ausgeliefert werden (OS X, Win8), setzen. Das Bedürfnis für solche Mechanismen wird zusätzlichen Druck auf die Etablierung vergleichbarer Möglichkeiten im beruflichen Umfeld ausüben.

Kritik gegenüber Apple keimt auf: Der Hype um Apple wird einer latenten Kritik weichen. Die Produkte und Entscheidungen werden nicht mehr nur wohlwollend aufgenommen werden und damit ein schwieriges Zeitalter für den zuvor erfolgsverwöhnten Konzern einleiten. Dies wird die Chance für Alternativen wie Google Android und Microsoft/Nokia sein.

Elektronischen Zeitungen/Magazinen erreichen hohe Verbreitung: Das Lesen von Zeitungen und Magazinen und elektronischer Form wird stetig zunehmen und damit die lange anhaltende Kritik an einem solchen Konsum abebben lassen. Dazu tragen in erster Linie die leichten, hochauflösenden und leistungsstarken Geräte sowie die unkomplizierten Download-/Synchronisations-Dienste bei.

Windows XP verschwindet stetig: Das absehbare Auslaufen der Unterstützung von Windows XP durch Microsoft wird die Wachablösung durch Windows 7 vorantreiben. Unternehmen werden zunehmend die Migration angehen, was durch die skeptische Aufnahme des in manchen Punkten verspielt erscheinenden Windows 8 noch begünstigt wurde.

SMS als unsicheres Kommunikationsmittel wahrgenommen: Obschon erfolgreiche Angriffe auf GSM und SMS seit vielen Jahren möglich sind, wird die Unsicherheit von SMS und alternativen Kommunikationsdiensten (z.B. WhatsApp) in der breiten Öffentlichkeit immer mehr als unsicher wahrgenommen. Online-Banking, welche SMS als zweiten Faktor einsetzen, werden sich gewisser Kritik ausgesetzt sehen.

SHA-1 als unsicher wahrgenommen und abgelöst: Die anhaltenden und stetig verbesserten Angriffstechniken gegenüber SHA-1 werden diesen über kurz oder lang degradieren. Was heute MD5 ist, wird in wenigen Jahren SHA-1 sein. Und damit wird SHA-1 in hochsicheren Umgebung zunehmend ersetzt und voraussichtlich durch SHA-2 bzw. SHA-3 (Keccak) abgelöst werden.

Marc Ruef | G+ (486 Wörter)

► 13.12.2012 – NAXSI Open-Source WAF

WAF or Web Application Firewall is a fancy marketing name to describe technology that existed long before this term became common. In fact the technology behind WAF used to be called full application reverse-proxy and basically allows to forward, inspect and sanitize (or block) protocol requests to an application server.

Introduction

Those servers are most of the time critical assets or positioned in critical zones and therefore needs an added layer of security. Beware that a WAF is not a magic thing that will solve all your problem in publishing a web application you always should apply to following security rules:

Integrate threat risk model when designing applications (The OWASP risk model is a good example)
Review code of published applications
Review implementation design (application communication, interfaces, ...)
Secure middleware if any (Java, SQL, .NET, ...)
Secure underlying operating system
Review authentication and authorization of whole framework
Check for the OWASP top 10 vulnerabilities before going public
Do a penetration test of the environment before going live
Deploy an anomaly detection system that will help when things starts to go wrong
Last but not least: remember to log wisely and put those information in a safe place. You may need it when things went wrong.

WAF implementation in the security design makes also sense when all of the above rules have been followed, because it adds another layer of defense. Experience teaches us that there is never enough defense when it comes to web application security.

Why using a WAF?

Usually you better have a WAF instance in place if you have to deal with a situation reflecting one or a combination of the following security issues regarding a web application:

closed source and no possibility to inspect the source code
vulnerabilities that cannot be fixed or mitigated on the system
vulnerabilities that needs too much effort (costs) to be fixed
too old to be patched
too critical to be patched
too complex to be secured efficiently
authentication/authorization that is not available on the system

Maybe you’ll find anther one, but you get the point by now. Virtual patching is also a term used in such cases to describe one of the main feature of WAF: It allows to virtually patch a vulnerable web application, blocking the attack before it happens on the application proxy gateway.

You may argue that such attack may also affect the gateway itself (we are inspecting and interpreting the application protocol, remember?) and yes, WAF life is a dangerous one.

WAF configuring and fine tuning is not to be underestimated, that is why I told you before there is no magic thing that will do all for you from the start and stay forever that way – Remember: Security is a process.

Blacklisting vs. Whitelisting

Talking about WAF we need to distinguish two major categories of modus operandi: The blacklist and the whitelist approach (also referred as positive and negative security model).

The blacklist approach tries to block all bad things based on blacklists done by you and/or pre-configured for you. The whitelist approach tries to define an allowed baseline of what is allowed to do with the wen application.
As you may guess WAF can also take the hybrid approach to accomplish the following requirements:

Protect from top 10 OWASP vulnerabilities
Provide few false positives
Provide no false Negatives
Provide brute force protection
Protect from XSS, SQL injection, CSRF and file inclusions
Block strange characters an or requests
Sanitize HTTP & XML requests

There are several good commercial product out there (like Airlock and others) that fulfill almost all requirements, but I like to talk about the open source project NAXSI.

NAXSI Project

The NAXSI Project is not so known like the ModSecurity open source project, but has a very interesting approach and features.

NAXSI uses the small and performant reverse proxy engine of Nginx web server instead of the full blown Apache engine used by ModSecurity (and from a security point of view: the lesser code).

Following are the major feature of NAXSI:

Protects from XSS, SQL injections, CSRF, file inclusion
Fast engine
Relative simple configuration
Check GET/POST requests
Check HTTP headers and cookies
Forbid dangerous symbols and SQL keywords
Allows whitelist approach configuration creating a web application baseline
Able to run in learn or production mode
Uses no signature of known attack

Installation

Let’s do a quick installation with ubuntu sever 12.04 LTS. You may also install it from the sources following the Nginx prerequisites for reference. After you’ve installed the basic server with openssh, install NAXSI with:

 sudo apt-get install nginx-naxsi

Initial configuration

In the nginx configuration file (/etc/nginx/nginx.conf) uncomment this line to activate the basic rulesets:

##
# nginx-naxsi config
##
# Uncomment it if you installed nginx-naxsi
##
include /etc/nginx/naxsi_core.rules;

Note that this file is not an attack signature repository but rather a “score rules” set. Let’s configure NAXSI for our website www.scip.ch. To do so edit the Nginx configuration file in /etc/nginx/sites-enabled/default and add following entries in the server context:

server {
        proxy_set_header Proxy-Connection “”;    
        listen   80;

        location / {
                # put your website IP here
                proxy_pass http://80.74.141.2/;

                # put your website FQDN here
                proxy_set_header Host www.scip.ch;

                # Uncomment to enable naxsi on this location
                include /etc/nginx/naxsi.rules;
                }

        # Only for nginx-naxsi : process denied requests
        location /RequestDenied {
                # For example, return an HTTP error code
                return 418;
                }
        }

Now you should be able to start the nginx service that will bring up the NASXI with following command:

sudo service nginx start

Be sure to check for error messages on the console or in the error log found in /var/log/nginx/error.log and verify with sudo netstat -antup that nginx daemon is opening the configured port (tcp/80 in our case). The output should look like this:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address    Foreign Address   State       PID/Program name
tcp        0      0 0.0.0.0:80       0.0.0.0:*         LISTEN      9865/nginx
tcp        0      0 0.0.0.0:22       0.0.0.0:*         LISTEN      8484/sshd
tcp        0      0 127.0.0.1:6010   0.0.0.0:*         LISTEN      9627/0
tcp        0      0 127.0.0.1:6011   0.0.0.0:*         LISTEN      9062/1
tcp        0     32 x.y.z.52:22      x.y.z.36:49749    ESTABLISHED 9046/sshd: anco
udp        0      0 0.0.0.0:68       0.0.0.0:*                     649/dhclient3

To test if it works, start a browser session and point it to the ip address of your test server (x.y.z.52:80) and you should see the website you configured (www.scip.ch) in the config file above. To continue further testing make sure you will proxying all web request to the nginx-NAXSI WAF. To accomplish this you can ether use the web-proxy configuration setting in the browser or fake the testing website ip address in your system hostfile. I prefer to put the ip address in my hostfile:

x.y.z.52     www.scip.ch

Here are the location of the target hosts file (you need admin right to save changes):

OS	Host Configuration File
Windows	`%SYSTEMROOT%\system32\drivers\etc\hosts`
Linux	`/etc/hosts`

Now we can browse to www.scip.ch and be sure that our test NAXSI WAF will inspect the content and remember that by now the configuration is in learning mode; it will only report errors in the nginx error logs (/var/log/nginx/error.log) and not block any bad scored request.

How It Works

The naxsi_core.rules are responsible for scoring the HTTP input and looks like this (excerpt):

MainRule "str:;" "msg:; in stuff" "mz:BODY|URL|ARGS" "s:$SQL:4" id:1008;
#
MainRule "str:<" "msg:html open tag" "mz:ARGS|URL|BODY|$HEADERS_VAR:Cookie" "s:$XSS:8" id:1302;
#
MainRule "str:&#" "msg: utf7/8 encoding" "mz:ARGS|BODY|URL|$HEADERS_VAR:Cookie" "s:$EVADE:4" id:1400;
#
MainRule "rx:.ph*|.asp*" "msg:asp/php file upload!" "mz:FILE_EXT" "s:$UPLOAD:8" id:1500;

Insight this file is the logic configuration used to score the input; the result will be used in /etc/nginx/naxsi.rules to decide if such input may be allowed or not. The format is quite simple:

Define what to look for: string (str:) or regular expression (rx:)
Define message to report into logfiles (msg:)
Put the rule a category (s:)
Assign rule identifier (id:)
Define where to look for (mz:) and short description below

`mz` entry	Look in
URL	URL path
ARGS	HTTP argument
BODY	HTML body entry
$HEADERS_VAR:	HTTP header variable

Now let’s take a look on the second NAXSI config file /etc/nginx/naxsi.rules where the main NAXSI behavior is defined; this is how it looks like:

# config mode section
LearningMode;
SecRulesEnabled;
#SecRulesDisabled;
DeniedUrl "/RequestDenied";
#
# check rules section
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;

Here is an explanation of the contents:

LearningMode – activates learning mode; in this mode requests aren’t blocked and white lists may be created.
SecRulesEnabled or SecRulesDisabled – to activate or disable NAXSI for this location/section.
DeniedURL – redirect URL for blocked requests; can be an HTTP error code (like 4xx or 5xx) or forward to an HTML site with code to help track false-positives.
CheckRule – per-category check scores; the score we saw above will be evaluated here. If a request hits a score in the naxsi.core.rules, this score will be recorded and added to each category (SQL, XSS, EVADE, ...) if the overall score for any of the categories is reached (8 in SQL per default) the input is treated as bad.

When you use the whitelist (positive secure model) approach you’ll find also the white-list entries (BasicRule statement) in this config file:

# Whitelist '|', as it's used on the /report/ page, in argument 'd'
BasicRule wl:1005 "mz:$URL:/report/|$ARGS_VAR:d";
# Whitelist ',' on URL zone as it's massively used for URL rewritting !
BasicRule wl:1008 "mz:URL";

The entry above will result in disabling some part of the check rule in naxsi_core.rules allowing a specific behavior and eliminate false-positives. BasicRule could be more or less specific at your pace (and security needs).

Information Gathering

At this stage we have our test installation inspecting the HTTP flow and reporting bad things in the /var/log/nginx/error.log file, let’s take a look on how NAXSI error entry looks like:

> error.log <
2012/11/30 04:57:55 [error] 9866#0: *47 NAXSI_FMT: ip=x.y.z.36&server=x.y.z.52&uri=/testmiztot&total_processed=8589934625&total_blocked=679029381853280060&zone0=URL&id0=1999&var_name0=, client:x.y.z.36, server: localhost, request: "GET /testmiztot HTTP/1.1", host: "x.y.z.52"

As you can see it’s a special error message: it was generated on a “special” HTTP URL GET request and is not a really bad request. To test the functionality on the WAF I’ve created this test-rule in the /etc/nginx/naxsi_core.rules:

MainRule "str:testmiztot" "msg:foobar test pattern" "mz:URL" "s:$SQL:42" id:1999;

This rule will trigger whenever the testmiztot string is detected in the address part (mz:URL) of the HTTP GET request and score as 42 (s:$SQL:42) in the SQL category. This will be evaluated as bad because the SQL category limit is 8. The msg: text will be shown in the learning mode log used to generate the white-list baseline.

Summary

NAXSI is open source, high performance, low rules maintenance, and uses the very good Nginx reverse-proxy engine. Still, Naxsi is young, and there are known bugs. So test it, use it and see if it can help in your environment.

Andrea Covello | G+ (1930 Wörter)

► 06.12.2012 – Microsoft Proxy Einstellungen werden ignoriert – Was nun?

Wie im Labs Webapp Pentesting mit Burp von Marc Ruef beschrieben, nehmen wir gerne Burp zur Unterstützung eines Web Application Penetration Test zur Hand. Zur Kategorie Webapp gehören auch Applikationen, die ein Client-Frontend besitzen, welches über HTTP/HTTPS mit einem Webserver kommuniziert. Normalerweise lässt sich auch diese Verbindung über einen Proxy leiten. Es kommt aber auch ab und zu vor, dass eine solche Applikation sich einfach weigert den Traffic über einen Proxy zu schicken. Die Proxy-Einstellungen vom System werden ignoriert und die Applikation selbst bietet keine Möglichkeit einen Proxy anzugeben oder ignoriert selbst die eigenen Einstellungen. In diesen Fällen muss man den Traffic durch den Proxy zwingen. In diesem Artikel geht es um eine Möglichkeit, wie das zu realisieren ist.

Konzept

Ich bevorzuge Applikationen in einer virtuellen Umgebung zu testen. Zum einen habe ich für jeden Test eine neue Umgebung zur Verfügung, bei der ich sicher sein kann, dass keine Rückstände von einem früheren Test das Ergebnis beeinträchtigen. Zum anderen mag ich es nicht, Fremd-Applikationen auf meinem produktiven Client zu installieren.

Das Konzept dazu ist dann auch relativ einfach: Da der Client-Teil schon in einer virtuellen Umgebung ist, ist es ein Einfaches eine weitere Instanz zu kreieren, welche die einzige Aufgabe besitzt, den Traffic vom Client zur Burp Instanz weiterzuleiten. Konkret soll Traffic mit dem Ziel Port 80 (http) oder Port 443 (https) auf den Listener von Burp auf Port 8080 umgeleitet werden. Dies soll mit einer möglichst ressourcearmen Installation erreicht werden, damit noch genügend Ressourcen für das Hostsystem wie auch allfällige weitere Clients vorhanden sind.

Netzwerkzugriff via Burp Proxy

Environment

Wie vorhin schon erwähnt, soll die Router-Instanz möglichst Ressourcen sparend ausfallen. Deshalb habe ich mich für Ubuntu Server 12.4 LTS entschieden. Das virtuelle Environment basiert auf VirtualBox von Oracle, welches sich seit Jahren als gratis Alternative zu VMware Workstation etabliert hat und in den meisten Fällen von der Funktionalität völlig ausreicht.

Folgendermassen sieht meine Konfiguration der virtuellen Hardware aus. Natürlich können sich die Namen der NICs je nach eingesetzter Lösung unterscheiden. Wichtig ist nur, dass die Netzte logisch getrennt sind, und dass eine in dem gleichen Netz wie die Burp Instanz positioniert wird.

VM Einstellung	Wert
CPU Cores	1
RAM	96 MB
Harddisk	8 GB
NIC1	NAT
NIC2	Host-only Adapter

IP-Konfiguration und DNS Forwarding

Nachdem Ubuntu installiert wurde, gilt es die Netzwerk Interfaces richtig zu konfigurieren. Hier verweise ich gerne auf die Dokumentation von Ubuntu, welche sehr umfangreich und gut bewirtschaftet ist.

Ein Beispiel für die IP-Konfiguration ist nachfolgend aufgeführt. DHCP für das externe Interface habe ich gewählt, damit die VM möglichst portabel bleibt. Der interne IP-Adressbereich wurde mir von VirtualBox vorgeschlagen, welchen ich dann auch übernommen habe. Die interne Konfiguration spielt sowieso praktisch keine Rolle, da das Netz nur auf dem Host selbst vorhanden ist. Die Anpassungen werden in der Konfigurationsdatei /etc/network/interfaces vorgenommen.

NIC	Konfiguration
NIC1 (extern)	`auto eth0`
NIC1 (extern)	`iface eth0 inet dhcp`
NIC2 (intern)	`auto eth1`
	`iface eth1 inet static`
	`address 192.168.56.1`
	`netmask 255.255.255.0`

Nun ist die VM in der Lage, auf der Netzwerkebene zu kommunizieren und sie ist nun bereit, die nächsten Dienste zur Verfügung zu stellen. Das erste ist das DNS-Forwarding. Dazu setzte ich Bind9 ein. Auch hier möchte ich auf die sehr gute Ubuntu Dokumentation verweisen. Nachfolgend sind die nötigen Schritte kurz zusammengefasst.

Wichtig: Die von mir gewählten DNS Server sind die öffentlichen Google DNS Server. Nicht von jedem Netzwerk aus sind direkte DNS Anfragen ins Internet erlaubt. Dann müssten hier lokale und erreichbare DNS Server eingetragen werden.

Schritt	Beschreibung	Wert
1	Installation von Bind9	`apt-get install bind9`
2	Bind9 Konfiguration öffnen	`Nano /etc/bind/named.conf.options`
3	In Bind9 Konfiguration einfügen	`forwarders {`
		`8.8.8.8;`
		`8.8.4.4;`
		`};`
4	Bind9 neu starten	`/etc/init.d/bind9 restart`

Routing Funktionalität

Nachdem auch das DNS Forwarding funktioniert, kommt es zum eigentlichen Routing. Hierbei habe mich an den Guide betreffend Routing von der Ubuntu Community gehalten. Das beschriebene Skript unter Punkt 4.5 musste nicht angepasst werden, da sich die Konfiguration nicht von meiner unterscheidet. DasSkript selbst habe ich mit dem Befehl ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript bootable gemacht, damit es nicht nach jedem Neustart des Systems manuell ausgeführt werden muss.

Rerouting

Als finaler Schritt werden die Verbindungen zum Burp Proxy umgeleitet. Dies geschieht mittels den folgenden Befehlen, welche die Iptables konfigurieren und alle Verbindungen, die auf die Ports 80 und 443 gemacht werden, zu Burp auf Port 8080 umgeleitet. In diesem Laborbeispielt hat der Burp Proxy die IP-Adresse 192.168.57.23.

-A PREROUTING -t nat -i eth1 -p tcp --dport 80 -j DNAT --to 192.168.57.23:8080

-A PREROUTING -t nat -i eth1 -p tcp --dport 443 -j DNAT --to 192.168.57.23:8080

Nun können wir natürlich auch diese Regeln in den Bootprozess einbinden. Vor allem da das Skript vom letzten Schritt die Regeln von Iptables immer wieder zurücksetzten, ist es sinnvoll, diese in das vorhergehende Skript einzubinden. Als erstes wird die Burp Proxy Verbindung in einer Variablen definiert:

EXTIF="eth0"
INTIF="eth1"
BURPDST="192.168.57.23:8080"
echo "   External Interface:  $EXTIF"
echo "   Internal Interface:  $INTIF"
echo "   Burp Destination:    $BURPDST"                                     #added

Danach werden die beiden neuen Regeln in das Skript eingefügt:

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
-A PREROUTING -i "$INTIF" -p tcp --dport 80 -j DNAT --to "$BURPDST"         #added
-A PREROUTING -i "$INTIF" -p tcp --dport 443 -j DNAT --to "$BURPDST"        #added
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

Nach dem Neustart des Systems wird nun jeglicher Traffic auf Port 80 und Port 443 auf den Burp Proxy auf Port 8080 umgeleitet. Die VM ist nun fertig konfiguriert und steht für die anstehenden Tests zur Verfügung.

Burp und Client Anpassungen

Da die Verbindungen umgebogen werden, hat Burp ein wenig Mühe damit, die Anfragen zu behandeln. Dies kann mit der folgenden Fehlermeldung enden:

Burp proxy error: Invalid client request received: First line of request did not contain an absolute URL – try enabling invisible proxy support

Um dieses Problem zu beheben, muss Burp in den Transparent-Mode geschaltet werden. Dies geschieht in den Proxy-Einstellungen, indem man die Option Support invisible proxying aktiviert.

Invisible Proxy von Burp aktivieren

Auf der Seite des Clients mit der Software bleibt noch das Problem mit dem SSL-Zertifikat, welches natürlich nicht mehr passt. Für Burp gibt es eine Online Anleitung, wie man dieses Problem lösen kann. Leider lässt es sich nicht für jede Applikation umsetzen. Da gibt es dann nur noch die Möglichkeit, innerhalb der Applikation die Zertifikatsvalidierung zu umgehen und so eine Verbindung zu erzwingen.

Fazit

In Ausnahmefällen bei denen die Proxyeinstellungen ignoriert werden, ist dies eine einfache und schnelle Lösung. Vor allem wenn die VM einmal aufgesetzt wurde, kann sie beliebig oft weiterverwendet werden. Leider bleibt auch hier noch ein kleiner Rest an Applikationen übrig, die sich auch mit dieser Methode weigern, den Traffic über den Proxy zu schicken.

Pascal Schaufelberger | G+ (1248 Wörter)

► 29.11.2012 – Blog Digest November 2012

4 Turning Points in Cybersecurity History (tripwire.com)
4G Wireless Networks Are Extremely Vulnerable (technologyreview.com)
7 Ways Vulnerability Scanners May Harm Website(s) (blog.whitehatsec.com)
Anatomy of an Attack: How I Hacked StackOverflow (blog.ircmaxell.com)
Applying Game Theory to Cybersecurity (blogs.rsa.com)
Better off without AV? Not yet (blogs.csoonline.com)
CrowdStrike: HTTP iframe Injecting Linux Rootkit (blog.crowdstrike.com)
Data Loss Prevention – Without the New Blinky Boxes (hp.com)
Getting Started With Lock Picking (blog.opensecurityresearch.com)
Hacker leaks VMware ESX kernel source code online (zdnet.com)
Hashdays Wrap-up Day (blog.rootshell.be)
Indicators of Suspicious Behaviors at Hotels (publicintelligence.net)
Malware Targeting Windows 8 Uses Google Docs (symantec.com)
Microsoft’s security team is killing it: Not one product on Kaspersky’s list (thenextweb.com)
Money Laundering scenes in The Digital World (uscyberlabs.com)
Offensive Defense: A Really Bad Idea (krypt3ia.wordpress.com)
Security Headers on the Top 1,000,000 Websites (veracode.com)
Some thoughts on HTTP response codes (blog.c22.cc)
Telcos declare SMS ‘unsafe’ for bank transactions (itnews.com.au)
The Biggest Problem in Computer Security (carnal0wnage.attackresearch.com)
VMInjector – DLL Injection tool to unlock guest VMs (secforce.com)
Which Antivirus Cleans Best? (securitywatch.pcmag.com)

Marc Ruef | G+ (338 Wörter)

► 27.11.2012 – Security Log, Part 2: Requirements, Costs and Tools

Part 1: Experience with Log Management
Part 2: Requirements, Costs and Tools

This article is the second in a series of two. In the first part we discussed how to approach log management and our experience with it. In this part, we’ll look more specifically at the requirements and costs of the various stages as well as provide an overview of some open-source tools.

Foreword

Drawing a log management infrastructure is a complex task and requires the collection and analysis of requests from different company departments. After the preparation phase and the definition of the requirements, the design of the infrastructure can begin.

Since 2005, the SANS Industry Analyst Team conducts annual surveys on installed Log management solutions; looking at the results by year, we can extrapolate the main reasons, or expectations, behind a log management solution deployment.

SANS Log Management Trends

The graph illustrates how the various request priorities have changed over the years. Note how it has gone from Important to Critical, while the overall trend is upward for the first three and falling for the last two.

In a first phase, the systems were used for the optimization and monitoring IT infrastructure. with time, it became more important to be compliant with regulations and to track complex suspicious activity (increase of Critical versus detriment of Important). Keep this trend in mind when planning your solution.

Without pretending to exhaust the subject in these few lines, below we list, without extensive discussions, some basic criteria that we consider necessary for each component of the solution.

Infrastructure

Collect and Store

A good solution should be able to collect log data from across an enterprise regardless of their source. Syslog is the well known protocol for collecting systems log records in the UNIX world. Thanks to its relative simplicity, it has also been used in the Windows world. It is also simple to build interfaces from the different applications to send logs trough syslog infrastructure.

The system administrators should be able to remove or compress reports of events known to be uninteresting in favor of alert monitoring for events known to be interesting. But be conservative in discarding useless events, remember that the log is a friend so keep all possible messages.

Based on the requirements, tune your applications to generate the required information:

Audit
Transaction
Intrusion
Connection
User activity log
etc.

About 3/4 of organizations implementing log management solutions, collect logs from:

UNIX systems
Security devices (firewalls)
Network devices (switches/routers)
Network system/services (IDS/IPS/AV)
Security applications
Windows servers

Therefore, it is very important to not forget to sync time across devices and take care of the timezone.

Key points to consider while designing/choosing a log solution:

Normalize collected event data into a consistent format, possibly following NIST SP-800-92.
Collect log data with or without installing an agent on the log source.
Reduce event data through filtering or aggregation.
Handling peak event rates EPS; this is fundamental in case of attack.
Transmit in a secure manner, preferable over secure TCP
Collect from any flat-file ascii text log in real time (e.g. web server and application logs)
Aggregate and forward logs from multiple sources from any remote site and schedule transmission if needed.
Support of audit quality integrity mechanisms in accordance with NIST SP-800-92.
Support chained triggers.

Report

A robust infrastructure will perform both logging and auditing and store data using configurable automated methods to summarize them. At its simplest, reporting is a selection and formatting of the data stored. Its primary goal is to make a huge amount of data readable, rendering them in graphical format or extract just a few lines having very important content.

Building a report is not trivial, it involves a deep understanding of the data and how it is stored. Good tools provide standard reports out of the box. It is preferable to pick up 10/15 of those reports, tune and use them, not start playing with Jasper Report to get a customized 3 columns table and a pie graph with company logo. Reports should:

be concise
point to key information with graphs (if possible)
explain with tables

In very special cases it is preferable to create customised reports and the tool should be flexible enough to permit the creation of that report without much effort.

Key points to consider while designing/choosing a log solution:

An intuitive reporting interface for simple queries
A well documented database structure for complex SQL queries.
The ability to generate baselines and trends for group of hosts, specific protocols or combination in minutes.

Interact

The first place to start for an investigation or analysis of any security incidents will be the log tool, its performance and general UI design should be intuitive enough so as to not slow down the operator. The tool must provide the ability to create customized dashboards. Ideally, the dashboards should operate in real-time and provide drill-down capabilities.

Key points to consider while designing/choosing a log solution:

Simple, intuitive search interface usable by different users with varying skill sets.
Search performance must be capable of searching through millions of messages in less than a minute.
Logical segregation of log data that can be viewed by different teams.
Search interface must provide the ability to drill-down on output data.
Regular expression searches.
Logical concatenation.
Provide attack visualization
Guided retrieval of any archived logs in seconds

Correlate

A systems administrator was told his servers will soon be outsourced. Three days later, the administrator launches a SSH session to a MySQL server, runs a mysqldump and logs the output on the desktop. Then sends 10 emails to different accounts, each containing 30 lines of what looks like garbage.

Do you want an alert? To start coding this case a lot of information must be collected from different devices, stored long enough and interpreted. The system should maintain a tree of possibilities and react if a branch ends in a case.

The correlation engine depends mainly on rules the product can use. A critical point is to have an easy rule creation process. The search function available for events is also very important, as you will need the ability to search across multiple devices, logs and timeframes.

Key points to consider while designing/choosing a log solution:

Out of the box support of correlation policy including authentication failures, firewall security, worms.
Correlate messages from different devices.
Automatically define a “baseline” (Statistical/Historical correlation).
Monitoring attack history against critical asset or by particular users.
Correlation of different information regarding a single connection: ex. User/VPN/DHCP.
Beyond the real time data, it must be possible to correlate with short-term historical data to detect attack pattern.

Additional points

Additional key points to consider while designing/choosing a log solution:

Role based security model providing user accountability and access control; protect the data from the system administrator.
Open architecture allowing direct and secure access to log data via third-party analysis and reporting tools.

Costs

Calculating how much a solution will cost is hard. Talks with our customers about SIEM experience have pointed out a minimal model:

Initial costs

Hardware: servers/disks/databases, ...
Software: pay attention to the license model (user/CPU/cores/clients/...)
Additional software requirements
Training / Time to familiarize
Initial setup of SIEM and clients/applications
Tuning of SIEM and clients/applications
Solution of first-time issues

Ongoing costs

License/Support/Professional services
Operators/Maintenance
Review results: 50% of organizations use to invest at least 1 day/week in log analysis
Respond to alerts

Occasional costs

Updates (time to test new update and to apply to production systems)
Customization/Optimization
Expansions (add disks, CPUs, satellites)

Summary

Being tasked with planning a log management solution for your organization can be a bit overwhelming. Approaching the problem with sed/grep/awk, sorting and coloring a .csv file or directly installing a SIEM are all valid used solutions – But starting with the first one can help developing a mature concept and clarify the requests that a SIEM must satisfy.

With time, you will learn to understand your network, how different devices must work togheter to make an application run well, how they are interconnected, from which you need what information and so on. This takes time, but in the meantime you will look deep inside your infrastructure, understand how things work and prevent or resolve problems faster than before.

Once you know what you’re looking for, it will be easier to configure a SIEM, set alerts, correlate events and receive useful alerts.

In fact, before you can perform real-time analysis on all of the logs to detect threats as they occur, you need to capture all of the event data from the plethora of heterogenous event sources and store the logs in a centralized location, so start collecting today, then look inside the log, note how something should work and at the end configure a computer to check if the expectations are met.

Open-source tools

A list of useful open-source tools you can download and install on a Linux machine with relatively low effort. With these tools, you should be able to realise a pretty honest log management solution.

Graylog2 is an open source log management solution that stores your logs in ElasticSearch. It consists of a server written in Java that accepts your syslog messages via TCP, UDP or AMQP and stores it in the database.
ELSA is a centralized syslog framework built on Syslog-NG, MySQL, and Sphinx full-text search. It provides a fully asynchronous web-based query interface that normalizes logs and makes searching billions of them for arbitrary strings as easy as searching the web.
OSSEC an open source tool for analysis of real-time log data from Unix systems, Windows servers and network devices. A set of useful default alerting rules is included in standard configuration.
syslog-ng is a replacement and improvement of classic syslog service. I use to ping-pong between syslog-ng and rsyslog.
Snare agent is used to convert Windows Event Logs into syslog.

Some older tools you can also consider:

Simpler Log Watch
Some useful summarizing tools: Logwatch, Lire and LogSurfer.
Log2timeline is a useful tool for investigative review of logs; it can create a timeline view out of raw log data.
LogZilla (aka php-syslog-ng) is a frontend for viewing syslog-ng messages logged to MySQL in realtime. It features customized searches based on device, priority, date, time, and message.

References

{$t:Security log - part 2,$a:rcc,$v:1.0}

Rocco Gagliardi | G+ (2018 Wörter)

► 22.11.2012 – Security Log, Part 1: Experience with Log Management

Part 1: Experience with Log Management
Part 2: Requirements, Costs and Tools

This article is the first in a series of two. In this part we will discuss how to approach log management and our experience with it. In the second part we’ll look more specifically at the requirements and costs of the various stages as well as provide an overview of different tools.

Listen to the Devices

Often, during our audits, we run into the logging? problem; regulations or recommendations that, at some point, require the ability to analyze the data sent by computers about their operational state. Even conscientious companies, with very high levels of security, run into troubles. We see a series of erroneous behaviours:

not logging
logging but ignoring logs
looking just at the bad patterns
create sparkling useless reports
alerting without reaction
etc.

The problem is not trivial. Very good tools trying to collect and analyze a wide range of messages coming at very high speed from a plethora of different devices and applications, each of them garbage and highly important information at the same time. SIEM solutions are at the moment state of the art in log collection/analysis. Top, expensive products in this category are Q1 Labs and HP ArcSight, but there are also many useful open source tools to start with.

Buy a server, turn it on and let it do something for a couple of days is often sold as a solution, but this is quite unrealistic. Log management, and security log management as a special case, is a complex project that involves different components, technical and human and that requires a very high quality conceptional phase.

Our Experience

Between 2003 and 2008 we developed and deployed SE.LO.R.SY. (SEcurity LOg Reporting SYstem), our customized security log management solution. Several of our clients asked us for a solution to correlate data with the objective of identifying attacks in heterogeneous environments using complex communication channels. Our goal was to create a flexible enough, dedicated, highly secure solution for early adapters to solve very specific customer needs.

We provided the solution (software, db logic etc.) without extra fee; they payed us for the conception and the logic of what to log, where, why and how to report and present that to different internal divisions (legal, compliance, audit, it, security) and tiers ranging from technician to risk officer.

Supporting even a small number of log/s requires a robust and reliable infrastructure: All engines for

normalization,
storage,
reporting and
real-time analysis

must be stable, work together and provide good performance. If one of these key factors is missing, the entire solution may become unusable.

We designed SE.LO.R.SY. with focus on reporting, so to produce results in offline mode, but it is also possible to interact with the collected data and to be alerted in near real-time manner (~min interval).

Core components used:

Component	Usage	Details
syslog-ng	transport	internally initiated ssh tunnels to collect syslog data from external devices on dmz server
perl/dbi	parsing engine	parsing/normalizing and transactional insert relational records in three different tier-1 (option tier-2) mysql databases
php	reporting engine	reporting/presentation engine based on proprietary presentation framework

On a single low-end server (i686, 4GB, RAID-5) SE.LO.R.SY. was able to parse, normalize (extract ~10/15 pieces of information from the logline) and transactionally store about 1K logs/s (sustained), without in-memory summarization. At the same time, creation of daily reports based on tables/graphs (filtering and counting on a base of 2M logs/d) needed around 10min/report. Interactivity was tuned by the customer: Performance was increased placing strategic indexes – The challenge was to balance performance (insert/query) and space for an optimal overall usability.

We developed parsers for Checkpoint Firewall, Sonicwall, Windows Servers, Citrix, Unix log and audit, RACF and some others. At the end of the day we had solutions for auditing the administrators, AD changes and data calls on Windows platforms, escalating if the log-in chain (no sso) was corrupted from the initial log-in on the portal web, monitoring Citrix account and core banking application, correlating RACF logins with Unix logins and comparing them to the paper workflow of the given appropriate rights and many more, and it was possible to deliver customized security reports to different users, ranging from operators up to management.

Designing, engineering, implementing and customizing SE.LO.R.SY. for our different customers was not a simple task and we learned a lot about the log-management products from the inside point of view.

Some Terms

What is a Log

A log is a record of the events occurring within an organization. Logs are composed of log entries; each entry contains information related to a specific event that has occurred. Many logs within an organization contain records related to computer security (generated by firewalls, authentication software, anti-viruses, etc.).

Logging and auditing take different approaches to collecting data:

A logging infrastructure provides a framework for individual programs running on the system to report whatever events are considered interesting.
An auditing infrastructure, on the other hand, reports each instance of certain low-level events, regardless of which program caused the event to occur.

SIM (Security Information Management) is an event collection from applications and operational systems, normally responsible for:

Log and context data collection
Normalization and categorization
Reporting

SEM (Security Events Management)is collecting events relating together for security benefit, normally responsible for:

Correlation
Notification/Alerting
Prioritization

SIEM: Security Information and Event Management.

Logging or Auditing: Reasons, Advantages and Problems

Successful attacks on systems do not necessarily leave clear evidence of what happened. It is necessary to build a configuration in advance that collects this evidence, both in order to determine that something anomalous has occurred and in order to respond appropriately. Log consolidation is fundamental for detecting APT. Standards require you to log user, application and network activity.

However they tend to be very vague in how that information gets processed. You can usually get away with dropping in a black box, generating some colourful management reports, and be considered compliant. It may not help you find that backdoored system that is calling home, but you have met the standard.

A well-configured logging and audit infrastructure will show evidence of any misconfiguration which might leave the system vulnerable to attack, acting as problem prevention. Routine log analysis is beneficial for identifying security incidents, policy violations, fraudulent activity, and operational problems. Logs are also useful when performing auditing and forensic analysis, supporting internal investigations, establishing baselines, and identifying operational trends and long-term problems.

Auditing has the advantage of being more comprehensive, but the disadvantage of reporting a large amount of information is that most of it is uninteresting. Logging has the advantage of being compatible with a wide variety of client applications and of reporting only information considered important by each application, but the disadvantage that the information reported is not consistent between applications. Syslog is a standard on many different systems just because the MSG field is free-form text field, so you can fill it with whatever you like; more than 750 logfile formats are currently used.

Our Approach to Log Management

1. Define Scope

The scope of the infrastructure is the fundament on which to build them: Do you want to improve security or is there a compliance specification you need to adhere to? Declaring the primary goal to be compliant, monitoring, alerting or a combination of them steers the whole project in different direction.

It is very important to define the deliveries that the system must or should produce; it is preferable to start indicating the name, sections, records, filters, sort order, grouping, counting and the audience for each report.

2. Identify Processes and Roles

Infrastructure must produce something for different audience with different needs, must be maintained and must be audited. Identify teams to maintain the infrastructure with particular regard to the sensitivity of the data processed; normally, people deputed to the maintenance don’t have the rights to read/modify the processed data.

Define the destination groups: security, administrators, managers, architects; each of them need to look at the same data from a different perspective. Define the management team and carefully design the permission model to implement. Define the audit team and assure they regularly review the key parts of the system, from the generation trough transmission up to storage.

3. Plan Resources

Be sure to not under dimension the resources needed. Assign enough time to personnel to learn the infrastructure, identify the problems, solve it until a stable system state is reached. A typical pattern is to analyze a huge amount of logs, most of them useless; list the reported problems, prioritize them based on the number of logs that can be removed with a single action, act to correct the problem; repeat until log entry is eliminated or the number of superfluous log entries becomes acceptable.

This takes time and may have unpredictable impact on multiple company resources! Example: Firewall log filled with drops caused by a misconfigured application ⇒ Fixing the application may involve other departments and take a long time to be engineered and implemented.

4. Define Requirements

Define the requirements to meet and declare the method to use. Use these definitions to assure that the logging sources reports what is needed.

Do not just declare meet PCI-DSS requirements. Specify in detail which part of the regulation one must be compliant with, which information from which source is needed, what should be checked/counted, what is a normal/warning/error state, the generation frequency, who receives the result, what should be checked, how and how long should it be retained, what to do in case of warning and in case of error.
An example of definition:

area: authentication
scope: all systems with authentication
purpose: detect unauthorized access
method: track successful/failed login
search: multiple failed logins followed by successful login
baseline:
- normal(ignore): 2 failed logins/user/week
- warning: 2 failed logins/user/day
- error: >2 failed logins/user/day
response: alert operator, cross-check with suspect user, suspend login (sometime automatic after 10 failed logins)

5. Write Request For Proposal

If you would buy something from a vendor or start a project internally using open-source tools, summarize all requirements in a Request For Proposal (RFP) using very clear, short, punctual questions; even so you will get nebulous answers from your counterpart.

Describe functionality, use cases, which data must be parsed, which should, how many Events Per Second (EPS) you expect. Compare with open source products, but consider they will also cost.

Summary

During our years of development experience in log management solution, we learned that it is probably the single most effective security solution you can deploy. If you really care about the logs, this will give you unrivaled visibility into the inner workings of your network. A logging system can be resource intensive, but it can also provide a very high rate of return.

A common log language is missing and this makes it really difficult to manage the huge amount of information, so do not expect the X-Tool to solve all your problems. It is important to start with a very good concept, this is the absolutely first step; to do this, it is fundamental to collect as many needs/inputs as possible from different departments. Don’t just limit the focus on the single IT requirements; carefully plan resources needed and integrate the log management as part of daily business. Expecting to solve everything in a couple of weeks is naive.

{$t:Security log - part 1,$a:rcc,$v:1.0}

Rocco Gagliardi | G+ (1948 Wörter)

► 15.11.2012 – Webapp Pentesting mit Burp

Mit der Einführung neuer Technologien hat das Web immer mehr an Dynamik gewonnen und ist somit für webbasierte Applikationen immer interessanter geworden. Viele Anwendungen, die früher nativ und lokal auf einem Betriebssystem ausgeführt werden mussten, können heute remote und innerhalb eines Webbrowsers genutzt werden.

Automatisierte Analyse

Sowohl die Steigerung der Popularität von Webdiensten als auch die Erhöhung der Komplexität der dafür notwendigen Technologien hat direkten Einfluss auf die Angriffsfläche solcher Lösungen. Aus diesem Grund sind Web Application Penetration Tests in den letzten Jahren vermehrt in den Fokus von Sicherheitsüberprüfungen gerückt.

Der Umfang und die Vielschichtigkeit moderner Webapplikationen macht es praktisch unmöglich, diese binnen nützlicher Frist auf rein manueller Basis einer gerechten Prüfung unterziehen zu können. Zur Erhöhung von Effizienz und Zuverlässigkeit, werden aus diesem Grund nach Möglichkeiten automatisierte Mechanismen eingesetzt. Grundsätzlich kann dabei zwischen zwei Ansätzen unterschieden werden:

Automatisierte Vulnerability Scanner sind für die möglichst automatisierte Suche und Entdeckung von Schwachstellen in einer Lösung verantwortlich.
Semi-automatisierte Frameworks helfen dabei, etwaige Angriffsvektoren ausfindig zu machen und ausnutzen zu können.

Der primäre Einsatz automatisierter Vulnerability Scanner ist umstritten, denn gerade bei inviduell entwickelten Applikationen können sie gar nicht oder nur in beschränktem Rahmen verlässlige Resultate zusammenführen.

Aus diesem Grund pflegen wir bei der Durchführung von Penetration Tests auf Frameworks zur computergestützten Identifikation und Ausnutzung von Schwachstellen zurückzugreifen. Anhand des Beispiels von Burp soll das Vorgehen illustriert werden. Die Software steht als Freeware zum Download bereit. Viele der hier vorgestellten Funktionen (z.B. Scanning) sind aber nur in der kommerziellen Variante freigeschaltet.

Target – Ziele definieren

Typischerweise werden innerhalb von Netzwerktools die anzugehenden Zielsysteme als Targets definiert. Burp funktioniert hier ein bisschen anders, denn es handelt sich nicht um eine klassische Standalone-Applikation, mit der die Zugriffe initiiert werden. Stattdessen fungiert Burp als Proxy, der die initialen Zugriffe eines beliebigen Webbrowsers weiterleitet, anpassen und erweitern kann (ähnlich OWASP WebScarab).

Zu diesem Zweck muss Burp zuerst gestartet und der Proxy aktiviert werden. Standardmässig kann man ihn sofort als lokalen Proxy über 127.0.0.1:8080 ansteuern (Anpassungen können im Tab proxy vorgenommen werden). Im entsprechend konfigurierten Webbrowser kann nun die für die Prüfung vorgesehene Webseite aufgerufen werden.

Die erste Abfrage wird vom Proxy abgefangen

Beim ersten Zugriff wird der Tab proxy aufblinken und eben diese zuvor initiierte HTTP-Anfrage darstellen. Sie wird noch nicht direkt an das Zielsystem weitergeleitet, sondern wurde vorerst abgefangen. Durch das Abschalten des Buttons intercept is on kann dieses Enkoppeln deaktiviert und der Proxy in einen transparenten Modus geschalten werden: Von nun an werden sämtliche Anfragen nicht mehr aufgehalten, sondern direkt weitergereicht – Die Interception kann wieder aktiviert werden, um beispielsweise einzelne Zugriffe abfangen und dann dediziert weiterleiten, verändern oder verwerfen zu können.

Der Zugriff auf das Zielsystem hat nun, sofern die eigenen Anfragen sowie die daraus resultierenden Antworten weitergereicht wurden, stattgefunden. Um das Testing beginnen zu können, muss nun aber das Zielsystem – oder Teile davon – explizit als Target definiert werden. Zu diesem Zweck muss in den gleichnamigen Reiter gewechselt werden. In diesem werden unter scope die Zielobjekte festgehalten. Viele Funktionen können nur auf die hier definierten Objekte angewendet werden. Damit wird verhindert, dass die Prüfung auf nicht vorgesehene Objekte (z.B. externe Systeme, ausgeschlossene Verzeichnisse) durchgeführt wird.

Das Definieren des Target Scope ist emminent wichtig

Es können unter include in scope die zu prüfenden Objekte manuell definiert und entfernt werden. Typischerweise werden ganze Hostnamen zum Scope hinzugefügt. Und unter exclude from scope lassen sich Objekte festhalten, die in jedem Fall nicht angegangen werden sollen. In der Regel finden sich hier URLs und Parameter, die für Logout-Funktionen eingesetzt werden (es soll nicht mitten im Testing als authentisierter Benutzer ein Logout stattfinen). Oder Bereiche, die als instabil und besonders heikel gelten.

Die Site Map ist eine gute Ausgangslage für dedizierte Zugriffe

Einfacher ist es aber, dass wenn auf die site map zur Generierung des Scopes zurückgegriffen wird. In dieser wird in Echtzeit jedes Objekt (Host, Verzeichnis, Datei), mit dem interagiert wurde, festgehalten. In einer Baumstruktur lassen sich Hosts, Verzeichnisse, Dateien und Parameter ausmachen. Durch einen Rechtsklick auf ein solches Objekt kann das Kontextmenu geöffnet und dieses – sowie alle darunterliegenden Objekte – zum Scope hinzugefühgt werden. In der Regel werden ganze Hosts – oder wenigstens ganze Verzeichnisse – zu einem Scope hinzugefügt. Ob ein solches Hinzufügen funktioniert hat, kann dann wieder im scope geprüft (und bei bedarf manuell angepasst) werden.

Alle Zugriffe werden vollumfänglich in der History dokumentiert

Alternativ kann unter history beim Tab Proxy jede bisher durchgeführte Anfrage angezeigt werden. Dies ist einerseits wertvoll, um ein Höchstmass an Nachvollziehbarkeit gewährleisten zu können. Andererseits kann auch hier über das Kontext-Menu auf weitere Funktionen zugegriffen werden (z.B. Hinzufügen zum Scope, Starten eines Scans).

Bevor weitreichende Zugriffe angestrebt werden, sollte immer der Scope geprüft und gegebenenfalls angepasst werden. Daten aus vorangegangenen Sessions werden übernommen und es ist nicht untypisch, dass damit plötzlich Zielobjekte anderer Projekte in eine neue Prüfung miteinfliessen. Dies sollte unbedingt verhindert werden.

Spider – Daten sammeln

Es gibt nun zwei Varianten, wie die Zielobjekte angegangen werden können. Einerseits können weitere Zugriffe über den Webbrowser initiiert werden. Diese werden durch die Proxy-Funktionalität von Burp dokumentiert – hauptsächlich in history und in site map – und weitergereicht. Mit einem Mehr an Zugriffen wird auch ein Mehr an Daten anfallen. Diese bilden dann die Ausgangslage für weitere Zugriffe und Tests.

Das Durchforsten der Webseite kann aber auch in automatisierter Weise geschehen. Zu diesem Zweck kann der Spider eingesetzt werden, dessen Funktionalität unter dem gleichnamigen Reiter angeboten wird. Er wird durch das Aktivieren der Checkbox spider running (bis Version 1.4.1x) bzw. das Klicken des entsprechenden Buttons ein- und ausgeschaltet.

Durch den Spider werden alle potentiellen Zielobjekte gefunden

Standardmässig ist in spider scope definiert, dass die Datensammlung nur auf die zuvor im Gesamtscope definierten Objekte angewendet wird. Es lässt sich aber auch ein Custom Scope für den Spider definieren. In jedem Fall ist es wichtig, dass bei automatisierten Funktionen immer zuerst die Korrektheit der Scope-Definition und -Auswahl verifiziert wird.

Wird der Spider aktiviert, greift er als erstes auf jene Objekte des Zielsystems zu, die er schon bei vorangegangenen Zugriffen (sie sind in der Site Map dokumentiert) gesehen hat. Diese Dokumente lädt er herunter, wie wenn sie durch einen regulären Browser angefordert worden wären. Innerhalb der Dokumente werden weiterführende Objekte und Links gesucht, die – sofern sie ebenfalls im Scope sind – ebenfalls heruntergeladen werden. Dieser Prozess wird solange wiederholt, bis sämtliche verlinkten und angebotenen Objekte heruntergeladen worden sind. Im Grunde lässt sich damit eine Offline-Kopie der Webseite anstellen, so wie man es beispielsweise von wget kennt.

Ist der Spider aktiv, wird in einer kleinen Übersicht der aktuelle Status angezeigt. Die Anzahl für durchgeführte Anfragen, übertragene Bytes, vorgesehene Anfragen und abgeschickte Formulare wird aufgelistet.

Hierbei ist wichtig zu beobachten, ob die Anzahl der ausstehenden Objekte (requests queued) tendenziell abnimmt oder nicht. Sollte es über mehrere Minuten gegeben sein, dass die dort ausgewiesene Zahl gleich bleibt oder gar ansteigt, dann ist eine Fehlkonfiguration von Burp und/oder ein spezielles Verhalten der Webapplikation gegeben. Voraussichtlich unterstützt die Zielanwendung eine schier unendliche Zahl an verschiedenen Anfrageformen, wodurch stetig die gleichen Daten heruntergeladen und damit Burp quasi in eine Endlosschleife geschickt wird. In diesem Fall sollte der Spider deaktiviert und mit dem Drücken auf den Button clear queues die ausstehenden Anfragen entfernt werden.

In einem solchen Fall ist es angeraten, dass die wichtigsten Bereiche der Webapplikation mittels manuellen Zugriffen innerhalb des Browser aufgerufen werden. Der Spider sollte dann nur noch punktuell in ausgewählten Fällen zum Einsatz kommen.

Scanner – Schwachstellen entdecken

Die gerade für Einsteiger am nützlichste Funktionalität wird durch den Scanner bereitgestellt. Dieses Modul ist dafür zuständig, möglichst automatisiert potentielle oder existente Schwachstellen als solche zu identifizieren. Burp ist also nicht nur ein Framework, das bei der Suche und dem Ausnutzen von Schwachstellen unterstützt – Im weitesten Sinn kann es diese Aufgabe auch zu einem gewissen grad automatisiert angehen.

Das Scanning-Module identifiziert potentielle Schwachstellen

Die Scan-Funktionalität ist nach Bedarf sowohl passiv als auch aktiv gewährleistet. Unter live scanning können die entsprechenden Funktionen bestimmt werden:

Standardmässig wird das passive Scanning auf den aktiven Scope angewendet. Dies bedeutet, dass bei jeglichem Zugriff auf ein Objekt geprüft wird, ob es einen Hinweis auf eine Schwachstelle gibt. Das Scanning-Modul führt in diesem Zusammenhang keine zusätzlichen Zugriffe durch. Es werden also ausschliesslich die über die legitimen HTTP-Zugriffe bereitgestellten Informationen berücksichtigt (z.B. HTTPS/SSL, Formulare, Cookies, Dateinamen).

Das aktive Scanning wird standardmässig deaktiviert. Da hierbei eine Vielzahl zusätzlicher und teilweise verhältnismässig aggressiver Zugriffe durchgeführt werden, muss diese Funktionalität – analog zur Spider-Funktion – manuell aktiviert werden. Hier ist es ganz besonders wichtig, dass der Scope zuvor richtig definiert wurde und auf diesen verwiesen wird.

Unter results werden wiederum in Baumform die bisher zusammengetragenen Findings aufgelistet. Diese können ausgewählt werden, um eine Beschreibung und zusätzliche Details zu erhalten. Bei applikationsspezifischen Findings werden in der Regel sowohl Request als auch Response, die zum gegebenen Problem geführt haben, mitgeliefert. Dies erleichtert die Analyse und das weiterführende Ausnutzen einer Schwachstelle enorm.

Mit dem Aktivieren des automatisierten Scannings werden die zu prüfenden Objekte in die scan queue geschrieben. Dort ist zu sehen, welche Objekte gerade geprüft werden und welche Objekte für eine Prüfung vorgesehen sind. Burp unterscheidet hier nach URL ohne Parameter – Letztere werden iterativ bei den Zugriffen geprüft.

Durch das aktive Scanning werden Angriffsmöglichkeiten gesucht

Gerade bei grösseren Applikationen und bei Projekten mit einem eng gestrickten Zeitrahmen ist es nicht möglich, ein gesamtes aktives Scanning durchzuführen. Hier bietet es sich an, dass innerhalb der site map über das Kontext-Menu interessante Objekte an den aktiven Scanner geschickt werden. Gerade Such- und Kontakt-Formulare sind erste Anlaufstellen für solche Tests.

Standardmässig verwendet Burp ein Multi-Threading mit bis zu 10 gleichzeitigen Zugriffen innerhalb des aktiven Scannings. Obschon diese Einstellung bei den meisten Applikationen verträglich arbeitet, kann es durch die erhöhte Anzahl aggressiver Zugriffe zu Komplikationen, die den produktiven Betrieb tangieren können, kommen. Aus diesem Grund pflegen wir das Multi-Threading zwischen 2 und 5 gleichzeitigen Zugriffen festzulegen. Die Anzahl kann während des Scannings geändert und damit ein Optimieren der bestmöglichen Analyseform erarbeitet werden.

Intruder & Repeater – Schwachstellen ausnutzen

Die bisher diskutierte Funktionalität hat sich in erster Linie darum bemüht, einen Überblick zu einem Zielobjekt zu erhalten und etwaige Schwachstellen in diesem ausfindig zu machen. Ein professioneller Penetration Test geht aber noch einen Schritt weiter und nutzt die Sicherheitslücke aus, um Machbarkeit und Auswirkungen determinieren zu können.

Zu diesem Zweck werden in erster Linie die drei Module intruder und repeater eingesetzt:

Mit dem Intruder können spezifische Payloads auf ein Objekt angewendet werden. Durch das Definieren des Ziels (target) und einer Maske (positions) lassen sich iterative Zugriffe durchführen. Damit wird quasi die zuvor im Scanner automatisierte Funktionsweise individualisiert und semi-automatisiert zur Anwendung gebracht. Burp kommt mit einem Set verschiedener Payloads daher, die hochgradig angepasst werden können. Damit lässt sich ein sehr individuelles Fuzzing angehen.

Der Repeater ist eigentlich auf das manuelle Strukturieren von einzelnen Zugriffen ausgelegt. Der wird in der Regel verwendet, wenn ein möglicher Angriffsvektor ausgemacht wurde und sich in semi-automatisierter Weise und durch iterative Zugriffe an diesen herangetastet werden soll. Die einzelnen Parameter des Zugriffs lassen sich wie gewünscht anpassen und absetzen. Vorzugsweise wird diese Funktion genutzt, um GET- und POST-Parameter sowie HTTP-Header manipulieren zu können.

Zusammenfassung

Die Professionalisierung von Web Application Penetration Tests ist in einer stark durch Webapplikationen getriebenen Zeit unabdingbar. Durch ein möglichst hohes Mass an Automatisierung soll die Effizienz und Zuverlässigkeit entsprechender Prüfungen erhöht werden.

Exemplarisch wurde mittels Burp aufgezeigt, welche Funktionalität im Rahmen solcher Betrachtungen erwartet werden. Anhand konkreter Beispiele wurde illustriert, wie sich die einzelnen Module und ihre Funktionen einsetzen lassen, um Schwachstellen finden und ausnutzen zu können. Ausführliche Informationen zur Funktionsweise und Nutzung von Burp ist in der Online-Hilfe zu finden.

Marc Ruef | G+ (2164 Wörter)

► 08.11.2012 – Präsentation zu ganzheitlicher Server-Sicherheit

An den Hashdays vom 2. und 3. November 2012 (siehe auch unser Hashdays Diary) durfte ich das erste Mal an einer Sicherheitskonferenz eine Präsentation halten. Diese gestaltete sich in Form eines Lightning Talks, der insgesamt 8 Minuten dauerte.

Da ich nicht mit einem eigenen Talk gerechnet hatte, musste ich innert kurzer Zeit ein Thema auswählen sowie eine Präsentation dazu erstellen. Als Thema wählte ich Holistic Server Security, da ich mich in letzter Zeit vermehrt mit den einzelnen Punkten der Serversicherheit im Allgemeinen befasst hatte.

In absehbarer Zeit werden die Videoaufnahmen der Talks veröffentlicht und vermutlich werden sich auch die Lightning Talks darunter befinden. Bis dahin können die Slides, die hier zur Verfügung gestellt werden, begutachtet werden.

Sean Rütschi | G+ (150 Wörter)

► 03.11.2012 – Hashdays Diary 2012, Tag 2: Hinter den Kulissen

Tag 0: Anreise und Abendessen (Marc Ruef)
Tag 1: Mein Vortrag und diverse Treffen (Marc Ruef)
Tag 2: Hinter den Kulissen (Stefan Friedli)

Nachdem Marc seine Eindrücke seiner ersten beide Tag an den diesjährigen hashdays bereits niedergeschrieben hat, konnte er aus terminlichen Gründen am Samstag leider nicht mehr vor Ort sein. Wir haben uns daher darauf geeinigt, dass ich unsere Berichterstattung an dieser Stelle übernehmen werde.

Als einer der Hauptorganisatoren der hashdays war “Tag 2” de fakto schon Tag 5, zumal die Vorbereitung der Konferenz vor Ort, inklusive der Trainings und Management Sessions durchaus zeitintensiv ist. Der Samstag ist traditionell eher der ruhigere Tag, zumal am Vorabend üblicherweise der hashdays Social Event steigt, an dem es auch gerne mal etwas später wird und die Diskussionen öfters bei einem Drink in lockerer Atmosphäre geführt werden. So war Raum 1, dessen Supervision ich an diesem Morgen übernommen hatte eher dürftig gefüllt und der eine oder andere Zeitgenosse war offensichtlich dankbar um den Kaffee, der im Vorraum wie immer kostenfrei und in ausreichenden Mengen zur Verfügung gestellt wurde.

Alexander Polyakov und Dmitriy Chastuchin eröffneten den Tag sogleich mit Ihrem Talk Breaking SAP Portal. Leider meldete sich nach den ersten 3 Folien bereits das NOC via Funk und es galt eine Abklärung bezüglich eines doppelt benutzten Registrations-Barcodes zu lösen.

Diese kurze Episode ist eigentlich ziemlich exemplarisch für den Alltag unseres Teams während der Veranstaltung. Zwar wird durch die ganzjährige Planungsarbeit enorm viel Vorbereitung betrieben, aber trotzdem bleibt meistens nicht viel Zeit, sich selber einen Talk in voller Länge anzuschauen. Umso erfreulicher ist es dann aber, das nach dem Event mit den hochauflösenden Videoaufnahmen in den eigenen vier Wänden nachholen zu können. Als Programmverantwortlicher ist mir ja eigentlich im Vorfeld relativ klar, was präsentiert werden wir und auch die Slides liegen mir jeweils im voraus vor, dadurch kommt der Knowhow-Transfer zumindest nicht zu kurz. Besonders gefreut hat mich desweiteren, dass Sean Rütschi, einer unserer Mitarbeiter, spontan seinen ersten öffentlichen Vortrag an einer Konferenz im Rahmen der Lightning Talks gab.

So verging also auch der zweite Tag relativ rasch und bald hiess es dann auch schon wieder: Das war’s für dieses Jahr. Im Rahmen der Closing Ceremony verabschiedeten wir uns von unseren Gästen, die durch ihr zahlreiches Erscheinen dafür gesorgt haben, dass wir dieses Jahr die erste ausverkaufte hashdays vermelden durften. Danach ging alles ziemlich schnell: Material wurde abgebaut und in Autos verladen, ein kurzes Debriefing der Helfer wurde durchgeführt und dann ging es auch schon bald Richtung Zürich, wo ich in kleinem Rahmen mit einigen meiner Freunde, die für die Konferenz angereist zumeist als Speaker angereist waren, den Abend ausklingen liess.

Zusammenfassend war auch die dritte hashdays ein voller Erfolg und es ist schön, das positive Feedback zu hören, das via Twitter und E-Mail von Speakern, Sponsoren und Besuchern eintrifft. Einer der wunderbaren Aspekte eine derartige Community-Konferenz zu organisieren ist, dass unsere Besucher den Talks und Workshops grosse Passion und Begeisterung entgegenbringen, was für das hashdays Kommittee, das strikt als Non-Profit Organisation agiert, natürlich der schönste Lohn ist. Eines jedoch fehlt an jeder hashdays, und das ist Schlaf. Und aus diesem Grund werde ich diesen Beitrag an dieser Stelle beenden und wünsche einen angenehmen Start in die erste Woche, post-hashdays.

Stefan Friedli | G+ (570 Wörter)

► 02.11.2012 – Hashdays Diary 2012, Tag 1: Mein Vortrag und diverse Treffen

Tag 0: Anreise und Abendessen (Marc Ruef)
Tag 1: Mein Vortrag und diverse Treffen (Marc Ruef)
Tag 2: Hinter den Kulissen (Stefan Friedli)

Der erste offizielle Tag mit Vorträgen begann mit dem ersten Treffen alter Bekannter. Zu meinem Erstaunen habe ich auf den ersten Blick einen Grossteil der Anwesenden gekannt. Dies freute mich natürlich sehr.

Die Keynote wurde dann auch von Christien Rioux, mit dem ich mich gestern prächtig am Speakers Dinner unterhalten habe, gehalten. In seinem Referat diskutierte er die Schönheiten und Schwierigkeiten der Transition eines technischen Hackers zu einem guten Manager. Ein Thema, mit dem sich ein Grossteil der Leute früher oder später auseinandersetzen müssen. Seine Erfahrungen mit dem rasanten Wachstum von Veracode hat er dargelegt und gute Eckpunkte formuliert.

Als nächstes war der Vortrag von Chris Nickerson dran, der in Tactical Surveillance: Look at me now! einen breitflächigen Einblick in die Wichitgkeit und Möglichkeit der Auswahl und Analyse eines Ziels (Unternehmen oder Person) gab. Mit verschiedenen Mechanismen, Diensten und Tools zeigte er auf, dass professionelle Überwachung nicht unbedingt viel Geld kosten muss. GPS-Tracking, Wanzen und Laser-Mikrofone lassen sich auch durch einen technisch versierten Laien mit kleinem Portemonnaie basteln.

Weiter wartete ich gespannt auf IPv6 Insecurity Revolutions von Marc Heuse (van Hauser). Er zeigte auf, welche klassischen und leicht erweiterten Angriffstechniken sich auf die IPv6-Protokollfamilie anwenden lassen. Dazu gehören altbekanntes Flooding von Kernel-Komponenten sowie Overflows bei der Definiton von Fragmentierungszügen. Vor allem seine Einschätzung zur gegenwärtigen Etablierung von IPv6 sowie der Zukunft der nächsten Protokollgeneration waren interessant.

Danach gönnte ich mir eine Pause und diskutierte mit einigen alten und neuen Bekannten über die verschiedensten Themen. Erst kurz vor Mittag setzte ich mich nochmal in den Vortrag von Ilja van Sprundel. Unter dem Titel The Security (or Insecurity) of 3rd Party iOS Applications stellte er seine Erfahrungen bei der Analyse von iOS Apps – in erster Linie aus der Sicht von Source Code Reviews – vor.

Nach dem Mittagessen diskutierte ich noch ein bisschen weiter, um mich dann auf meinen Talk mit dem Titel Firewall Rule Reviews – Methodologies and Possibilities vorzubereiten. Um 16:30 Uhr war es dann so weit und ich war wirklich erfreut, wieviele Leute sich eingefunden hatten. Der Vortrag lief ganz gut und besonders die anregende Fragerunde zum Schluss hat mir Spass gemacht. Anhand des ersten Feedbacks meine ich, dass sich da durchaus der eine oder andere für das eigentlich traditionelle Gebiet interessieren könnte. Weitere Details zum Thema habe ich vor einigen Monaten in einem Labs Post dokumentiert.

Alles in allem war es ein spannender und anregender Tag. Leider kann ich aus terminlichen Gründen am zweiten Tag nicht teilnehmen. Aus diesem Grund bedanke ich mich bei allen alten und neuen Bekannten, mit denen ich ein paar Worte wechseln durfte. Und ich wünsche auch morgen spannende Vorträge und Gespräche!

Marc Ruef | G+ (520 Wörter)

► 01.11.2012 – Hashdays Diary 2012, Tag 0: Anreise und Abendessen

Tag 0: Anreise und Abendessen (Marc Ruef)
Tag 1: Mein Vortrag und diverse Treffen (Marc Ruef)
Tag 2: Hinter den Kulissen (Stefan Friedli)

Zum dritten Mal findet dieses Jahr die Hashdays Security Conference in Luzern statt. Und zum dritten Mal bin ich vor Ort, um einen Vortrag zu halten. Vor zwei Jahren diskutierte ich Nmap NSE Scripting, vor einem Jahr referierte ich über Software-Plagiate und dieses Jahr werde ich mich zur Analyse von Firewalls äussern.

Die Vorträge finden Freitags und Samstags statt. Doch wie immer reisen die Speaker schon einen Tag früher an, um am Abend gemeinsam am Speakers Dinner teilzunehmen. Die letzten beiden Jahre reiste ich jeweils mit der Bahn an, entschied mich dieses Jahr jedoch das Auto zu nehmen. Das verlief weitestgehend unkompliziert, auch wenn die Streckenführung in Luzern nicht immer jene war, die mein Navi vorsah …

Im Blu Radisson Hotel angekommen, begrüsste ich als erstes Mal die altbekannten Gesichter im NOC und holte meinen Badge ab. Dieses Jahr trumpft dieser mit einem Arduino Board auf, das eine Vielzahl von Möglichkeiten und Erweiterungen erschliessen wird. Nach dem Check-In für mein Hotelzimmer musste ich noch einige Anrufe tätigen, bis wir uns dann um 18:30 Uhr fürs gemeinsame Abendessen trafen.

Mein Hotelzimmer an den Hashdays 2012

Rund 30 Leute fanden sich dann auf einem Fondue-Schiff wieder. Während der angenehmen Fahrt auf dem Vierwaldstättersee wurde uns feines Fondue Chinoise und guter Wein serviert. Der hektische Tag machte mich hungrig und so fiel es mir schwer, mich zurückzuhalten.

Ich sass bei Christien Rioux, Iftach Ian Amit, Chris Nickerson und Sven Vetsch, die ich schon zuvor kannte. Wie üblich wurde über Gott und die Welt diskutiert. Christien war zum ersten Mal wirklich in der Schweiz und erfreute sich am familiären Zusammensein. Und Sven und ich amüsierten uns über skurrile Dinge, die uns währen der Arbeit so passieren. Es ist immerwieder lustig zu sehen, dass Security Tester schlussendlich immer mit den gleichen Problemen kämpfen, auch wenn man sich in der Hektik des Gefechts oftmals ziemlich alleine fühlen kann.

Nach der rund dreistündigen Fahrt ging es zurück ins Hotel, wo man sich noch einen Schlummertrunk genehmigte. Da ich schon seit 06:00 Uhr auf den Beinen war und es mittlerweile 23:00 Uhr hiess, legte ich mich ins Bett. Ein kurzer Check der Twitter- und RSS-Feeds, bevor ich dann endlich einschlief.

Marc Ruef | G+ (428 Wörter)

► 31.10.2012 – Blog Digest Oktober 2012

6 Business Friendly Features In iOS 6 (techcrunch.com)
botCloud – an emerging platform (stratsec.blogspot.com)
Bypassing WAF via HTTP Parameter Pollution (danuxx.blogspot.com)
Defending Against DoS Attacks (securosis.com)
Five Habits of Companies That Catch Insiders (darkreading.com)
Hacking KeyLoggers (blog.opensecurityresearch.com)
Hakin9 – Spam Kings (digininja.org)
Hoaxicane Sandy (blogs.rjssoftware.com)
How Did Software Get So Reliable Without Proof? (blog.regehr.org)
In a Zero-Day World, It’s Active Attacks that Matter (krebsonsecurity.com)
iOS photos EXIF data (swisshttp.blogspot.com)
James Bond’s Dry Erase Marker: The Hotel PenTest Pen (blog.spiderlabs.com)
Linux 3.6 (lkml.org)
Malware Authors Using New Techniques to Evade Automated Threat Analysis (symantec.com)
Mysterious Algorithm Was 4% of Trading Activity Last Week (cnbc.com)
New Security Capabilities in Adobe Reader and Acrobat XI (blogs.adobe.com)
NIST Selects Winner of Secure Hash Algorithm (SHA-3) Competition (nist.gov)
Physics duo create tractor beam using dual Bessel beams (phys.org)
Quality Coding Takes A Break For The Holidays. But Why? (threatpost.com)
Security Flaws in the TSA Pre-Check System (puckinflight.wordpress.com)
Spam from an Android botnet (blogs.msdn.com)
What Is SHA-3 Good For? (links.org)
What Makes a Good Security Risk Equation? (blog.securestate.com)
Windows 8 has new policy to prevent users from being connected (blogs.microsoft.co.il)
Words Of War And Weakness: The Zero-Day Exploit Market (techweekeurope.co.uk)
World of Warcraft cities hacked (bbc.co.uk)
Younger people less secure online than their elders new study suggests (blog.eset.com)

Marc Ruef | G+ (429 Wörter)

► 25.10.2012 – Sicherheit von Webservern – Einführung anhand praktischer Beispiele

Das World Wide Web ist bereits seit mehreren Jahrzehnten ein integraler Teil des Alltags von vielen Menschen. Dabei spielen Websites eine grosse Rolle, mit dem Aufschwung des Social Media umso mehr. Facebook, Twitter, Xing, Linkedin und alle anderen haben eines gemeinsam: Sie alle pflegen eine Website, über die sich täglich tausende von Menschen anmelden und ihren Beschäftigungen nachgehen.

Es ist daher kein Wunder, dass bei einem solchen Bekanntheitsgrad Sicherheitsmassnahmen, welche die User vor bösartigen Absichten schützen sollen, getroffen werden müssen. Doch nicht nur für solche grossen Seiten müssen Sicherheitsvorkehrungen getroffen werden, denn auch bereits schon kleine Websites können beispielsweise für die Verbreiter von Malware ein gefundenes Fressen sein, wenn diese nicht korrekt abgesichert sind.

Dabei fallen die häufigsten Sicherheitslücken auf Programmierfehler in den einzelnen Webapplikationen zurück. Eine übersichtliche Liste bietet die OWASP Top Ten Liste. Doch selbst bei einer hypothetisch angenommen fehlerlosen Webapplikation ist es möglich, dass eine Website für bösartige Absichten missbraucht werden kann, wenn der darunterliegende Webserver nicht korrekt konfiguriert wurde.

Ich werde in diesem Beispiel von einem Webserver ausgehen, auf dem Debian Linux in der Version Squeeze (6.0) installiert ist. Aus den Standardrepositories wird der Apache Webserver in der Version Apache/2.2.16 installiert, namentlich apache2. Dieses Paket stellt alle weiteren, für einen funktionierenden Webserver benötigte Pakete zur Verfügung. Ein weiteres, möglicherweise benötigtes Paket ist libapache-mod-security, welches ModSecurity, einer Web Application Firewall, in der Version 2.5.12 bereitstellt. Wichtig zu wissen ist jeweils, dass die Versionsnummer auf Debian Linux nicht angehoben wird, Sicherheitspatches aber jeweils rückwirkend eingespielt werden. Auf anderen Linuxdistributionen sind diese Pakete möglicherweise anders benannt und in anderen Versionen vorhanden.

Auf weitere Installationen wie PHP oder ähnliche Skriptsprachen werde ich hier nicht eingehen, da diese für eine grundlegende Webserverkonfiguration nur eine bedingte und sehr individuelle Rolle spielen.

Best Practices

Als Erstes möchte ich über einige Grundlagen eines guten Serverbetriebs gehen. Dazu gehört an erster Stelle ein vernünftiges Upgradekonzept. Upgrades sollten so schnell wie möglich eingespielt werden, nachdem sie, sofern nötig, vorher getestet wurden. Dabei ist es auch nötig, dass die Testumgebung eine exakte Kopie der Liveumgebung ist, um Fehler aufgrund unterschiedlicher Konfigurationen zu vermeiden.

Schon unzählige Angriffe wären erfolglos gewesen, wäre der darunterliegende Webserver auf dem neusten Stand gewesen!

Als Zweites gehört für mich die Verschlüsselung erwähnt. Wer eine Verschlüsselung anbietet, sollte entsprechend sicherstellen, dass ein gültiges SSL-Zertifikat verwendet wird, welches von allen gängigen Browsern als legitim anerkannt wird.

Besonders bei Webshops und anderen Websites, die Bezahlung über die Website annehmen, ist eine seriöse Verschlüsselung ein Muss.

Als Drittes möchte ich anmerken, dass versteckte Subversion- und Gitverzeichnisse in einem Rootverzeichnis eines Webservers nichts verloren haben. Ich habe bei einer routinemässigen Untersuchung eines Kundenservers einmal einen .svn-Ordner entdeckt, in dem ich gültige Benutzer und Passwörter für SSH- und Datenbankverbindungen vorfand. Solche Fehler können fatale Auswirkungen haben und sollten daher bei einem Deployment oder ähnlichem zwingend bedacht werden.

An sich müssten die oben erwähnte Dinge selbstverständlich sein. Doch manchmal denkt man in der alltäglichen Hektik nicht an alles und es unterlaufen einem Fehler. Aus diesem Grunde empfiehlt es sich, Checklisten anzulegen, die stets angepasst und erneuert werden, damit solche Fehler unterbunden werden können.

Eine Internetsuche fördert Unmengen solcher Best Practice Listen hervor. Wer noch keine solche einsetzt, sollte ernsthaft über deren Einsatz nachdenken.

Konfiguration

Kommen wir nun zur eigentliche Konfiguration des Webservers. In der Standardinstallation wird Apache in einer nicht konsistent sicheren Konfiguration ausgeliefert. Viele der Module, die in /etc/apache2/mods-enabled/ bereitgestellt werden, sind für Basisinstallationen gar nicht nötig. Ich empfehle, die hier geladenen Module genau unter die Lupe zu nehmen und dann jeweils individuell zu beurteilen, ob diese für die zu betreibende Websites benötigt werden. Jedes unnötige Modul sollte deaktiviert werden.

Debian Linux betreibt den Server automatisch als den eingeschränkten User www-data. Dies ist besonders wichtig, da bei einem geglückten Angriff der User root in den meisten Fällen nicht automatisch kompromittiert wird. Um sicherzugehen, dass auch bei einer solchen Kompromittierung die Website an sich so lange als möglich unangetastet bleibt, sollten die Dateien der Website einem weiteren User, also weder root noch www-data, gehören. Beachtet werden muss dabei, dass lediglich globale Leseberechtigungen benötigt werden, damit www-data die Dateien dann zur Verfügung stellen kann.

Nun zur eigentlichen Apachekonfiguration: Debian Linux beachtet für individuelle Konfigurationen den Ordner /etc/apache2/conf.d/. Ich empfehle, die Standardkonfiguration weitgehend unangetastet zu lassen und Änderungen hier einzutragen. Da Apache die Dateien nach alphabetischer Reihenfolge einliest, füge ich vor den Dateinamen jeweils ein zzz_ an, damit diese Dateien als letzte geladen werden und vorherige Konfigurationsparameter überschreiben.

Eine mögliche solche Datei könnte beispielsweise zzz_apache2.conf benannt werden und folgenden Inhalt aufweisen:

MaxClients 500
Timeout 30
TraceEnable Off
ServerSignature Off
ServerTokens Prod

Mit MaxClients werden die Anzahl gleichzeitig zugreifender Clients auf maximal 500 reduziert, alle darauf folgenden Zugriffe werden erst bei Zugriffsende eines vorherigen Clients nachträglich abgearbeitet. Diese Option sollte gemäss der gängigen Besucheranzahl gesetzt werden, um mögliche DoS-Angriffe abzuwehren. Ein zu gering gesetztes MaxClients vereinfacht DoS-Angriffe entsprechend, ein zu hoch gesetztes MaxClients kann den Server bei rechenintensiven Websites überladen.

Der Parameter Timeout definiert die maximal erlaubte Zeit

für GET-Anfragen,
zwischen dem Empfang eines TCP-Pakets bei einem POST oder PUT Aufruf,
zwischen ACKs bei Versand von TCP-Paketen in Antworten

und sollte auf einen individuell ermittelten Wert gesetzt werden. Die von Apache standardmässig vorgegebene Zeit liegt bei 300 Sekunden. In den meisten Fällen kann diese problemlos gesenkt werden.

TraceEnable Off verbietet TRACE Requests. Diese sind für einen sicheren Betrieb eines Webserver unnötig und sollten deaktiviert werden.

ServerSignature Off und ServerTokens Prod stellen sicher, dass in den HTTP-Headern jeweils nur Apache ohne jeglichen Zusatz von Versionsnummer oder ähnlichen verschickt wird. Sollte sogar dies unerwünscht sein, lässt sich mithilfe von ModSecurity der Header verfälschen. Hierfür muss allerdings folgender Eintrag gemacht werden:

ServerTokens Full
SecServerSignature "Apache/2.2.0 (Fedora)"

Apache/2.2.0 (Fedora) ist der von ModSecurity standardmässig gesetzte Wert, der problemlos auf jeden beliebigen Wert geändert werden kann. Weitere mögliche Anpassungen können in den ModSecurity Core Rules gefunden werden.

Webserver Mitschnitt ohne Anpassungen

Auf dem vorangehenden Bild wird ersichtlich, dass die ServerSignature bereits auf Off und die ServerTokens auf Prod gesetzt wurden. Dies erschwert es Angreifern grundsätzlich, die genaue Versionsnummer des Webservers zu eruieren.

Allerdings gibt es einige weiteren HTTP-Header, die eingesetzt werden können und von denen viele Webserveradministratoren keine Kenntniss haben. Dies rührt daher, dass sie meistens explizit in Hardening-Guides erwähnt werden und nicht in Standardinstallationen und -Guides enthalten sind.

Diese Header können wie folgt in einer Konfigurationsdatei eingefügt werden:

Header set X-Content-Type-Options nosniff
Header set X-Frame-Options deny
Header set X-XSS-Protection "1; mode=block"

X-Content-Type-Options nosniff verhindert, dass Microsofts Internet Explorer per MIME-Sniffing eine Antwort mit dem deklarierten Content-Type falsch lädt. Dasselbe gilt auch für Googles Chrome beim Download von Extensions.

X-Frame-Options deny verhindert das Laden einer Website via Frame. Ein weiterer möglicher, etwas weniger restriktive Parameter wäre sameorigin, der das Laden von derselben Website aus erlaubt, von fremden aber verbietet.

X-XSS-Protection "1; mode=block" schliesslich ist ein auf Webserverebene angesetzter Schutz vor Cross-Site Scripting.

Nach der Konfigurationsanpassung sehen die mitgelieferten Header bereits etwas anders aus:

Webserver Mitschnitt mit angepasstem Header

Wie dem vorangehenden Bild zu erkennen ist, werden die neu hinzugefügten Header aufgeführt. Ausserdem wurde der Serverheader auf Microsoft-IIS/5.0 gesetzt. Die Header X-Content-Type-Options, X-Frame-Options und X-XSS-Protection werden ausgeliefert.

Wer eine komplette Auflistung aller möglichen HTTP Header möchte, kann diese auf Wikipedia genauer betrachten.

Zu guter Letzt möchte ich ein Thema ansprechen, welches viele Webserveradministratoren, aber auch viele Webentwickler ignorieren, vergessen und nicht genügend kennen. Die Rede ist von Cookies sowie deren Konfiguration auf einem Webserver.

Cookies werden hauptsächlich dafür eingesetzt, Sessionvariablen zu verwalten, wenn sich Benutzer auf einer Website einloggen. Das Problem ist, dass Cookies auf den PCs der Benutzer und nicht auf den Servern abgelegt werden. Dies ist aus Performancegründen sinnvoll, da der Server dann weniger belastet wird, hat aber aus Sicht der Sicherheit einen gravierenden Nachteil: Der Webserveradministrator kann schliesslich nur in den wenigsten Fällen die Schutzmassnahmen auf einem Benutzer-PC definieren. Wenn dieser das Ausführen von Scripts erlaubt, kann auf die Cookies zugegriffen werden.

Ein durch Cross Site Scripting gestohlenes Cookie kann aber möglicherweise vom Webserveradministrator verhindert werden. Dies bedingt lediglich das Setzen eines einzelnen Parameters:

Header edit Set-Cookie ^(.*)$ $1;HttpOnly

Damit wird, sofern es der eingesetzte Browser unterstützt, das Cookie mit HttpOnly generiert, wodurch es nicht von Scripts gelesen werden kann.

Es gibt eine weitere Option, die sicherstellt, dass der Inhalt von Cookies nur über eine verschlüsselte Verbindung ausgelesen werden kann. Dieser Parameter kann folgendermassen gesetzt werden:

Header edit Set-Cookie ^(.*)$ $1;Secure;HttpOnly

Damit kann der Inhalt eines Cookies nicht mehr über eine gewöhnliche HTTP-Verbindung ausgelesen werden und forciert somit den Einsatz von SSL beziehungsweise TLS.

Natürlich sind diese Optionen nach wie vor von der Sicherheitseinstellung der jeweiligen Benutzer abhängig. Denn wenn die Benutzer durch fahrlässiges Verhalten ihre Benutzerkonten zur Verfügung stellen, kann auch der beste Webserveradministrator nicht weiterhelfen.

Denn damit haben wir den grössten Teil der Grundkonfiguration des Webservers erledigt. Was nun folgt, sind weitere Elemente, die beachtet werden sollten. Dazu gehören die Themen Logs und Backups.

Logs

Logs spielen eine zentrale Rolle bei der Mitigierung von Angriffen, denn ohne sie wüssten wir oft nicht, dass Angriffe respektive deren Versuche überhaupt stattgefunden haben. Aus diesem Grund sollte ein Webserver seine Logs stets auch an einen zusätzlichen Logserver senden, damit diese im Falle eines gelungenen Angriffs zur Rekonstruierung des Vorgehens der Angreifer beitragen können. Die Logs einer Standardinstallation liegen unter Debian Linux im Verzeichnis /var/log/apache2/.

Ausserdem sollte automatisiert nach unerwünschten Zugriffen gescannt werden, um Möchtegernangreifer bereits aussperren zu können, bevor sie nennenswerten Schaden anzurichten in der Lage sind.

Auszüge eines Angriff mittels Brute-Force könnten beispielsweise so aussehen:

[Tue Apr 17 16:56:47 2012] [error] [client X.X.X.X] client denied by server configuration: /var/www/admin/ 
[Tue Apr 17 16:56:47 2012] [error] [client X.X.X.X] client denied by server configuration: /var/www/admin/ 
[Tue Apr 17 16:56:47 2012] [error] [client X.X.X.X] client denied by server configuration: /var/www/admin/ 
[Tue Apr 17 16:56:47 2012] [error] [client X.X.X.X] client denied by server configuration: /var/www/admin/ 
[Tue Apr 17 16:56:47 2012] [error] [client X.X.X.X] client denied by server configuration: /var/www/admin/ 
[Tue Apr 17 16:56:48 2012] [error] [client X.X.X.X] client denied by server configuration: /var/www/admin/ 
[Tue Apr 17 16:56:48 2012] [error] [client X.X.X.X] client denied by server configuration: /var/www/admin/ 
[Tue Apr 17 16:56:48 2012] [error] [client X.X.X.X] client denied by server configuration: /var/www/admin/ 
[Tue Apr 17 16:56:48 2012] [error] [client X.X.X.X] client denied by server configuration: /var/www/admin/ 
[Tue Apr 17 16:56:48 2012] [error] [client X.X.X.X] client denied by server configuration: /var/www/admin/

Mehrere Zugriffe pro Sekunde deuten auf einen automatischen Zugriff mittels eines Bots hin. Natürlich könnten diese Logeinträge auch von einem legitimen Fehlverhalten eines Benutzers stammen, doch ich gehe in solchen Fällen lieber auf Nummer sicher.

Die Aufgabe des automatisierten Aussperrens lässt sich mit Cronjobs jeweils leicht lösen. Hilfreich ist es dabei jeweils, wie bereits bei den Systemupgrades eine E-Mail verschicken zu lassen, wenn beispielsweise eine IP geblockt wurde. In diesem Beispiel könnte ein entsprechendes Skript in etwa so aussehen:

#!/bin/bash 
#alle ips, die einen 403 er generieren, blockieren

	HOSTDENY=$(grep ‘client denied by server configuration:’ /var/log/apache2/error.log /var/log/apache2/error.log.1 | awk ‘{print $8}’ | uniq | sed ‘s/\]//’ 

	for host in $HOSTDENY; do 
  ATTACKS=$(grep $host /var/log/apache2/error.log | wc -l) 
  if [ $ATTACKS -gt 10 ]; then 
    HOSTEXISTS=$(grep $host /etc/hosts.deny) 
    if [ -z “$HOSTEXISTS” ]; then 
      echo “Blocked IP $host” | mailx -s “ipblocker for $(hostname)” noreply@email.ch 
      echo “ALL: $host” >> /etc/hosts.deny 
    fi 
  fi 

done 

	exit 0

Alle Szenarien abzudecken ist sicherlich nicht einfach, doch mit entsprechender Erfahrung kann für jede Umgebung ein entsprechender Logsucher geschrieben werden, der automatisch nach Diskrepanzen in den Logs sucht und die Übeltäter aussperrt. Wird die Mühe auf sich genommen, diese Überprüfungen zu automatisieren, wird man mit schnelleren Reaktionszeiten im Ernstfall sowie eine vereinfachte Statistikerstellung belohnt.

Backups

Ein weiteres Thema sind Backups und deren korrekte Durchführung respektive Aufbewahrung. Dass dies noch nicht überall wie wünschenswert durchgeführt wird, zeigte sich erst kürzlich beim Hack der Firma RedSky, als diese ihre gesamte Website inklusive aller Backups verlor.

Grundsätzlich haben Backups von Websites auf dem Server, auf dem sie betrieben werden, nichts verloren. Ausser einigen wenigen Snapshots, die man für rasche Wiederherstellungen verwenden kann, sollte stets eine dedizierte Backupmaschine bereitstehen, die solche Aufgaben übernimmt.

Auch Backups können, wie bereits die Logauswertung, automatisiert vorgenommen werden. Unter eine reinen Linuxumgebung werden Backups häufig mit rsync realisiert. Dazu benötigt der Webserver lediglich einen laufenden SSH-Dienst, doch auch dieser muss entsprechend konfiguriert werden. Um ein gesamtes System zu backupen, muss der Prozess mit dem User root gestartet werden.

Dies muss natürlich entsprechend abgesichert werden, da ein für root automatisiert geöffnetes Tor eine Möglichkeit zum Missbrauch bietet. Aus diesem Grund muss in /etc/ssh/sshd_config der PermitRootLogin-Parameter folgendermassen gesetzt werden:

PermitRootLogin forced-commands-only

Damit kann der User root über SSH nur noch vordefinierte Befehle ausführen. In der Datei /root/.ssh/authorized_keys wird nun folgendes eingetragen:

from="10.0.1.2",command="rsync --server --sender -vlHogDtpre.iLsf --numeric-ids . /",no-pty,no-agent-forwarding,no-port-forwarding,no-user-rc,no-X11-forwarding ssh-rsa AAAA... root@backupserver

Dies erlaubt dem User root, nunmehr nur noch einen bestimmten rsync auszuführen. Dieser kann in einem Skript, beispielsweise unter /usr/local/sbin/ abgelegt, wie folgt festgelegt werden:

#!/bin/bash 

	SERVERS=“10.0.0.1 10.0.0.2” 

	for i in $SERVERS; do 
  status=“1” 
  until [ “$status” == “0” ]; do 
    rsync -avH —numeric-ids —exclude=/dev/* —exclude=/proc/* —exclude=/sys/* —exclude=/tmp/* $i:/ /backups/$i/$(date ‘+%Y-%m-%d_-_%H-%M-%S’) 
    status=$? 
  done 

done 

	exit 0

Somit können alle in der Variable SERVERS eingetragenen Server in den Backupprozess eingetragen werden. Das Skript selber muss lediglich als Cronjob hinterlegt werden, um regelmässige Backups anzulegen.

Schlusswort

Einen Apache Webserver abzusichern benötigt einige Schritte, die für viele auf den ersten Blick nicht offensichtlich erscheinen. Dies liegt häufig auch daran, dass häufig Kenntnisse benötigt werden, die erst nach längerem Suchen gefunden werden können. Ich hoffe, dass ich auf einige allgemein gültige Punkte hinweisen konnte, die übersehen oder missachtet wurden, und aufzeigen, weshalb diese Punkte beachtet werden sollten.

Sean Rütschi | G+ (2540 Wörter)

► 18.10.2012 – Microsoft AppLocker – Das wenig beachtete Sicherheitsfeature

Mit Windows 7 und Windows Server 2008 R2 wurde ein Sicherheitsfeature von Microsoft eingeführt, welches bis dato ein bisschen ein Schattendasein fristet. In den Vorgängerversionen von Windows gab es Software Restriction Policies unter den Group Policy Einstellungen. Diese wurden eingesetzt, wenn auch nur spärlich, um Benutzer an der Ausführung gewisser Programme zu hindern (Blacklisting). Da dieses Ziel aber auch über die NTFS Berechtigungen erreicht werden kann, wurde die Software Restriction selten bis gar nie eingesetzt. Microsoft hat nun mit dem AppLocker den Ansatz umgedreht und ist zu einem Whitelisting-Verfahren übergegangen. Dies bedeutet, dass alles verboten ist was nicht explizit erlaubt wurde. Also der gleiche Ansatz wie bei Firewall-Regelwerken.

Einsatzgebiet

Auch wenn natürlich der Einsatz auf den Endgeräten wünschenswert wäre, so sehe ich das grösste Potenzial dieses Feature im Bereich des Microsoft Terminal Server und Citrix XenApp. Die Herausforderung in diesen Umgebungen ist ja dem Benutzer alle Möglichkeiten zu lassen, um effizient zu arbeiten, aber das System so zu sichern (Hardening), dass kein Ausbrechen aus der vorgegebenen Umgebung möglich ist.

Terminal Server und Citrix XenApp Administratoren, die sich mit Sicherheit befassen, kommen früher oder später in Kontakt mit dem Whitelisting Ansatz. In diesem Bereich haben sich Firmen wie AppSense und triCerat mit ihren Lösungen einen Namen gemacht. Ich wollte mal schauen, was ich mit dem AppLocker schon alles abdecken kann, was die gestandenen Lösungen bieten.

Das Ziel

Zuerst brauche ich ein Ziel, das ich mit der Lösung erreichen will. Das Ziel ist rasch definiert: Ein Benutzer soll nur die ihm zugewiesenen Applikationen starten können. Wie Marc Ruef in seinem Artikel Citrix under Attack beschreibt, besteht ein grosses Risiko, dass man aus der vorgesehenen Umgebung ausbrechen kann.

Erste Schritte

Hier wird eigentlich schon klar warum diese Feature ein Schattendasein fristet. Man findet es nicht prominent als Programmpunkt irgendwo aufgelistet, sondern als Unterpunkt in der lokalen oder globalen Computer Policy. Da ich ein Fan von zentral gemanagten Systemen bin, entscheide ich mich für den GPO (Group Policy Object) Ansatz. Dies erlaubt mir die Policy gleichzeitig auf all meinen Terminal Server einzusetzen.

Erstellen einer Group Policy

Nach dem Erstellen des GPO finde ich die AppLocker Einstellungen unter dem Menupunkt Computer Configuration/Policies/Windows Settings/Security Settings/Application Control Policies/AppLocker. Nun sehe ich, welche Einstellungsmöglichkeiten ich habe. Insgesamt kann ich aus fünf verschiedenen Regelgruppen auswählen. In der nachfolgenden Tabelle sind die Gruppen und deren betroffenen Dateien ersichtlich. Die Gruppe DLL Rules ist als erstes nicht ersichtlich und muss über die Einstellungen von AppLocker zuerst aktiviert werden. Ich lasse sie für die Terminal Server Umgebung aber deaktiviert, da jeder DLL Aufruf gegen das Regelwerk geprüft werden müsste und die Performance enorm darunter leiden würde. Auch würde sich der Konfigurationsaufwand und die Fehleranfälligkeit unnötig erhöhen.

Regelgruppen	Betroffene Dateiendungen
Executable Rules	.exe
Executable Rules	.com
Script Rules	.ps1
	.bat
	.cmd
	.vbs
	.js
Windows Installer Rules	.msi
	.msp
	.mst
Packaged app Rules	.appx
DLL Rules	.dll
DLL Rules	.ocx

Als erstes erstelle ich für die vier verbleibenden Regelgruppen die Standardregeln. Dies geschieht einfach mittels rechter Maustaste und Create Default Rules. Dies dient mir als Basis für mein Regelwerk. Vor allem wird jeweils eine Regel für die Administratoren erstellt, damit die nicht aus Versehen aus dem System ausgesperrt werden. Nun bin ich bereit das Regelwerk zu definieren.

Ersteller einer neuen Standardregel

Das Regelwerks erstellen

Zuerst erstelle ich eine Standard Regel. Die soll mir aufzeigen, auf was für Dateien ein Benutzer in einer Remote Desktop Session Zugriff braucht. Dafür wähle ich Notepad als meine Testapplikation aus. Ich weiss, dass Notepad keine weiteren Programme braucht, um starten zu können.

Definieren des Erkennungsmechanismus

Ich wähle bewusst die Regel für Dateipfade aus. Mit den NTFS Rechten kann ich die Executables sehr gut vor Änderungen schützen. Generell Publishern vertrauen kommt für mich nicht in Frage. Microsoft liefert mit Windows genügend Programme, um aus dem Kontext auszubrechen. Diese wären alle erlaubt, wenn ich Microsoft vertrauen würde. Und der Filehash ist eine sehr gute Möglichkeit um sich zu schützen, man muss aber die Regeln anpassen sobald kleinste Änderungen an der Software erfolgen (z.B. Patches). Nun gebe ich den Pfad von notepad.exe (%SYSTEM32%\notepad.exe) in der Regel an und erlaube die Ausführung für alle Domain Users. Ist die Regel erstellt, folgt schon der nächste Schritt.

Das Regelwerk testen und aktivieren

Als nächstes aktiviere ich die Regel im Audit only Modus. Damit überwache und teste ich die Regel.

Regel im Audit-Modus betreiben

Das heisst die Anwendungen werden geprüft und alle Aktivitäten werden aufgezeichnet. Im Event Viewer und dem Punkt Applications and Services Logs/Microsoft/AppLocker findet man alle Logs betreffend Applocker. Nun finde ich Warnungen über Applikationen, die nicht gestartet hätten werden können.

Warnung: Damit die Regel auch greift, muss der Service Application Identity gestartet sein. Auch sollte das Startverhalten von Manual auf Automatic eingestellt werden. Ansonsten greifen die Regeln nicht.

Nun habe ich genügend Informationen, um für die alle Applikationen, die für die Remote Desktop Verbindung gebraucht werden, eine Regel zu erstellen. Nach der Anpassung der Regel und einem weiteren Test kann ich nun alle Regeln aktivieren.

Wenn ich nun versuche auf Applikationen und Scripts zuzugreifen, kriege ich eine Fehlermeldung, die mich darauf hinweist, dass ich keine Berechtigung zur Ausführung habe.

Dies geschieht bei allem, was ich versuche auszuführen – bis auf diejenigen Sachen, die ich explizit erlaubt habe. Das Regelwerk kann nun nach Belieben erweitert werden, um die Umgebung genau nach den vorgegebenen Sicherheitsrichtlinien zu gestalten.

Fazit

Microsofts AppLocker ist eine einfache Whitelisting Lösung, die man vor allem im Bereich Terminal Server einsetzen kann. AppLocker hat nicht den Umfang von den bekannten Lösungen – wie von AppSense oder triCerat -, bietet aber genügend Funktionalität, um ein Whitelisting-Konzept umzusetzen. Auch darf man AppLocker nicht als eigenständige Lösung betrachten, sondern immer als einen Teil des ganzen Hardening-Konzepts. Weitere Anregungen betreffend Windows Hardening hat Andrea Covello in seiner dreiteiligen Hardening-Serie veröffentlicht

Pascal Schaufelberger | G+ (1067 Wörter)

► 11.10.2012 – Formaler Prozess einer Config Review

Die Konfigurationseinstellungen einer Komponente sind massgeblich für die Sicherheit eben dieser und der eingebetteten Umgebung verantwortlich. Aus diesem Grund sind sogenannte Configuration Reviews ein zentraler Bestandteil moderner Sicherheitsüberprüfungen geworden. Das grundlegende Konzept dieses Analysemoduls haben wir im Beitrag Modell zur Umsetzung von Config Reviews dokumentiert. Das Ziel ist, unsichere, fehlende und ineffiziente Einstellungen frühzeitig erkennen und korrigieren zu können.

Klassische Onsite Reviews

Traditionell wurden Config Reviews mit sogenannten Onsite Reviews durchgeführt. Dabei setzt sich der Analyst vor das zu prüfende System und geht die dargebotene Konfiguration durch. Dazu ist in der Regel Zugriff auf die Administrationsoberfläche des eingesetzten Produkts erforderlich. Entweder werden unliebsame Einstellungen manuell dokumentiert oder mittels Screenshot festgehalten.

Eine solche Onsite Review fällt besonders dann langwierig aus, wenn umfangreiche und komplexe Konfigurationen überprüft werden sollen. Bei solchen bieten sich computergestützte Analysen an. In der Regel können die Konfigurationseinstellungen exportiert werden (z.B. Backup-Funktion), wobei sich dann auf diese Datenstrukturen die entsprechenden Analysen anwenden lassen.

Onsite Analyse

Computergestützte Analysen

Bei computergestützten Analysen muss mit verschiedenen Formaten von Konfigurationsdateien umgegangen werden können. Diese unterscheiden sich je nach Produkt oder eingesetzter Version. Aus Sicht eines Analysten sind auf Direktiven basierende Konfigurationen (z.B. Apache), kommandozeilenbasierte Formate (z.B. Cisco IOS), INI-Dateien (z.B. McAfee Webwasher) und XML-/JSON-Konstrukte (z.B. Astaro) besonders beliebt.

Diese lassen sich in der Regel direkt ansteuern und umformatieren (z.B. in eine relationale Datenbank ablegen). Dadurch kann besonders effizient und zuverlässig die entsprechende Untersuchung vorangetrieben werden.

Computergestützte Config Review

Kombination der Vorteile

Computergestützte Config Reviews stellen statische Tests dar, bei denen die Konfiguration für sich alleine betrachtet wird. Umliegende Einflüsse, wie zum Beispiel das einem Netzwerk zugrundeliegende Zonenkonzept, werden ausser Acht gelassen. Aus diesem Grund können solche Betrachtungen bisweilen zu theoretisch ausfallen – Die Resultate lassen sich dann manchmal nur mit zusätzlichem Aufwand mit den echten Gegebenheiten des Betriebs in Einklang bringen.

Um diese Diskrepanz verhindern oder wenigstens verringern zu können, sollte nach der computergestützten Analyse dennoch ein punktueller Onsite Review oder andere Analysetechniken (z.B. Netzwerkscan) stattfinden. Durch diesen Quercheck können Abweichungen und Missverständnisse frühzeitig identifiziert werden, wodurch die Qualität der schlussendlich abgelieferten Arbeit und des Reports hoch gehalten werden kann.

Fazit

Das Analysieren von Konfigurationseinstellungen ist wichtig für die sicherheitstechnische und betriebliche Vitalität einer Umgebung. Durch die Kombination verschiedener Betrachtungswinkel – dazu zählt die klassische Onsite Review und die computergestützte Analyse – können möglichst viele Vorteile erarbeitet werden. Dadurch lässt sich schlussendlich in effizienter Weise ein hochgradig akkurates Bild der gegebenen Situation zeichnen. Unsichere, fehlende und ineffiziente Einstellungen können damit frühzeitig erkannt und eliminiert werden.

Marc Ruef | G+ (481 Wörter)

► 04.10.2012 – Schwachstellen in WhatsApp

In den letzten Jahren wurde WhatsApp die meist gewählte Alternative zu herkömlichen Messenger Diensten wie SMS oder MMS. Innert kurzer Zeit erreichte die App – welche für Android, Blackberry, iOS, Nokia und WindowsPhone Geräte verfügbar ist – eine enorme Verbreitung. Im Oktober 2011 vermeldeten sie über 1 Mia. Nachrichten an einem Tag. Für Netzbetreiber ist die App ein Ärgernis, da sie weniger Umsatz mit SMS/MMS Dienste erzielen. Für Security Researcher ist die App ein Ärgernis, weil es scheint, als ignorierten die Entwickler jegliche Best Practice bei der Entwicklung. Nach 3 Jahren wurde erst eine Verschlüsselung eingebaut, der Status von Dritten konnte manipuliert werden und derzeit lesen wir überall über das Passwort Problem.

Das Passwort Problem

Kurze Zeit nach der Einführung von Verschlüsselung, im August 2012, gelangte die App erneut in die Kritik. Der Webentwickler Sam Granger veröffentlichte am 5. September in einem Blog-Post seine Forschungsresultate zum Authentisierungsmechanismus vom WhatsApp-Client an dessen Webfrontend-Server.

Für die Android Version von WhatsApp fand Granger heraus, dass als Passwort der MD5-Hash der umgekehrten IMEI verwendet wird. Eine Woche später veröffentlichte Ezio Amodio in einem Blog-Post, dass bei Apples iOS die MAC-Adresse der WLAN-Schnittstelle verwendet wird. Apple untersagt seinen Entwicklern seit einiger Zeit das auslesen der Gerätenummer.

Das Team von Heise-Security veröffentlichte in einem News-Artikel am 14. September 2012, wie einfach es Ihnen gelang mit Hilfe der PHP-basierten WhatsAPI Accounts zu übernehmen. Die Source von WhatsAPI wurde kurzzeitig vom Netz genommen. In der Commit-Meldung informieren die Entwickler von WhatsAPI, dass sie die API entfernt haben und in Kontakt mit dem Legal-Team von WhatsApp Inc. stehen. Dennoch portierte Sascha Gehlich, CEO FILSH Media GmbH, die API in node.js und veröffentlichte eine Webapplikation, in der man sich – durch Übermittlung der Telefonnummer und der zugehörigen IMEI/MAC-Adresse – am Webfrontend-Server von WhatsApp authentisieren kann. Die Verwendung statischer und bekannter Nummern als Passwort hat fatale Folgen. Mehr dazu im letzten Abschnitt dieses Artikel.

Passwortgenerieren unter Android

Um zu demonstrieren, wie leicht man an eine IMEI kommt, möchte ich hier zwei Wege unter Android vorstellen.

Physikalischer Zugriff auf das Gerät

Hat ein Angreifer die Möglichkeit, physikalischen Zugriff auf das Gerät zu erhalten, gibt es einfache Wege an die IMEI zu gelangen:

Durch Menuführung: Settings → About Phone → Phone identity
Durch Wahl der Kombination: *#*#4636#*#* → Phone Info
Durch Installation einer spezifischen App z.B.: Network Signal Info

Dummy-App mit entsprechender Funktion

Kann einem nichts ahnenden Benutzer eine App verkauft werden, die im Hintergrund verschiedene Informationen ausliest und dem Angreifer zusendet, sind keine Grenzen gesetzt. Gehen wir davon aus, der Angreifer kennt seine Zielperson nicht und benötigt daher die Telefon- und IMEI-Nummer. Mit diesen Informationen ist es möglich, dass der Account der Zielperson übernommen werden kann und er eine Social-Engineering Attacke auf dessen Kontakte fahren könnte.

IMEI auslesen (Benötigte Berechtigung: READ_PHONE_STATE):

TelephonyManager tm = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE);
String IMEI = tm.getDeviceId();

Telefonnummer auslesen (Benötigte Berechtigung: READ_PHONE_STATE):

TelephonyManager tm = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE);
String phone_no = tm.getLine1Number();

Telefonnummer der Kontakte auslesen (Benötigte Berechtigung: READ_CONTACTS):

Cursor phone = getContentResolver().query(ContactsContract.CommonDataKinds.Phone.CONTENT_URI, null, CONTACT-ID-CURRENT-CONTACT, null, null);
String phone_no = phone.getString(phone.getColumnIndex(ContactsContract.CommonDataKinds.Phone.NUMBER));

Risikobewertung

Beinahe wöchentlich gerät WhatsApp derzeit negativ in die Schlagzeilen. Genau so oft kann man Einschätzungen lesen, die sehr allgemein gehalten und ohne Differenzierung geäussert werden. Für die Teilaspekte der Problematik können folgende Aussagen zusammengefasst werden:

Grundsätzlich sollte eine App wie WhatsApp nicht für den Austausch von sensitiven Daten verwendet werden. Bezogen auf eine mögliches Hijacking eines Accounts bedeutet dies, dass auch in etablierten Unterhaltungen mit bekannten Kontakten keine sensitiven Daten übertragen werden sollten. Behandeln Sie die Kommunikation gleich vertrauensvoll, wie eine öffentliche Unterhaltung im Zug.
Im Szenario für Android Geräte wurde gezeigt, wie ein Angreifer auf die Daten zugreifen kann, die er benötigt, um die Authentisierung erfolgreich abzuschliessen. Der Schutz vor dem physikalischen Zugriff ist der einfachste. Lassen Sie keinen unbeaufsichten und unbefugten Zugriff auf Ihr Mobiltelefon zu.
Der Schutz vor einer App, welche die benötigten Daten ausliest und an den Angreifer überträgt, ist bereits schwieriger zu bewerkstelligen. Man sollte sich bewusst sein, welche App man installiert und welche Berechtigungen diese verlangen. Bei Zweifel über die Herkunft oder die Seriosität einer App sollte diese nicht installiert werden.
Es ist zwar schwieriger für ein Angreifer, eine App für Apple iOS Geräte im AppStore zu publizieren, welche die notwendigen Zugriffe ausführt. Im Gegensatz zu Google-Play für Android hat der AppStore von Apple einen Review-Prozess für neue Apps definiert. Negativ wirkt sich jedoch aus, dass bei einem iOS Gerät die MAC-Adresse für das Passwort verwendet wird. Dazu benötigt man keine auf dem Gerät installierte App mehr. Ein Mitschnitt eines Netzwerkverkehrs, der dem entsprechenden Telefon zugewiesen werden kann, genügt.

Zusammenfassung

Zusammenfassend kann gesagt werden, dass man nicht zwingend auf die App zu verzichten braucht. Man sollte sich jedoch über die Risiken im Klaren sein und sein Verhalten dementsprechend anpassen. Bei Verdacht, dass eine Nachricht von einem übernommenen Account stammt, sollten Sie sich beispielsweise via Telefon mit dem Kontakt in Verbindung setzen und die Echtheit überprüfen. Wie schon erwähnt, sollte der unbeaufsichtigte Zugriff auf ein Mobiltelefon unterbunden werden. Benutzer von Android und iOS Geräte sollten sich überlegen, welche App auf ihrem Gerät welche Berechtigung benötigt. Zusätzlich ist Benutzern von iOS Geräten anzuraten, midestens halböffentliche und öffentliche WLAN Netzwerke zu meiden bis das Problem behoben wurde. Da die MAC Adresse auch in einem verschlüsselten WLAN im Klartext übertragen wird.

Oliver Kunz | G+ (1024 Wörter)

► 28.09.2012 – Blog Digest September 2012

10 Ways Developers Put Databases At Risk (darkreading.com)
20 Questions to Ask Your Cloud Provider (blogs.mcafee.com)
Abusing Emoji in iOS and Your Mac (zachholman.com)
An update from VirusTotal (blog.virustotal.com)
Bank Fraud & ATM Security (infosecinstitute.com)
BYOA Brings New And Old Challenges For IT (blog.fortinet.com)
Data Discovery (blog.securestate.com)
Did I do that? (PenTest Faux Pas) (blog.spiderlabs.com)
Does Anything Really ‘End’ In Digital Security? (taosecurity.blogspot.com)
Do you allow XSS in your passwords? You should! (troyhunt.com)
Encryption Is Not the Answer to Security Problems (taosecurity.blogspot.com)
Getting in with the Proxmark 3 and ProxBrute (blog.spiderlabs.com)
How to Secure Windows 2000 (blog.securestate.com)
ICYMI: 0-day leaks from IPS (erratasec.blogspot.com)
My life after Anonymous: ‘I feel more fulfilled without the internet’ (guardian.co.uk)
PIN number analysis (datagenetics.com)
Quantum cryptography: yesterday, today, and tomorrow (arstechnica.com)
Researchers: Chip and PIN Enables ‘Chip and Skim’ (krebsonsecurity.com)
Security metrics: 5 tips (tripwire.com)
Source Code Review Grep Script (floyd.ch)
Testing Websites in Game Console Browsers (alistapart.com)
The First Few Months of Penetration Testing: What they don’t teach you (blog.spiderlabs.com)
Top 15 Cloud Security Best Practices (blogs.mcafee.com)
Using Google Trends to Analyse the Popularity of IT Security Certifications (infosecinstitute.com)
Vulnerability Spidey Sense – Demystifying PenTesting Intuition (blog.spiderlabs.com)
Web Application Defense: Bayesian Attack Analysis (blog.spiderlabs.com)
What can we learn from the social engineering contest? (newschoolsecurity.com)

Marc Ruef | G+ (425 Wörter)

► 18.09.2012 – 10 Jahre scip AG

Heute ist ein besonderer Tag: Wir feiern das 10-jährige Bestehen der scip AG!

Ein Jubiläum ist immer wieder ein Anlass, den Blick zurück schweifen zu lassen und die vergangenen Erlebnisse revue passieren zu lassen. So auch das heutige 10-jährige Jubiläum der scip AG.

10 Jahre sind bereits ins Land gezogen, seit die Firma scip AG auf dem Notariat Zürich (Aussersihl-Zürich) gegründet wurde. Der 18. September 2002 war ein ganz besonderer Tag und die Gründung einer Aktiengesellschaft der erste grosse Schritt zur Etablierung der Erfolgsgeschichte der scip AG. So einfach wie die Gründung einer Firma ist die Umsetzung gesetzter Ziele einer erfolgreichen Firma jedoch nicht.

Marc, Simon und Rocco

Basis

Hinter einem Akt steht immer ein Auslöser, ein Ziel und eine Menge an Energie. Der Firma scip AG liegt ein fundamentaler Gedanke zu Grunde:

Hinter der Arbeit stehen zu können, vorbehaltlos.

Diese sehr trivial verstandene Aussage ist auf den zweiten Blick nicht so trivial und benötigt eine grosse Menge an Energie, Überzeugung und Durchhaltewillen. Jeder, der in der Arbeitswelt zuhause ist, weiss wie schnell von diesem Weg abgekommen werden kann!

Nebst dem oben aufgenommenen fundamentalen Grund verfolgt die scip AG das einfache Ziel auch in 100 Jahren noch Bestand zu haben. Somit gilt das Folgende:

Entscheidungen und die daraus erfolgten Ergebnisse sind langfristig zu bedenken und nicht kurzfristigen Erfolgen nachzueifern.

Eine Utopie ein solches Vorhaben ohne die richtige Unterstützung aus dem Nichts heben zu wollen und erfolgreich durch stürmische Zeiten zu lenken. Es braucht dazu die besten Personen. Diese Menschen müssen dieselben Grundsätze stützen und hinter ihnen stehen.

Zur Etablierung der Denkweise und zur gemeinsamen Zielerreichung gelten scip AG intern diese Vorgaben:

professionelle Arbeit
nachhaltige Planung
transparente Arbeitsmethoden
absolute Unabhängigkeit
faire Anstellungsbedingungen
interessante Projekte
langfristige Kundenbeziehungen
Spass an der Arbeit

Die Mitarbeiter sind das Blut der scip AG. Ohne zufriedene, gut ausgebildetet, erfahrene und loyale Mitarbeiter steht alles still. Dank unseren Grundsätzen können sich unsere Mitarbeiter im Fachbereich entfalten und werden dabei aktiv unterstützt. Das genossene Vertrauen, die abweschlungsreichen Aufgaben und die interessanten Projekte ergeben Lebensqualität nebst der Arbeitswelt innerhalb der scip AG.

10 Jahre nach ihrer initialen Festlegung werden diese Grundwerte immer noch gelebt. Darauf sind wir zurecht stolz.

Rückblick

Die vergangenen 10 Jahre waren jedoch nicht nur einfach. Papier ist geduldig und egal wie schön sich etwas liest oder es in der Theorie klappt und auf Papier aussieht, niemand lebt von Luft und Liebe alleine. Projekte können nur durchgeführt werden, wenn Kunden von uns überzeugt sind und das Budget haben, entsprechende Projekte vergeben zu können. Die scip AG hat bereits zwei Wirtschaftskrisen mit signifikanten Budgetkürzungen unserer Kunden und erheblichen Änderungen der allgemeinen Wirtschaftslandschaft überstanden.

Rückblickend überwiegen eindeutig die posititven Erinnerungen. Ich möchte an dieser Stelle nun nicht einzelne Projekte herausheben. Jedes unserer Projekte hat nicht mit der Bestellung des Projekts begonnen oder wurde damit beendet, sondern hat immer den Anstoss zu einer langfristigen Kundenbeziehung gegeben. Ein Projekt muss ich hier dennoch zitieren:

So kann ich mich noch gut an unseren ersten Kunden erinnern. Die Unterzeichnung des ersten Vertrages auf scip AG Papier war ein unglaublicher Glücksmoment. Die Kundenbeziehung mit diesem Kunden ist noch immer vorhanden, fast 10 Jahre später.

Besonders positiv erinnere ich mich an die Momente, in denen ich angehende Mitarbeiter der scip AG ein erstes Mal kennen lernen durfte. Ein immer wieder schönes Gefühl. Wir haben zudem das grosse Glück eine sehr tiefe Fluktuation in der scip AG zu haben. Die Zusammenarbeit mit bis dato beinahe Unbekannten sowie das Miterleben des Findungsprozesses birgt viele schöne und einzigartige Erfahrungen.

Nebst dem Kennenlernen der Mitarbeiter ist auch die Interaktion mit neuen und bestehenden Kunden sehr inspiriend. Neue Gedanken werden ausgetauscht, neue Herausforderungen besprochen, neue Vorgaben erläutert und neue Lösungen gesucht. Es ist immer wieder eindrücklich in Firmen zu sehen, sind dies nun Banken, Non-Profit Organisationen, öffentliche Verwaltungen, Industrie, Logistik, international oder national tätig. Ein unglaubliches Glück, dass wir als scip AG solche Kunden haben und diese uns ihr Vertrauen aussprechen.

Resumée

Heute nach zehn Jahren kann ich folgendes kurzes Resumée niederschreiben:

Wir haben Erfolg, da wir nicht blenden, sondern liefern. Wir sind echt und versuchen die Bedürfnisse der Kunden zu verstehen und umzusetzen. Unser Kundenbeziehungen bauen auf Vertrauen und Langfristigkeit.

Danke

In den letzten 10 Jahren ist nicht nur die scip AG gewachsen, sondern auch die am Erfolg beteiligten Menschen haben sich weiterentwickelt. Ich bedanke mich ganz herzlich bei meiner Frau, welche mir Ihr Vertrauen und das nötige Verständis gegenüberbringt, bei meinen Kindern für Ihre Offenheit und Unbeschwertheit, bei meinen Eltern für Ihren Rückhalt und bei meinem Bruder für seine Unterstützung.

Ich bedanke mich ganz herzlich bei Rocco und Marc für ihr unglaubliches Vertrauen von der ersten Minute und durch alle Widrigkeiten – grazie! Herzlichen Dank an Stefan für sein Engagement und wertvolle Unterstützung. Im gleichen Atemzug bedanke ich mich bei Pascal, Andrea, Sean, Oliver und Ramona für den Einsatz, Leistung und Ihre Einstellung. Ebenso bedanke ich mich bei den Partnern, Kindern und Angehörigen unserer Mitarbeiter für Ihre Unterstützung und Geduld.

Vielen Dank an alle unsere Kunden für Ihr Vertrauen und den Möglichkeiten, welche Sie uns eröffnet haben als auch dem unglaublich wertvollen Erfahrungsaustausch mit ihnen.

Zukunft

Die kommenden Jahre der scip AG und die nächsten Schritte zur Verankerung unseres Erfolges sind geplant und teilweise schon in Angriff genommen worden. Dank unserer Mitarbeiter und unseren Kunden freue ich mich bereits heute auf den 18. September 2022 und meinen erscheinenden nächsten Rückblick: “20 Jahre scip AG”. Ich freue mich auf viele weitere erfolgreiche Jahre mit Euch!

Simon Zumstein

Simon Zumstein | G+ (978 Wörter)

► 13.09.2012 – Threat Management

Es gibt immer wieder mal die Situation, in der ich jemandem erklären muss, was IT Risk Management ist. Wenn ich dann das Gespräch beginne und sage, dass jeder von uns jeden Tag Risk Management betreibt, ernte ich meist ungläubige Blicke. Wir sehen uns jeden Tag zig Gefahren ausgesetzt. Sei es beim Überqueren der Strasse, beim Autofahren, im Sport, selbst zuhause.

Nur – im Gegensatz zur Informatik – kennen die meisten Leute die alltäglichen Gefahren. So braucht jemand beim Überqueren der Strasse nur seine Erfahrung abzurufen, um dann sogleich zu erkennen, ob es sicher ist loszulaufen. Das passiert meist sogar unbewusst, solange wir keine Anomalien um uns erkennen. Wenn aber nun die Unfallrate bei Fussgängern beim Überqueren der Strasse drastisch ansteigen und dementsprechend auch die mediale Berichterstattung zunehmen würde, würden wir uns zweimal überlegen, ob wir nun über die Strasse laufen. Im IT Risk Management beginnt auch alles mit der Erkennung der Gefahren, was ich in diesem Labs Artikel gerne etwas näher betrachte.

Was will man schützen?

Als erstes muss man wissen, was denn überhaupt in Gefahr ist. Bei dem in der Einleitung verwendeten Beispiel mit der Strassenüberquerung ist meine Gesundheit in Gefahr. Auf die Informatik übertragen, stellt sich hier die Frage, was für Wertbestände (Assets) in einem Unternehmen vorhanden sind und in Gefahr sein könnten. Diese Frage muss vom Business beantwortet werden. Als ehemaliger System Engineer weiss ich, dass man als Informatiker manchmal Annahmen trifft, die nicht immer von allen Abteilungen geteilt werden.

Am besten stellt man sich eine Liste mit den Wertbeständen zusammen. Wichtig ist, dass wir uns im IT Risk Management nur auf Dinge konzentrieren, die auch in irgendeiner Verbindung mit der Informatik stehen. Sei dies die Steuerung eines Roboters oder gespeicherte Kundeninformationen.

Hat man eine solche Liste zusammen, kann man die Wertbestände in Gruppen aufteilen. Zum Beispiel: Kundendaten, Forschungsergebnisse, Geld etc. Wichtig ist auch, welche Wertbestände welchen Stellenwert für das Unternehmen haben (Priorisierung) und was für ein Verlust daraus resultieren könnte.

Die Gefahr selbst

Als erstes greife ich wieder das Beispiel mit der Strassenüberquerung auf. Die Frage stellt sich nämlich, wie denn meine Gesundheit in Gefahr ist. Bei diesem Beispiel eine relativ einfach zu beantwortende Frage: Ich könnte angefahren werden – Die ganze Gefahr lautet also “Ich (meine Gesundheit) werde angefahren”.

Und nun zurück in die Informatik. Was kann alles mit meinen Wertbeständen passieren? Daten können gestohlen, Geld kann ertrogen und Steuerungen manipuliert werden. Wenn man das mit allen Wertbeständen durchspielt, kriegt man als Ergebnis eine Liste mit den Gefahren, denen das Unternehmen gegenübersteht.

Von wem geht die Gefahr aus?

Hier scheiden sich die Geister. Muss man wissen von wem eine Gefahr ausgeht? Bei meinem Beispiel der Strassenüberquerung ist für mich der Fall klar. Mich interessiert es nicht, ob ich von einem Bus, Auto oder Motorrad angefahren werde. Ich möchte gar nicht angefahren werden, also interessiert mich nur die Gefahr selbst.

In der Informatik kann es aber unter Umständen interessant sein zu wissen, von wem eine Gefahr ausgeht. Eine ganz simple Frage ist zum Beispiel, ob die Gefahr von Intern oder Extern ausgeht. Auch ist sehr interessant, über was für Mittel und Wissen ein Angreifer verfügt. Und wie stark man im Fokus des jeweiligen Angreifers als Unternehmen steht.

Threat Modeling

Hier ist der Punkt, wo sich die vielen Threat Management Ansätze unterscheiden und doch meistens eine Gemeinsamkeit aufweisen: Man möchte die grössten Gefahren gegen sein Unternehmen herausfinden. Die Ansätze, wie man das rausfindet, können sehr verschieden sein. Ich kann zum Beispiel eine Liste kreieren, bei der die Wertbestände in einen monetären Schätzwert gewandelt werden und dementsprechend priorisiert werden. Andere Modelle haben mathematische Ansätze, welche das Gefahrenpotenzial errechnen. Für welchen Ansatz und Modell man sich auch immer entscheiden mag, wichtig erachte ich, dass man sich überhaupt für eines entscheidet.

Als ein möglicher Ideengeber oder Leitfaden kann ich hier den Risk Management Guide for Information Technology Systems vom National Institute of Standards and Technology (NIST) empfehlen. Viele IT Risk Management Frameworks enthalten Elemente, welche in diesem Guide beschrieben werden oder sie sind sogar gänzlich auf diesem Guide aufgebaut.

Fazit

Threat Management ist ein wichtiger Bestandteil von IT Risk Management. Welches Modell man verfolgt, spielt eine sekundäre Rolle. Wichtig finde ich, dass wir uns bewusst sind, was wir schützen wollen und müssen. Wenn man sich den Gefahren bewusst ist, kann man sich auch besser absichern. Sei diese durch technische Massnahmen oder durch Schulung, wie man sich solchen Gefahren gegenüber verhält.

Pascal Schaufelberger | G+ (802 Wörter)

► 06.09.2012 – Windows 7 Stripping & Hardening, Part 3: Keep it Safe

Coming to an end, after stripping and hardening, there is the need to keep the system secure and clean. This may be a difficult task to accomplish, because you may need to to install and use new applications and of course the attack profiles changes over time. Therefore here some hints to help you out in this matter.

Apply Application Auditing

Microsoft just released a tool to the public, that was deployed for the internal application audit process, which was needed to be compliant to the Microsoft Security Development Lifecycle. This tools name is Attack Surface Analyzer

Basically this tool will create a snapshot of the system parameters in a known state: for example when you’re done with the OS stripping/hardening. After the first run the tool will start a multiple scan procedure and baseline your system. The system state will be saved in a .cab file and will be used as a reference once you’ll want to compare other systems state, for example after a software installation.

Below is a list of system areas changes & permissions settings that will be baselined (analyzed):

OS Area	Checked Items
System Information	`Running Processes, Executables Memory Pages, Windows GUI, Kernel Objects, Impersonation Tokens, Kernel Objects`
Service Information	`Services, Drivers`
ActiveX, DCOM, COM & File Registrations	`Registered ActiveX Controls, Registered DCOM Servers, DCOM Default Permissions, Registered COM Controls, File Registration`
Internet Explorer	`Pluggable Protocol Handlers, Silent Elevation Entries, Preapproved Controls, Browser Helper Objects, Internet Explorer, IE Zones, IE Actions Policy`
Network Information	`Open/Used Ports (TCP/UDP), Named Pipes, RPC Endpoints, Network Shares, Network Interfaces`
Firewall	`Rules, Profiles, Service Restriction Rules & Authorized Application`
System Environment, Users & Groups	`PATH Entries, Accounts, Groups, Group Membership, Account Privileges`

There is a lot to check and to be compared, so don’t worry if it takes some time to execute all those tasks, just remember to stop all processes and programs not needed when you run the first baseline scan… Now just make the test:

Ensure you’re have a clean OS state and start the Attack Surface Analyzer. The first time you have to select scan to generate the initial baseline
Now you’ll see that several scanning processes are starting…
Once the scan is done you can start making change to your system installing a new application. When you’re done, restart the Attack Surface scanner and select the comparing baseline created before (it will be selected by default)
The analysis will take a while before displaying the results
After the comparing process a report is created and displayed in the browser…
...dig into the detailed report for more information

You may wonder how much application and tools may change your system state and consequently the attack surface of your system!

Of course you can compare different scan status and (as you may already figure out) you can use this tool for forensics analysis, if you manage to have a clean baseline of the analyzing system.

The Attack Surface Analyzer comes free of charge and supports following OS:

Windows Vista / Windows 7 / Windows 8
Windows Server 2008 / 2008 R2 / 2012
Windows Server Core 2008 / 2008 R2 / 2012

You can run the scan also in command mode to create the baseline files (.cab), but unfortunately you’ll need to have the .NET Framework 4 to compare the baselines and to generate the reports. At best you’ll use a dedicated workstation for the reporting generation task.

Application Whitelisting

Another way to keep your system clean and safe is to provide a known list of application that may run on your machine, this approach is known as Whitelisting. As the words says, only application listed as known (and safe) are able to execute.

It really is a possibility to achieve a very secure operation state but it also need a long tuning session where you define and configure all application needed to run and its required executables. The Application Auditing explained above really helps in this task and is a prerequisite to accomplish successful Whitelisting.

Following are key points for Application Whitelisting:

Executables integrity (the binary code has not changed since the auditing)
Executables path integrity (knowing where the binary is)
Executable permission profile (define what the binary code is able to do)

In Windows you’ll use the Group Policy Editor (GPO) to define and enforce Application Whitelisting.

We just scratched the surface of the possibilities with Application Whitelisting, more on this item may be discussed in dedicated Lab article.

Summary

In this article we covered the security procedure on keeping a hardened system secure over time. Now this series has reached the end, but stay tuned for future labs articles.

Andrea Covello | G+ (845 Wörter)

► 30.08.2012 – Blog Digest August 2012

10 Tips For Protecting Mobile Users (darkreading.com)
5 Design Tricks Facebook Uses To Affect Your Privacy Decisions (techcrunch.com)
Attack Surface Analyzer 1.0 Released (blogs.msdn.com)
Backup Security Best Practices (blogs.mcafee.com)
Bad password choices: don’t miss the point (blog.eset.com)
Brainfuck beware: JavaScript is after you! (patriciopalladino.com)
Bring it on: Companies bring sensitive data to the cloud despite doubts (securitybistro.com)
Bypassing CAPTCHAs by Impersonating CAPTCHA Providers (blog.opensecurityresearch.com)
Dilbert Comic Strip – Government Agencies (dilbert.com)
Divide and Conquer: Cracking MS-CHAPv2 with a 100% success rate (cloudcracker.com)
Ending mixed scripting vulnerabilities (blog.chromium.org)
Endpoint Security Management Buyer’s Guide (securosis.com)
Flamer Analysis: Framework Reconstruction (blog.eset.com)
Information Security: Analysis of the FinFisher (community.rapid7.com)
Introduction to HTTP Response Headers for Security (resources.infosecinstitute.com)
I Was a Teenage Hacker (codinghorror.com)
Mobile Security Experts on BYOD (veracode.com)
No, ‘hacker’ really does mean ‘hacker’ (erratasec.blogspot.com)
Not So Random Numbers. Take Two (blog.ptsecurity.com)
Overreaction and Overly Specific Reactions to Rare Risks (schneier.com)
Plaintext Caching with iOS Document Interaction APIs (blog.gdssecurity.com)
Pragmatic WAF Management: Policy Management (securosis.com)
Pragmatic WAF Management: the Trouble with WAF (securosis.com)
Quality Coding Takes A Break For The Holidays. But Why? (threatpost.com)
Spam from an Android botnet (blogs.msdn.com)
Stamping Out Hash Corruption, Like a Boss (blog.spiderlabs.com)
Surprises in our advanced threat awareness survey (blog.fireeye.com)
Tackling Modern Malware (blog.redscan.com)
The Importance of Security Engineering (schneier.com)
The Password Dilemma – Unique and Complex is the Key (blog.sucuri.net)
Web Application Fingerprinting (pentestlab.wordpress.com)
Why passwords have never been weaker and crackers have never been stronger (arstechnica.com)

Marc Ruef | G+ (491 Wörter)

► 23.08.2012 – Google Chrome Extensions für Penetration Tests

Eine Vielzahl der Client/Server-basierten Anwendungen werden heutzutage als Webapplikationen umgesetzt. Der Grund dafür ist vielfältig. In erster Linie kann der Nutzen der etablierten Techniken nicht bestritten werden. Auf der Basis webfähiger Programmiersprachen lassen sich innert kürzester Zeit Anwendungen entwickeln, die sich komfortabel über bestehende Browser in einem Netzwerk oder über das Internet nutzen lassen.

Sodann wird es für Penetration Tester immer wichtiger, sich mit Webapplikationen auseinanderzusetzen. Die manuelle Prüfung individueller Lösungen kann jenachdem sehr aufwendig sein. Durch die Modularität des beliebten Webbrowsers Google Chrome ist es möglich, zusätzliche Extensions zu installieren und damit den Browser für derlei Tätigkeit zugeschnittene Funktionen zu erweitern.

Nachfolgend sollen einige der nützlichsten Google Chrome Extensions für Web Application Penetration Tests – ähnlich unserer Liste für Firefox Addons – vorgestellt werden. Die gezeigte Tabelle unterscheidet je nach Anwendungszweck. In der letzten Spalte wird die Bewertung der Extension in einer Skala von 1-5 ausgewiesen.

Allgemein / Debugging
Web Developer	Diverse Funktionalitäten für Entwickler	★★★★★
Pendule	Diverse Funktionalitäten für Entwickler	★★★★★
Firebug Lite	Debugging und Anpassung von Webseiten	★★★★★
Tampermonkey	Dynamische Anpassung von Webseiten	★★★★★
XPath Helper	Extrahieren von XPath-Informationen	★★★☆☆
Modifikation von Anfragen
Dev HTTP Client	Erstellen eigener HTTP-Anfragen	★★★★☆
Request Maker	Erstellen eigener HTTP-Anfragen (ähnlich Burp)	★★★★☆
Proxy SwitchySharp	Schnelles Wechseln von Proxies	★★★☆☆
Change HTTP Request Header	Ändern der HTTP Header Zeilen	★★★☆☆
Edit This Cookie	Erstellen und Anpassen von Cookies	★★★☆☆
Referer Control	Manipulieren des Referer	★★☆☆☆
Emulation
Mozilla Gecko Tab	Anzeigen einer Seite mit Mozilla Gecko (Firefox Engine)	★★★☆☆
IE Tab	Anzeigen einer Seite mit Internet Explorer Engine	★★★☆☆
Sniffing
HTTP Headers	Anzeigen der HTTP-Kommunikation	★★★☆☆
Caching und Blocking
Adblock Plus	Entfernen von Seitenelementen	★★★★★
ScriptNo	Deaktivieren aktiver Inhalte	★★★★☆
Cache Killer	Löschen des lokalen Cache vor jeder Anfrage	★★☆☆☆
Footprinting und Auswertung
BuiltWith Technology Profiler	Identifikation eingesetzter Technologien	★★★★☆
TinEye Reverse Image Search	Identifikation von Bildquellen	★★★★☆
Passive Cache	Gelöschte Seiten im Cache anzeigen	★★★★☆
Web Cache	Gelöschte Seiten im Cache finden	★★★☆☆
Port Scanner	Durchführen von simplen TCP-Portscans	★★★☆☆
Automatisiertes Testing
Websecurify	Scanner für Verwundbarkeiten	★★★★★
XSS Rays	Tool für Cross Site Scripting	★★★★★
iMacros for Chrome	Automatisierung mittels Makros	★★★★★

Einmal mehr gilt auch hier, dass Extensions nur nach sorgfältiger Prüfung nach etwaiger Malware installiert und ausgeführt werden sollten.

Marc Ruef | G+ (555 Wörter)

► 16.08.2012 – Erfahrungen aus der Information Security

Durch meine Arbeit als Security Consultant bei der scip AG habe ich die Branche der Information Security besser kennengelernt und Einblick in Dinge erhalten, die ich ausserhalb dieses Bereichs noch nicht gesehen habe.

Da ich bisher, wie viele andere, die in die Informationssicherheit einsteigen wollen, aus beruflicher Sicht hauptsächlich als System Engineer gearbeitet habe, möchte ich für Neueinsteiger einen kurzen Erfahrungsbericht vorstellen.

Information Security

Menschen, die in der Informationssicherheit tätig sind, haben meist eine hohe Affinität zu Sicherheit im Allgemeinen. Es ist eine Leidenschaft, die sie beruflich ausleben können.

Durch die Tatsache, dass viele Menschen Sicherheit bewusst ignorieren oder deren Wichtigkeit herunterspielen, bleibt die Anzahl an Leuten, die in dieser Branche tätig sind, vergleichsweise klein.

Dieses Tatsache ist beispielsweise IT-Supportern bestimmt schon mehrmals untergekommen:

User setzen beim erstmaligen Gebrauch kurze Passwörter
Diese Passwörter werden nach Ablauf lediglich inkrementell geändert
Nach Änderung der Passwörter wird der IT-Support aufgeboten, die frisch vergessenen Passwörter erneut zurückzusetzen

Eine weitere beliebte Geschichte sind nicht gesperrte Arbeitsrechner. Seit ich die Funktion der Rechnersperre kenne, nutze ich sie sobald ich mich von meinem Rechner entferne. Umso erstaunter bin ich, dass es Leute gibt, die einen PC stundenlang unbeaufsichtigt lassen. Und kommt dann noch das Passwort auf dem Post-it am Bildschirm dazu ist es geschehen. In solchen Situationen war ich häufig der Einzige der sich daran störte und häufig eine Nachricht auf einem Editor hinterliess, um auf die unsichere Gewohnheit aufmerksam zu machen.

Noch erstaunlicher wurde es dann, wenn die betroffenen Personen ausriefen und sich darüber aufregten. Ganz so, als ob ihr Verhalten in bester Ordnung war und sie dies nicht einmal in Frage stellten. Natürlich konnte ich dies nicht verstehen. Denn genauso gut hätte ich via USB-Stick sämtliche geheimen Firmendaten, auf die die Betroffenen Zugriff hatten, einfach stehlen können.

Beispiele für unsicheres Verhalten gibt es also unzählige. Alle Personen, die meine Situation kennen oder nachvollziehen können, haben also ein anderes Verhältnis zu Sicherheit wie der durchschnittliche User (und schlimmstenfalls gar Administrator).

Dieses Verhältnis macht einen grossen Teil der Affinität zur Informationssicherheit aus. Einsteiger ohne diese Affinität werden wohl umso grössere Schwierigkeiten haben, sich zurechtzufinden, als jene mit.

Neue Trends

Die IT ist an sich schon eine sehr schnelllebige Branche. Was heute noch neu ist, wird morgen bereits mit etwas anderem ersetzt werden. In der Informationssicherheit ist diese Schnelllebigkeit noch extremer. Entsprechend bedeutet dies auch, dass man immer dazu bereit sein muss, Neues zu lernen und sich zu erarbeiten. Es gilt, wichtige Ereignisse als solche zu erkennen und entsprechend zu reagieren.

Ein Beispiel dafür ist der im Mai gefundene Schädling Flame. Viele Reaktionen waren masslos übertrieben und entbehrten jeglicher grundlegender Fachkentnnisse. Stefan Friedli fasste es schlussendlich bestens zusammen:

Für die meisten Benutzer und Firmen ändert sich nichts, ausser einem neuen Eintrag in der Datenbank ihres Virenscanners. (Quelle: 20 Minuten Online)

Ein weiteres Beispiel eines neuen Trends wäre die sogenannte BYOD-Strategie (Bring Your Own Device), die seit der Einführung des iPhone grassiert. Der Trend führt dazu, dass immer mehr Mitarbeiter mit privaten Geräten geschäftliche Daten bearbeiten. Diese Geräte stehen natürlich nicht unter der Kontrolle der für die Daten zuständigen Administratoren und sind aus dieser Sicht ein nicht zu unterschätzendes Gefahrenpotenzial.

Da herkömmliche Schutzstrategien nicht mehr greifen, müssen neue erstellt, evaluiert und eingeführt werden. Dies natürlich im besten Falle so schnell wie nur möglich.

Grundwissen

Alle oben besprochenen Eigenschaften sind sicher sehr wichtig und nicht zu unterschätzende Faktoren. Allerdings setzt die Informationssicherheit ein sehr solides IT-Grundwissen voraus, ohne das es nicht möglich ist, viele Abläufe zu verstehen. So sollten Begriffe wie beispielsweise Three-Way-Handshake, asymmetrische und symmetrische Verschlüsselung, Exploit, Vulnerability, Risk Assessment oder Firewall (unter vielen, vielen weiteren) nicht unbekannt sein und zumindest im Ansatz verstanden sein.

Wer über kein Grundwissen verfügt wird nicht in der Lage sein, Entscheidungen zu treffen, die dieses Grundwissen dringendst voraussetzen, und wird früher oder später eine Fehlentscheidung treffen, die möglicherweise gravierende Folgen mit sich zieht.

Grundwissen beinhaltet für mich allerdings nicht nur technisches Wissen, sondern auch Wissen über Firmen und Erfahrungen mit der Art und Weise, wie sie funktionieren. Ein rein akademischer Ansatz, der nur mit idealen Voraussetzungen funktioniert, wird in der realen Wirtschaft zwangsläufig versagen.

Des weiteren beinhaltet Grundwissen für mich auch ein Verständnis der menschlichen Psyche. Wer nicht versteht, dass ein Verwaltungsratsmitglied einen anderen Kommunikationsansatz wie ein Netzwerkadministrator benötigt, wird trotz bestem technischen Wissen und ausgezeichneter, korrekter Analyse häufig erfolglos sein.

Community

Schlussendlich empfiehlt es sich, sich in die Community einzubringen. Twitter bietet sich hierfür bestens an, da viele Profis der Branche über Twitter direkt ansprechbar sind und viel Wissen darüber verteilen und zur Verfügung stellen.

Ein Einstieg wird auch erleichtert, wenn man keine unbekannte Persönlichkeit ist, sondern vorgägnig auf sich aufmerksam gemacht hat. Vorzugsweise nicht mit peinlichen Nacktfotos, wie es heute unter Hollywoodsternchen verbreitet ist, sondern mit wohlüberlegten Fragen, Überlegungen und Äusserungen zu aktuellen Themen und Anlässen.

Auch an Konferenzen, Treffen und ähnlichen Anlässen lassen sich gut Kontakte knüpfen. Im November findet beispielsweise zum 3. Mal die hashdays-Konferenz in Luzern statt, an der man hautnah die neusten Entwicklungen aus der Community präsentiert bekommt.

Wer sich aktiv einbringt, wird auch etwas dafür zurückerhalten. Allerdings wird der Einstieg nicht einfach passieren. Man muss sich anstrengen und am Ball bleiben, um nicht in der Flut von “Eintagsfliegen” unterzugehen.

Schlusswort

Die Branche der Informationssicherheit ist ein Kapitel für sich. Wo IT ist, ist auch Security. Und dies ist im heutigen Informationszeitalter nun mal überall.

Diese Tatsache macht die Informationssicherheit zu einem der interessantesten Gebiete, auf denen man arbeiten kann, denn man erhält Einblick in die unterschiedlichsten Branchen, Systeme und Kulturen. Für alle Einsteiger oder die, die einsteigen wollen: Bleibt dran, gebt nicht auf und geht stetig Euren Weg. Denn der Weg ist das Ziel!

Sean Rütschi | G+ (1036 Wörter)

► 14.08.2012 – Las Vegas 2012: Teil 2 – DEFCON 20, BSidesLV

Las Vegas

Wenn die Opt-Out Rate am McCarran Airport in Las Vegas schlagartig in die Höhe schiesst, dann heisst das meistens eines: Es ist Sommer, Zeit für die alljährlichen Sicherheitskonferenzen Blackhat, BSides Las Vegas und DEFCON. Für unsere Branche sind die Events, sowohl aus inhaltlicher Sicht wie auch im Hinblick auf Networking, von essentieller Bedeutung. Naheliegenderweise hat es sich die scip AG auch dieses Jahr nicht nehmen lassen, vor Ort zu sein. Stefan Friedli, der selber schon in Vegas präsentieren durfte, fasst seine Erlebnisse in diesem Artikel zusammen. Den ersten Teil, der sich mit der BlackHat Security Conference beschäftigt, finden Sie hier

Es ist schon eine interessante Konstellation, die die drei Konferenzen zur Sommerzeit in Las Vegas bilden: Die BlackHat, die mit ihren relativ hohen Ticketpreisen ein eher business-orientiertes Publikum anzieht bietet meistens exklusiven Inhalt, wirkt aber relativ emotionsfrei. Man bemüht sich, Professionalität zu emphasieren und in der Sponsor Hall bemühen sich diverse Hersteller und Sponsoren darum, möglichst viele Besucher auf die eigenen Produkte aufmerksam zu machen, in der Hoffnung den einen oder anderen grossen Lead an Land zu ziehen. Die BSidesLV versucht seit Jahren, ein kostenloses Alternativprogramm für all jene zu bieten, denen die BlackHat entweder zu teuer oder zu kommerziell/untechnisch geworden ist. Mit Erfolg, denn auch dieses Jahr war das Artisan Hotel, das bereits letztes Jahr als Kulisse für die BSides diente, prall gefüllt.

Und trotz der non-kommerziellen Natur konnte die BSides auch dieses Jahr wieder mit hochqualitativen Inhalt punkten: HD Moore präsentierte einen Talk mit dem klangvollen Titel “Empirical Exploitation” sowie einen weiteren mit dem nicht weniger poetischen Namen “Global Loot”. Ian Amit, der bereits letzte Woche Erwähnung für seinen vielbeachteten BlackHat Talk fand, präsentierte denselben Inhalt, in leicht Zielgruppen-optimierter Form. Aber auch sonst präsentierte sich ein durchaus attraktives, abgerundetes Programm im Artisan. Die Schedule sowie Informationen zu den Talks sind auf der offiziellen Webseite der BSides Las Vegas einsehbar.

Am meisten Aufmerksamkeit dürfte dieses Jahr allerdings mit Abstand die grösste der drei Konferenzen abgestaubt haben: Die DEFCON feierte ihr 20-jähriges Bestehen und zog zu diesem Anlass natürlich auch alle Register. So warteten fünf prall gefüllte Tracks auf die Besucher, die bereits lange vor Türöffnung Schlange standen, um einen der begehrten elektronischen Badges zu ergattern, nachdem die Verfügbarkeit der “regulären” Badges in vergangenen Jahren öfters mal bereits nach kurzer Zeit zur Neige ging.

Besonders viel Beachtung erhielt zu Anfang der Konferenz der Direktor der NSA, General Keith B. Alexander, der in seinem Talk mit dem Titel “Shared Values, Shared Responsibility” um die Gunst der Anwesenden buhlte und dabei auf überraschend viel Zuspruch stiess. In Jeans und T-Shirt erschienen, erläuterte Alexander die Aktivitäten des Geheimdienstes und forderte die Hackercommunity zur Mitarbeit auf. Die Reaktionen waren, wie zu erwarten war, gemischt, trotzdem dürfte das öffentliche Auftreten eines Geheimdienstlers, das in der 20-jährigen Existenz der DEFCON eine Premiere darstellt, einen Meilenstein in deren Geschichte darstellen.

Ein anderer Talk, der vor allem in unserem Feld durchaus einiges an Beachtung erhalten dürfte, kam von Moxie Marlinspike, der demonstrierte wie PPTP VPN Authentisierungen via MS-CHAPv2 binnen absehbarer Frist gecrackt werden können, sofern ein Mitschnitt des Traffics vorliegt. Gerade viele kleinere Firmen, die auch heute noch PPTP einsetzen, dürften hier mittelfristig auf Probleme stossen, sobald entsprechende Tools auch für weniger versierte Angreifer frei zugänglich sind. Entsprechende Proof of Concepts kursierten bereits kurz nach der Präsentation in den üblichen Kanälen.

Während meine Auflistung in diesem Rahmen bei weitem nicht alle erwähnenswerten Talks abzudecken vermag, so komme nicht darum herum kurz auf Felix “FX” Lindner’s Talk zu verweisen. Unter dem Titel “Hacking [redacted] Routers” enthüllte FX verschiedene Probleme, die vor allem SOHO-Router des massiven chinesischen Herstellers betreffen. Was durchaus amüsant und interessant präsentierte wurde, ist hoffentlich ein Wake-up Call für den Grosslieferanten: Weder ein Kontakt für Sicherheitsfragen ist vorhanden, noch hat der Konzern jemals ein Sicherheitsadvisory veröffentlicht. Huawei hat inzwischen reagiert und angekündigt, man würde gemeinsam mit der britischen Regierung an der Sicherheit der Produkte arbeiten. Inwiefern dies ein Trost für all jene ist, die bereits mit entsprechenden Produkten arbeiten und unter der mangelhaften Qualität leiden, das bleibt offen.

Zurück zur DEFCON als solches: Neben den Präsentationen gab es natürlich, wie jedes Jahr, auch viele andere Dinge zu sehen. So gab es auch dieses Jahr ein Lockpicking- und ein Hardware-Hacking Village und in der Vendor Area boten diverse Händler ihre Waren – T-Shirts, Hardware, Lockpicks, … – feil. Und dann gab es da natürlich auch noch die zahlreichen Social Events, die nach den langen Konferenztagen auch noch für entsprechende lange Nächte sorgten. Unvergessen ist die Performance der israelischen Psy-Trance-Electro Band “Infected Mushroom”, die im Rahmen der IOActive Freakshow ein unglaublich stimmungsvolles Set ablieferten.

So verging auch diese Woche in Vegas überraschend schnell und bald trat ich den langen Rückflug via Toronto nach Zürich an um dann direkt für eine Woche in die Schweizer Alpen zu fahren, quasi als Kompensation für die Reizüberflutung der bunten und blinkenden Stadt in der Wüste Nevadas. Eine Stadt, in die ich jederzeit gerne reise, solange ich sie nach einiger Zeit auch wieder verlassen kann.

Stefan Friedli | G+ (918 Wörter)

► 08.08.2012 – Las Vegas 2012: Teil 1 – BlackHat

Las Vegas

Gut 10’000km lang ist der Flug von Zürich nach Las Vegas via Los Angeles. Die SWISS LX40, angeboten im Codeshare mit United Airlines, legt dabei die längste Direktdistanz im derzeitigen Streckennetz der Schweizer Fluggesellschaft zurück. Gut 13 Stunden dauerte der Flug an diesem Montag. Die Fähigkeit, in einem Flugzeug erholsamen Schlaf zu finden, fehlt mir leider vollends. Dementsprechend schaute ich mir Joss Whedons “Avengers” noch einmal an, beendete das mitgebrachte Buch und ging dann dazu über mir noch einmal die Schedule der anstehenden Events anzuschauen und meine Favoriten herauszupicken. Nachdem dies nicht mein erstes Jahr in Vegas war, weiss ich dass es keinen Sinn macht sich einen allzu ambitionierten Plan aufzustellen: Erstens kommt es anders und zweitens als man denkt. Gerade im Kontext zu Security- und Hackerkonferenzen beweist diese Floskel seine Gültigkeit Jahr für Jahr. So bezahlt man seine Ambition, möglichst viele Talks zu sehen oft mit verpassten Adhoc-Sessions, ungeführten Gesprächen und verpassten neuen Kontakten. Spontanität hilft, dementsprechend hatte ich meine Favoriten gewählt und beschlossen, den Rest auf mich zukommen zu lassen.

Für den ersten Teil der Woche stand der industrielastige Grossevent Blackhat an. Da unser Labs Blog zu den meistgelesenen Ressourcen zum Thema Informationssicherheit im deutschsprachigen Raum gehört, kamen wir dieses Jahr in den Genuss eines kostenlosen Pressebadges. Die Blackhat Briefings boten auch dieses Jahr wieder eine Fülle an Inhalt, meine vorgängig genannten Favoriten hier waren SexyDefense – Maximizing the home-field advantage, von Iftach Ian Amit und Don’t Stand So Close To Me: An Analysis of the NFC Attack Surface von Charlie Miller. Beide Talks konnten überzeugen und wurden vom Publikum gesamthaft gut aufgenommen.

Ganz anders erging es Dallas De Atley von Apple, der den zweiten Tag mit seinem Talk zum Thema iOS Security eröffnen sollte. Manch einer, der in den letzten Monaten die Freude hatte, sich mit der Integration von iOS Devices in globale Unternehmensnetzwerke auseinanderzusetzen, – ich zähle mich zu ihnen – wartete gespannt auf neue Insights von De Atley, der bei Apple immerhin in führender Position für die Sicherheit des mobilen Betriebssystems zuständig ist. Sie alle wurden bitter enttäuscht. Während 50 Minuten rezitierte der Vortragende das, vor einigen Monaten veröffentlichte, Whitepaper zur iOS Security und ging dabei keinen Schritt über die bereits bekannten Informationen hinaus, was für Kopfschütteln im Publikum sorgte. De Atley komplettierte seine enttäuschende Vorstellung damit, dass er nach Abschluss seiner Präsentation mehr oder minder fluchtartig die Bühne verliess, ohne – wie es eigentlich üblich wäre – auch nur eine einzige Frage zu beantworten.

Positiv überraschen konnte dafür die vorhergegangene Keynote, bei der der bekannte Security-Blogger Brian Krebs (Krebs on Security) ein Interview mit Neal Stephenson, Author zahlreicher Romane wie “Snowcrash” oder “Reamde”, führte. Stephenson, der eigentlich mit der “realen” Informationssicherheitswelt nur limitierte Berührungspunkte hat, beeindruckte dabei durch überlegte Statements und Ansichten zu einer Vielfalt von Themen, die in einem vernetzten Zeitalter von Signifikanz sind.

Neben all dem Inhalt, der auf insgesamt 7 Tracks (exkl. Workshops) präsentiert wurde und hier in Form von Slides/Whitepapers online betrachtet werden kann, bot die Blackhat natürlich auch zahlreiche Möglichkeiten zum Networking. So gab Microsoft dieses Jahr, nach eigenen Aussagen, für ihre “Researcher Appreciation Party” mehr Geld aus, als Kim Kardashian für ihre Geburtstagsparty und erhob entsprechend auch den Anspruch, damit eine bessere Party zu haben als das skandalerprobte It-Girl. Die Meinungen dazu dürften auseinandergehen. Doch so waren die Nächte in der “City of Sin” auch dieses Jahr lang und manch einer war froh, wenn er endlich im Taxi zum eigenen Hotel sass, in dem der – erst gerade zur Frühschicht erschienenene und entsprechend muntere – Taxifahrer amüsiert erzählt, er würde während der Woche in der “die Hacker da sind”, nie einen ATM benutzen. Recht hat er, vermutlich.

Nächste Woche folgt die Fortsetzung dieses Artikels: DEFCON/BSidesLV

Stefan Friedli | G+ (816 Wörter)

► 02.08.2012 – Schwachstellen finden mittels Fuzzing

Bei Fuzzing handelt es sich um eine Technik im Bereich des Software-Testing. Dabei werden in semi-automatisierter oder automatisierter Weise Eingaben getätigt, um mittels fehlerhafter Zugriffe unerwartete Reaktionen zu provozieren.

Die Geburt des Begriffs wird Barton Miller zugeschrieben, der 1988 an der University of Winsconsin eine entsprechende Arbeit mit dem Titel Operating System Utility Program Reliability – The Fuzz Generator durchgeführt hat. Doch schon 1983 wurde für den Macintosh durch Steve Capps eine Applikation namens The Monkey entwickelt, mit der entsprechendes Fuzz Testing in der Software MacPaint umgesetzt werden konnten.

Fuzzing ist damit eigentlich eine relativ alte Technik, die aber erst ab ca. 2005 den zaghaften Durchbruch in der IT-Security Branche geschafft hat. Heutzutage gilt es als fester Bestandteil systematischer Sicherheitsüberprüfungen.

Ein System erwartet immer irgendwelche Eingaben. Diese haben eine bestimmte Struktur. Zum Beispiel erwartet in einem Formular das Feld Postleitzahl für Schweizer Adressen stets vier Ziffern der folgenden Form (als regulärer Ausdruck):

([0-9]{4}) = { 0000, 0001, ..., 9999 }

Beim Fuzzing werden nun Eingaben getätigt, die gezielt diese Anforderungen verletzen. In diesem Beispiel bieten sich an:

Test	Beispiel
kürzer als 4 Zeichen	`111_`
länger als 4 Zeichen	`1234567890(...)`
Buchstaben	`123A`
Sonderzeichen	`123*`
Minuswerte	`-123`
konstruierte Werte	`1+23` (wird nach Berechnung als `24` gehandelt)
leere Eingabe	`____`
nicht abgeschlossene Eingaben	(gibts in diesem Beispiel nicht)
reservierten Mustern	HTML-Anweisungen, SQL-Abfragen, ...
alternative Codierungen	UTF-8, Unicode, ...

Dadurch soll ein Verhalten provoziert werden, auf das das Zielsystem nicht ausgelegt ist. Wenn zum Beispiel die PLZ eingegeben und das Formular abgeschickt wurde, dann soll direkt die Ortschaft aus einer Datenbank geholt und dargestellt werden. Doch was wird geholt, wenn 123* eingegeben wird? Mögliche Resultate, denen eine generische Kritikalität beigemessen wird, sind:

Sicherheitstechnisch Positiv
passed	allgemeine Fehlermeldung (bevorzugte Lösung)
low	es passiert gar nichts (vom Betrieb her aber unerwünscht)
Sicherheitstechnisch Negativ
medium	technische Fehlermeldung (z.B. Informationen zur internen Verarbeitung)
medium	erster Treffer wird geladen
medium	letzter Treffer wird geladen
medium	“zufälliger” Treffer wird geladen (z.B. je nach Sortierung)
high	alle Treffer werden geladen (erweiterte Zugriffsrechte)
high	auf geschützte Daten zugreifen (erweiterte Zugriffsrechte)
high	geschützte Funktionen benutzen (z.B. Code ausführen)
high	Datenverarbeitung blockieren (Denial of Service)

In einer guten Sicherheitsüberprüfung wird mit intelligentem Fuzzing gearbeitet. Dies erfordert aber viel Verständnis für die eingesetzten Technologien. Das simple Abstützen auf irgendwelche Vulnerability Scanner gewährleistet nicht, dass derlei Tests mitberücksichtigt werden. Gerade wenn individuelle Software-Lösungen zum Tragen kommen, muss ein zielgerichtetes Fuzzing angestrebt werden.

Marc Ruef | G+ (442 Wörter)

► 26.07.2012 – Blog Digest Juli 2012

4 Reasons Why IT Security Needs Risk Management (darkreading.com)
Accelerating Password Recovery: the Addition of FPGA (blog.crackpassword.com)
Android Security 101: A Short Guide (blog.fortinet.com)
App detects compromised, jailbroken iOS devices (scmagazine.com.au)
Appeals Court Calls Bank’s Security ‘Commercially Unreasonable’ (threatpost.com)
Apple Security ‘Grows Up’ With Pair Of Malicious Threats (blog.fortinet.com)
Apple’s Mountain Lion to offer automatic security updates (appleinsider.com)
A Step-by-Step Guide for Choosing the Best Scanner (infosecisland.com)
Creating Metasploit Exploits (pentestlab.wordpress.com)
Decoding Common XOR Obfuscation in Malicious Code (isc.sans.edu)
How much data? Apache, Ubuntu and the Lies of the Logs (blog.spiderlabs.com)
How To Select A DDoS Mitigation Service (darkreading.com)
Linux 3.5 released (lkml.org)
Pharma Hack Backdoor Analyzed (blog.sucuri.net)
Reducing web application attack surface (blog.spiderlabs.com)
Spam from an Android botnet (blogs.msdn.com)
Statistics about Yahoo leak of 450.000 plain-text accounts (blog.eset.se)
Survey Reveals Traditional Vulnerability Scanners Not Working (skyboxsecurity.com)
Ten Things I’ve Learned About Cloud Security (infosecisland.com)
The Differences Between Security Certifications (infosecisland.com)
The fallacy of remote wiping (zdnet.com)
Thieves placed bugs and hacked onboard computers of luxury cars (telegraph.feedsportal.com)
Unvalidate Redirects and Forwards (hackingtricks.in)
Using Chip Malfunction To Leak Private Keys (darkreading.com)
VirusTotal += Behavioural Information (blog.virustotal.com)
WebDriver (w3.org)
What do Sony and Yahoo! have in common? Passwords! (troyhunt.com)
When is Undefined Behavior OK? (blog.regehr.org)
Windows short (8.3) filenames – a web security nightmare (acunetix.com)

Marc Ruef | G+ (480 Wörter)

► 19.07.2012 – Mac OS X Memory Analysis: An Overview

This article is an overview of current methods and tools for volatile memory analysis of a Apple Mac OS X system; additional references for each subject are listed. This is not a guide for dumping or analysing memory.

Introduction

The forensic analysis of a computer involves many complex and delicate tasks. To make an accurate and reliable copy of the data stored on hard disks, there are well documented and reliable procedures. The reasons are simple: the acquisition procedure is quite easy, so an expert is not strictly required, and there are a plenty of examination tools available on the market that can be used to investigate the collected data. More complex and unreliable is the acquisition of volatile memory.

The Random-Access Memory (RAM) is an area of the computer which is used to store data while the computer is working on it. A large amount of clear text sensitive information resides only within the RAM, assuming that the OS will prevent unauthorized access and that when the computer is powered off the content will be unavailable.

It is quite obvious that we can loose evidence if we omit volatile data during an acquisition procedure. Additionally, a growing number of infections show us that the memory content will be the only place where evidence can be found.

From a forensic perspective, RAM is extremely important, because it gives an idea of what the computer was doing at the time of analysis. With the increasing number of Apple Macintosh computers in the industry, the investigation of Mac OSX RAM content is becoming very important.

Acquisition

Most standards and best practice guidelines, such as the “Computer Security Incident Handling Guide” from NIST or RFC 3227 “Guidelines for Evidence Collection and Archiving”, include procedures of gathering volatile data: current network connections, running processes, users sessions, kernel parameters, open files etc. The problem is that to acquire data, some tools like netstat, lsof, ifconfig must be executed. These tools collect only obvious data, leaving most of the system’s memory unanalyzed. Moreover, these tools are executed from user mode and even if statically linked they can print unreliable data because of a kernel level modification. The perfect tool for collecting volatile data should not rely on an operating system (see the Tribble PCI device, [Carrier2003]).

A memory acquisition procedure should be useful in different environments so in most cases it relies on a software solution, and, if well designed, just uses a very short collection process, if possible, reduced to a single command in order to minimize the impact on the machine.

Several methods for the acquisition of the memory of a Mac OSX system may be used, all with some problems/limitations. Following a list of currently most used procedures some of them not specific for the Mac world.

Kernel module to dump memory [Singh2006]

This method, implemented for example in MacMemoryReader, uses a kernel extension to create temporary, read-only /dev/mem and /dev/pmap devices. /dev/mem provides the same functionality provided by /dev/mem on other Unix operating systems and gives access to physical memory of the following types, as defined by EFI: “available”, Loader Code, Loader Data, Bootstrap Code, Bootstrap Data, Runtime Code, Runtime Data, and, optionally, “reserved”.

It does not allow access to memory ports or memory-mapped I/O devices, so it cannot be used to write device drivers.

Superuser access is required to load the extension. In addition, since something is loaded in the memory, a footprint is left in the memory itself and changes the state of the acquired system.

Boot time argument [Singh2006]

As a trivial alternative to the kernel extension, it is possible to use the kmem=1 boot-time argument. If kernel supports the argument, this setting will reenable the kernel memory device. Since is a boot-time argument, a reboot is required, so it is useless in case acquisition of a running computer.

Direct Memory Access using Firewire [Boileau2006]

This method uses a “feature” of the Firewire spec (OHCI-1394), that allows read/write access to physical memory (via DMA) for external Firewire devices. As this is DMA, the CPU/OS will not even know what’s going on, so may work regardless of whether you have locked your screen; If not mitigated, Mac OSX prior to Lion 10.7.2 was vulnerable to this kind of attack; in Lion 10.7.2 it only works if a user is logged in.

Due to the firewire bus limitation, only 2GB on memory can be dumped, so with the growing memory size in modern machines, this method may be limited.

With specific HW, Macs with only the new Thunderbolt interface are also vulnerable. A summary of papers, attacks and tools related to the Firewire DMA attack can be found at Physical memory attacks via Firewire/DMA

Cold boot attack [Haldermann2008]

Powering off a computer has the consequence of RAM clearing, but not immediately! Research demonstrate that without power, memory chips may retain values for a short period of time (from seconds to minutes) giving the possibilities to read the full memory content. Additionally, if the chips are cooled, they may retain values for hours.

This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM. Placing the key in memory was thought to be safe because the operating system protect them while running, and there was no way to get rid of the operating system without cutting power to the machine, which “everybody knew” would cause the keys to be erased.

Collecting the sleepimage

If the computer if configured to go in sleep mode, the content of the memory is saved to /var/vm/sleepimage for future restore of the exact state; this file can be used to analyze the memory. It is not a perfect image of the running system, because a process is started to put the machine in sleep-mode influencing the content itself, but a lot of valuable information can still be collected.

Analysis

Having a memory dump is the first step, methods to extract useful information from memory such as opened files, detailed information about each process (start/stop …), network status etc. are still needed.

Compared to Microsoft world, the Mac OSX tools are in an prehistoric era. As stated in the the MacMemoryReader Readme.txt,

There are currently very few tools to analyze physical memory dumps from Mac OS X machines. Hex editors, string extraction tools, search tools, and file carvers are all useful for extracting data.

In addition, the memory can be dumped in different formats (using different offsets), and this may make some investigating tools useless.

For example, MacMemoryReader, the plug-and-play dumper, dumps the data in Mach-O binary or raw-format, while volafox (the analysis tool) requires the “linear” format (for memory addressing mechanism, consult the Intel Programmers Handbook), unless you checkout the head volafox version.

Some information can be extracted from the mach-O dump format using the command “string” and grepping for interesting sequences like – as example – “Plongname”: around this string the current logged username/password can be found.

But this is a trial & error method; just dumping strings and looking around may be useful but is prone to errors and very time consuming.

Tools

Mac Memory Reader: Mac Memory Reader is an easy to use command-line utility to capture the contents of physical RAM on a suspect computer, letting an investigator gather volatile state information prior to shutting the machine down. Results are stored in a Mach-O binary or raw-format file for later off-line analysis by the investigator. The “MacMemoryReader” can be downloaded from here.
volafox: Kyeong-Sik Lee and the Korean Digital Forensic Research Center have released Volafox, a free and open-source tool to analyze Mac OS X memory images. Volafox is based on work by Matthieu Suiche and the Volatility memory analysis framework. Volafox is the only open source tool that can extract some memory information automagically; running volafox against a linear memory dump may extract following information: os_version, machine_info, mount_info, kern_kext_info, kext_info, proc_info, syscall_info, net_info. “volafox” can be downloaded from here or checked out from http://volafox.googlecode.com/svn/trunk/. The svn checkout has the ability to read the MacMemoryReader format.
system tools: The string functions manipulate strings that are terminated by a null byte; can be used to extract ASCII strings from the image. Object file displaying tool command displays specified parts of object files or libraries; can be used to look at the mach-O export made with MacMemoryReader.
Goldfish: Goldfish is a free MAC OS X live forensic tool for use only by law enforcement. Its main purpose is to provide an easy to use interface to dump system RAM of a target machine via a firewire connection. It then automatically extracts the current user login password and any open AIM conversation fragments that may be available. A short presentation about Goldfish is available

Summary

The methods and tools to analyze a Mac OSX memory dump are still a work in progress; currently the only tool that can extract useful information from a memory image is “volafox”; the usage of filecarvers, string and grep for known signatures is ineffiecient and may lead to false positive.

Basically it’s possible to use following patterns:

MacMemoryReader -> mach-O dump -> string/grep/otool -> some unorganized and informal results
DMA memory dump -> volafox -> predefined set of information
MacMemoryReader -> volafox -> predefined set of information

References

[Singh2006] A.Singh, Mac OSX Internals: A Systems Approach, Addison Wesley Professional 2006, Chapter 8
[Suiche2010] M.Suiche, Advanced Mac OSX Physical Memory Analysis, Blackhat 2010
[Haldermann2008] Haldermann et al, Lest we remember: Cold Boot Attacks on Encryptions Keys
[Ligh2011] S.Adair; B.Hartstein; M.Richard, Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code, Wiley 2011
[Boileau2006] A.Boileau, Hit by a Bus: Physical Access Attacks with FireWire
[Carrier2003] B.Carrier; J.Grand, A Hardware-Based Memory Acquisition Procedure for Digital Investigations

Sources

{$t:Mac OS X Memory Analysis, an overview,$a:rcc,$v:1}

Rocco Gagliardi | G+ (1907 Wörter)

► 12.07.2012 – Information statt Angst

IT-Sicherheit beschäftigt. In unserem Alltag werden wir zunehmend mit dem Schutz unserer eigenen Daten und Privatsphäre konfrontiert. Firmeninhaber sehen sich durch Industriespionage und dem Ausfall von Systemen durch Virenbefall bedroht. Politiker zucken zusammen, wenn der Kunstbegriff “Cyberterrorismus” die Runde macht.

Technologie ist ein komplexes Thema. Im Alltag unserer Gesellschaft erhöht sich diese Komplexität noch einmal massiv, weil Technologie sich mit politischen, wirtschaftlichen, ethischen und moralischen Faktoren untrennbar verkettet. Reden wir dann von der Sicherheit dieser Technologien, so reden wir auch vom Einfluss auf alle damit verwobenen gesellschaftlichen Verknüpfungen.

Virenangriffe wie Stuxnet sind ein exzellentes Beispiel: Natürlich ist der Angriffsmechanismus interessant. Ebenso die Schwachstellen, die ausgenutzt wurden. Doch was Stuxnet zu einem Thema der Massen machte, ist der Fakt, dass (angeblich) Atomkraftwerke angegriffen werden sollte. Dass Vermutungen im Raum stehen, dass es sich hier um digitale Kriegsführung handelt, einem realen Konflikt zwischen realen Staaten – mit den komplexen technologischen Grundlagen hat das aber nichts mehr zu tun.

Es ist heute weitgehend bekannt, dass Technologie Schwachstellen aufweist. Die Existenz von Hackern ist, so sehr sie auch sensationalisiert und verfälscht dargestellt wird, eine unumstrittene Tatsache. Einige Themen und Begriffe, wie zum Beispiel Computerviren und Trojaner sind dermassen oft schon in der Öffentlichtkeit aufgetaucht, dass sie Common Knowledge sind. Die Mainstream Medien arbeiten mit diesen Begriffen und, oftmals selbsternannte, “Experten” nutzen dieselbe Terminologie, um ihre Kredibilität zu unterstreichen und sich gegenüber den Medien und der Öffentlichkeit verständlich zu machen. IT-Sicherheit ist ein Thema, über das gesprochen wird.

Wir sprechen über Virenattacken, über Keylogger und Trojaner und wie wir uns davor schützen können. Das ist gut, aber es gibt eine schlechte Nachricht: Wir sprechen über 2% des Problems – und das ist eine optimistische Schätzung. Die restlichen 98% des Problems werden nicht angesprochen, weil sie nach dem Ermessen irgendwelcher Leute in eine der folgenden Kategorien fallen:

1. Der Inhalt ist technisch zu komplex für die breite Masse
2. Das Szenario des Problems ist für einen grossen Teil der Masse nicht nachvollziehbar
3. Niemand hat bislang eine Möglichkeit gefunden, damit Geld zu verdienen

Alle drei Kategorien sind kurzsichtig, unlogisch sowie, abhängig vom jeweiligen Fall aus journalistischem Blickwinkel falsch und unmoralisch.

Die wenigen Themen, die wir effektiv ansprechen, sind meistens trivial und veraltet. Wir erhalten zum Beispiel regelmässig Presseanfragen zum Thema Computerviren – erst vor kurzem wurde ich in einem Radiointerview nach Dingen gefragt, die seit 10 Jahren in Hunderten von Artikel geschrieben wurden: Was ist ein Virus? Kann man sich schützen? Wie gut sind AV Produkte?

Sind diese Fragen legitim? Ja. Gäbe es bessere Fragen: Definitiv.

Vor kurzem wurde ich von einem Journalisten gefragt, was ich von der Berichterstattung in unserem Sektor halte. Meine ehrliche Antwort war: Sehr wenig. Die meisten Artikel, die ihren Weg in die Schweizer Tagespresse finden sind entweder irrelevant, masslos übertrieben oder fachlich schlicht und einfach falsch. Mein Gesprächspartner war etwas pikiert, hakte aber nach und fragte nach Ursachen. Meines Erachtens liegen diese nicht bei den Journalisten. Niemand kann von einem Journalisten erwarten, ein hochkomplexes Feld wie unseres vollumfänglich zu verstehen. Das Problem liegt an der Quelle – in unserer eigenen Industrie:

1. Übermässige Vereinfachung von Sachverhalten (“dumbing down”)
2. Mangel an kompetenten, qualifizierten Quellen/selbsternannte “Experten”
3. Das Anbieten falscher oder unzureichender Lösungen

Diese Gründe können mehr oder minder beliebig miteinander kombiniert werden. Beliebte Beispiel sind:

Sicherheitsexperten reden von Bedrohungen, sprechen dabei aber nur von Viren, weil andere Angriffsvektoren erklärt werden müssten. Aus diesem Grund werden auch nur entsprechende Gegenmassnahmen (AV) empfohlen (1, 3)
“Experten” warnen vor unermesslichen Risiken epochalen Ausmasses und prophezeien den Untergang des Abendlandes (2, oft zu finden in Artikeln zu Stuxnet)
Marketing-Mitarbeiter von “Sicherheitsfirmen”, die Firewalls und AV-Produkte verkaufen, erklären wie man sich mit ihren Produkten gegen “Hackerangriffe” schützt (1, 2 und 3)

Es mag viele Motivationen geben, sich mit IT-Sicherheit zu beschäftigen. Einige profitieren sicherlich massiv von dieser Art von Berichterstattung. So mancher Hersteller einer “Sicherheitssoftware” hat sich mit geschickter Panikmache eine goldene Nase verdient. Fakt ist aber: Wir verlieren alle. Es existieren Risiken und Schwachstellen, über die wir informieren müssen und über die ein öffentlicher Dialog geführt werden muss – ohne Panikmache, sondern mit verständlichen und akkuraten Informationen zur Problematik.

Diesen Dialog zu starten, das ist die Aufgabe der professionellen IT-Security-Schaffenden. Wir müssen aufhören, still grollend zu akzeptieren, dass Probleme trivialisiert, inakkurat wiedergegeben oder mit falschen Empfehlungen versehen werden. Die, schweizerisch-sprichwörtliche “Faust im Sack” hilft niemanden weiter – aber der Dialog mit den Medienschaffenden und das Bereitstellen von akkuraten, verständlichen Informationen kann der erste Schritt dazu sein, das Thema IT-Sicherheit seriös und ernsthaft zu behandeln.

Stefan Friedli | G+ (775 Wörter)

► 05.07.2012 – Windows 7 Stripping & Hardening, Part 2: Hardening Procedures

Part 1: OS Tools
Part 2: Hardening Procedures
Part 3: Keep it Safe

Hardening procedures are the most interesting and scaring thing to do in ICT security. Interesting because it requires not only deep knowledge of the system and/or application architecture, but also a deep knowledge of security related concepts.

On the other side it might be scary because you are going to touch deep into the system configuration and every single mistake could lead to a complete system or application failure. System administrators who just managed to make a system work as required would say: “Don’t touch a running system!” And guess what? They are right!

Because hardening should be a procedure that is implemented during the system engineering and not after everything is up and running. Anyway, most of the time the ideal way is not the one we may find and have to deal with it. In this case, before any attempt to harden is made, a system replica (virtual or physical) must be created and used as playground. Ideally you’ll test on virtual machines that allow you to take several snapshots of the data environment allowing to step back easily in case to total failure.

Now talking about Windows 7, Microsoft did a great job in making documents and tools to address security in general and hardening in particular. Microsoft has developed a framework to help business companies to be compliant to legal regulation (like SOX, HIPAA, PCI-DSS, …) and those regulations also requires baselines for operating system and application. The name of this framework is SCM (Security Compliance Manager) – On the other side we can also do hardening the old style: making everything by hand.

Hardening Procedure using SCM

The SCM toolset has following features:

It is available free of charge
Can create a GOLD/MASTER image for mass distribution (domain deployment)
Can create a baseline for stand-alone machine (local hardening)
Has several security guides for configuring registry and file system settings
Can compare baselines with industry security standards (SOX, PCI-DSS, …)
Can export settings for usage in other environment
Can generate configuration check for technical compliance

At the end you’ll get computer policies that can be used locally or imported to the Active Directory allowing to enforce Registry and File system settings. This helps in avoiding making all the changes by hand; it also permits to quickly revert any parameter to its original value (and this is very nice).

Once SCM is downloaded and installed, you’ll get access to several Security Guides like:

Windows 7 Computer Security
Windows 7 Domain Security
Windows 7 BitLocker Security
Windows 7 User Security
Internet Explorer Security

plus documentation on Windows Server, Exchange and Office security. Those guides are not only for technical settings but also handles security design issues allowing a good foundation for security plan and deployment.

The SCE tool itself has a central management console and has a windows 7 MMC like GUI.

Microsoft Security Compliance Manager

If you would like to see how it works I suggest you check this well made video that gives you a good introduction on how the toolset works.

Hardening Procedure on Windows 7

I’ll highlight the main settings areas of the hardening procedures in Windows 7:

Settings	Description
Audit Policy	Before we can secure we need to see what is happening or has happened, therefore we need to activate security event recording
User Rights	User rights should be assessed and use minimum privileged user for daily tasks
Security Options	These are the configurations that we can deploy best via baselines tools like SCM (services to run, network parameters, ...)
Authentication	Reducing the NTLM authentication and setting an adequate password policy is one of the most tangible effects for workstation security
Event Logging	After we make sure the system is reporting security events we need to make sure that those logs are available and tamper proof
Firewall	The new firewall is capable of filtering IN/OUT packets making a prerequisite for strong security policy on application access, therefore every application should be monitored and be allowed to access only what it really needs to
Update	Windows automated update policy is a must
File Sharing	A workstation should not share any file and configuration setting to assure the confidentiality of accessed files must be in place (SMB security)
Malware detection	Windows offers a basic malware detection tool, and at least this should be used although better solutions are available by security vendors

Summary

In this article we covered Hardening Procedures for Windows 7 using SCM, next month we’ll focus on other hardening methods, stay tuned!

Andrea Covello | G+ (785 Wörter)

► 28.06.2012 – Blog Digest Juni 2012

10 Movie Scenes Of Authentication Worth Rewatching (darkreading.com)
A bad couple of years for the cryptographic token industry (blog.cryptographyengineering.com)
Algorithms: When is Random Really Random? (infosecisland.com)
Android app steals contactless credit card data (scmagazine.com.au)
Backup Security Best Practices (blogs.mcafee.com)
Crypto breakthrough shows Flame was designed by world-class scientists (arstechnica.com)
CVSS for Penetration Test Results (Part I) (blog.spiderlabs.com)
Data Classification: Why it is Important for Information Security (infosecisland.com)
Decoding Common XOR Obfuscation in Malicious Code (isc.sans.edu)
Defeating Flame String Obfuscation with IDAPython (blog.spiderlabs.com)
eHarmony Password Dump Analysis (blog.spiderlabs.com)
Evolving Endpoint Malware Detection: Controls, Trade-offs and Compromises (securosis.com)
Evolving Endpoint Malware Detection: Providing Context (securosis.com)
Falsehoods programmers believe about networks (erratasec.blogspot.com)
HashDos: 42% of IIS sites are still Vulnerable (devcentral.f5.com)
How Advanced Malware Bypasses Process Monitoring (blog.fireeye.com)
How Malicious Code Can Run in Microsoft Office Documents (blog.zeltser.com)
How old is Flame? (labs.alienvault.com)
JSLR (thespanner.co.uk)
Kaspersky’s Problematic Flame Analysis (jeffreycarr.blogspot.ch)
Meet Flame, The Massive Spy Malware Infiltrating Iranian Computers (wired.com)
Microsoft certification authority signing certificates added to the Untrusted Certificate Store (blogs.technet.com)
Most Consumers Don’t Understand Breach Notification (darkreading.com)
Obama Order Sped Up Wave of Cyberattacks Against Iran (nytimes.com)
Our password hashing has no clothes (troyhunt.com)
Playing by the Rules: Performing Firewall Audits (resources.infosecinstitute.com)
Protect answers to password reset questions with pen-and-paper (blog.eset.com)
Rumor: LinkedIn Hacked – Password Hashes Dumped on Russian Forum (securityweek.com)
Safe Browsing – Protecting Web Users for 5 Years and Counting (googleonlinesecurity.blogspot.com)
Scientists crack RSA SecurID 800 tokens, steal cryptographic keys (arstechnica.com)
Security warnings for suspected state-sponsored attacks (googleonlinesecurity.blogspot.com)
The Central Limit Theorem Makes Random Testing Hard (blog.regehr.org)
Thoughts on Active Defense, Intrusion Deception, and Counterstrikes (securosis.com)
Why Antivirus Companies Like Mine Failed to Catch Flame and Stuxnet (wired.com)
XSS: Gaining access to HttpOnly Cookie in 2012 (seckb.yehg.net)

Marc Ruef | G+ (564 Wörter)

► 21.06.2012 – Banner unterdrücken oder ändern?

Im Rahmen unserer Vulnerability Scans taucht ein Finding immerwieder auf: Banner-Grabbing. Durch das Herstellen einer Verbindung auf einen Zeilport heisst die Zielanwendung den Benutzer mit einem Banner willkommen. In diesem sind Informationen zum eingesetzten Produkt und eventuell gar zur genutzten Version sowie zusätzlichen Informationen (z.B. Bugfixes, Plattform) enthalten. Beispiel des Banners eines SMTP-Mailservers:

maru@debian:~$ telnet mailtest.scip.ch 25
220 mailtest.scip.ch ESMTP Sendmail 8.12.3/8.12.3/Debian-7.1

Laut unserer Schwachstellenklassifizierung erhält ein Banner-Grabbing die Einstufung Medium. Diese Form der Auswertung (im weitesten Sinn handelt es sich um ein patternbasiertes Application Fingerprinting) bietet eine elementare Grundlage, um zielgerichtete Angriffe vorzubereiten und anzugehen. Ein Angreifer erlangt damit drei Vorteile:

Lohnenswerte Ziele können identifiziert werden
Angriffstechniken lassen sich auf Technologien/Produkte/Versionen/Einstellungen ausrichten
Unnötige Zugriffs-/Angriffsversuche können gespart werden

Wir empfehlen den betroffenen Kunden jeweils auf die Herausgabe sensitiver/technischer Informationen zur Zielumgebung zu verzichten (z.B. Banner, Fehlermeldungen). Dies bedeutet, dass Angreifern die jeweiligen Bannerinformationen nicht zur Verfügung gestellt werden sollten.

In diesem Zusammenhang erschliessen sich jedoch unterschiedliche Lösungswege. Einerseits kann der Banner gelöscht werden, um auf jegliche Herausgabe von Informationen zu verzichten (Banner Suppression). Andererseits kann der Banner angepasst werden, um falsche Informationen herauszugeben (Banner Spoofing). Die folgende Liste zeigt die Vor- und Nachteile der jeweiligen Ansätze:

Banner löschen (⇒ 220 mailtest.scip.ch ESMTP)
- Vorteile (+)
  - Intelligente Scanner testen evtl. gar nichts (z.B. Nessus mit safe_checks)
  - Minimierung der Ressourcenbelastung bei Bannerherausgabe (System, Netzwerk)
- Nachteile (-)
  - Intelligente/Aggressive Scanner testen evtl. alles (z.B. Nikto im Standardmodus)
  - Legitime Scans generieren evtl. False-Negatives (z.B. Nessus, Qualys)
  - Legitimes Debugging gestaltet sich schwieriger

Banner ändern (⇒ 220 scip.ch Microsoft ESMTP MAIL Service, Version: 5.0.2195.6713)
- Vorteile (+)
  - Intelligente Scanner testen falsche Schwachstellen (z.B. Nikto ohne -generic Argument)
  - Zielgerichtete Angreifer verschwenden ihre Zeit
- Nachteile (-)
  - Intelligente Scanner testen trotzdem (z.B. Nessus ohne optimize the test Option)
  - Angreifer werden evtl. angespornt (Skript-Kiddies und semi-professionelle Angreifer)
  - Legitime Scans generieren viele False-Positives und False-Negatives (z.B. Nessus, Qualys)
  - Legitimes Debugging gestaltet sich schwieriger

Unsere Empfehlung: Schauen Sie sich die Vor- und Nachteile der unterschiedlichen Ansätze an. Besprechen Sie im Team, welche Massnahme ein Mehr an Nutzen zu gewähren in der Lage ist. Sie kann je nach Unternehmen, Server und Dienst unterschiedlich ausfallen. Setzen Sie die beste Massnahme um.

Etwa 70% unserer Kunden sind der Meinung, dass generische Applikationsbanner ein akzeptierbares Risiko darstellen. Von den restlichen Kunden sind 27% um das Löschen und nur 3% um das Ändern des Banners bemüht.

Marc Ruef | G+ (464 Wörter)

► 14.06.2012 – IT-Risk Management – Eine Übersicht

Die Zeiten, in der man sich in der Informatiksicherheit mit einem Virenscanner und einer Firewall sicher fühlen konnte, sind schon seit längerer Zeit vorbei. Die Thematik ist über die Jahre komplexer geworden und man sieht sich als Unternehmen vielerlei Gefahren ausgesetzt. IT-Risk Management ist eine unterstützende Massnahme, um Gefahren zu erkennen und ihnen proaktiv gegenüber zu treten.

In den letzten Jahren haben sich verschieden Frameworks verbreitet, um die Unternehmen in diesem Bereich zu unterstützen. Diese Frameworks unterscheiden sich zwar immer ein wenig, doch haben sie auch immer gemeinsame Nenner. Dieser Artikel soll eine Übersicht über den Bereich IT-Risk Management geben und die wichtigsten Aspekte herausleuchten. Angefangen bei der Gefahr bis hin zu den Risiken und wie man die selbigen behandeln kann.

Die Gefahren

An erster Stellekommt die Erkennung der Gefahren denen man gegenüber steht. Jedes Unternehmen ist den ähnlichen Gefahren ausgesetzt sobald man eine IT-Infrastruktur betreibt und diese noch an das Internet angebunden hat.

Die Gefahr geht immer von jemandem aus. Sei dies ein interner Mitarbeiter oder eine Hacktivisten-Gruppe wie Anonymous. Nun gilt es den Angreifer zu charakterisieren. Hier helfen zum Beispiel Fragen wie:

Wie mächtig ist der Angreifer?
Wie motiviert ist er um sein Ziel zu erreichen?
Wie fundiert ist sein Wissen?

Als nächstes kommt die Tätigkeit. Also was macht der Angreifer. Hier wird werden Tätigkeiten gesucht, die ein Angreifer ausführen kann. Stiehlt er etwas oder geht es ihm um eine sinnlose Zerstörung.

Und der wichtigste Punkt ist herauszufinden, was in einem Unternehmen alles in Gefahr sein kann. Für eine Schweizer Bank sind wohl die Kundendaten von erhöhter Priorität. Bei einem Unternehmen welches aktiv Forschung betreibt, werden wohl diese Forschungsergebnisse als das wichtigste Gut betrachtet.

Zum Schluss möchte ich zwei mögliche Gefahren als Beispiele aufführen, die wir in den vergangenen Jahren in den Medien mehrmals gesehen haben:

Ein interner Mitarbeiter stiehlt Kundendaten (z.B. Bei einer Bank werden Kundeninformationen gestohlen und im Ausland zum Kauf angeboten)
Eine kriminelle Organisation stiehlt geheime Informationen (z.B. Bei RSA wurde ins Netzwerk eingebrochen und sensitive Informationen über ihre RSA-Tokens entwendet)

Gefahrenszenarien

Das Szenario beschreibt, wie die Gefahr eintreten kann. Trojaner, die Daten und Passwörter ausspähen, gehören in diesen Bereich, wie auch das Social Engineering, wo Mitarbeiter angegangen werden, um an Informationen zu kommen. Die Palette von Angriffs-Vektoren ist sehr vielfältig. Um den Rahmen hier nicht zu sprengen, fahre ich mit den beiden Gefahrenbeispielen fort und bilde je ein mögliches Szenario:

Ein interner Mitarbeiter stiehlt Kundendaten, indem er unerlaubterweise eine Daten-CD brennt.
Eine kriminelle Organisation stiehlt geheime Informationen, indem sie einen Trojaner im Netzwerk einschleust.

Das Risiko

Um das Risiko zu bewerten, muss man die zuvor kreierten Szenarien herbeiziehen und sie mit den vorhandenen Massnahmen vergleichen.

Ein interner Mitarbeiter stiehlt Kundendaten, indem er unerlaubterweise eine Daten-CD brennt. ⇒ Jeder PC ist mit einem Brenner ausgestattet und auch das schreiben auf USB Sticks ist nicht eingeschränkt. Fazit: Es besteht ein erhöhtes Risiko, dass Daten unbemerkt aus dem Unternehmen entwendet werden.
Eine kriminelle Organisation stiehlt geheime Informationen, indem sie einen Trojaner im Netzwerk einschleust. ⇒ Alle Systeme sind mit einem Antiviren Scanner ausgestattet. Zusätzlich ist eine Lösung im Einsatz, welche die Ausführung von unerlaubtem Code unterbindet (z.B. Whitelisting). Fazit: Es besteht ein geringes Risiko, dass dieser Fall eintritt.

Die Mitigierungsmassnahmen

Wenn man sich der Risiken bewusst ist, hat man zwei Möglichkeiten. Man kann das Risiko akzeptieren oder man kann proaktiv das Risiko minimieren. Vor allem sollte man als erstes die hohen Risiken auf einen vertretbaren Stand bringen. Hier nehme ich das erhöhte Risiko:

Ein interner Mitarbeiter stiehlt Kundendaten indem er unerlaubterweise eine Daten-CD brennt. ⇒ Massnahmen: Das Brennen von CDs und das beschreiben von Wechseldatenträger im Unternehmen wird unterbunden und überwacht. Fazit: Das Risiko wird massiv verringert.

Fazit

IT-Risk Management hilft allen Unternehmen frühzeitig die Gefahren zu erkennen und Risiken zu minimieren. Ebenfalls dient es dazu, um den Sicherheits-Zustand eines Unternehmens zu erfassen und um den Verantwortlichen Personen den Status aufzuzeigen. Es sollte aber vor allem ein integraler Bestandteil des IT-Sicherheitskonzepts jedes Unternehmens sein.

Pascal Schaufelberger | G+ (697 Wörter)

► 07.06.2012 – Firewall Rule Review – Ansatz und Möglichkeiten

Durch Firewall-Systeme wird die Grundsicherheit in Netzwerken gewährleistet. Bei einer Firewall Rule Review wird das Regelwerk einer solchen Sicherheitskomponente auf etwaige Fehler und Schwächen hin untersucht. Dieser Beitrag fasst die Grundlagen einer solchen Analyse zusammen.

Einführung
Export
Dissection
Review
Einstellungen
Bewertung
Gründe
Zusammenfassung

Einführung

Das grundlegende Ziel einer Firewall Rule Analyse ist das Identifizieren von Schwachstellen und Unschönheiten in einem Firewall-Regelwerk. Dabei geht es darum

Regeln,
Objekte,
und Relationen

zu identifizieren, die

unsicher,
falsch,
ineffizient
oder unnötig

sind. Zu diesem Zweck wird das Regelwerk einer Firewall mit all seinen Details und Abhängigkeiten betrachtet.

Export

Als erstes gilt es Zugriff auf das Regelwerk zu erhalten. Man unterscheidet hier zwischen onsite Analysen, bei denen online auf der Firewall bzw. der Management-Schnittstelle dieser gearbeitet wird. Und einer offline Analyse, bei der das Regelwerk extrahiert und unabhängig von der produktiven Umgebung untersucht wird.

Früher wurden Onsite-Analysen vorgezogen, da sich diese schnell und unkompiziert angehen lassen. Man kann sich direkt an die Firewall setzen und mit der Begutachtung beginnen. Aus Gründen der Professionalität versuchen wir jedoch darauf zu verzichten. Eine Offline-Analyse bietet wichtige Vorteile, wie Unabhängigkeit von der produktiven Umgebung. Zudem lassen sich, wie wir in einem späteren Schritt sehen werden, computergestützte Analysen vorantreiben.

Viele Firewall-Systeme bieten eine Export- oder Backup-Funktion, mit der das Regelwerk extrahiert werden kann. Entweder sind es spezifische Kommandoeingaben oder Funktionen auf der grafischen Oberfläche, die zu diesem Ziel führen können. Die folgende Tabelle fasst einige bekannte Firewall-Systeme und ihre Exportfunktionalität für Rulsets und Configs zusammen.

Produkt	Ansatz	Vorgehen
iptables	View/Export	`/usr/sbin/iptables-save`
Astaro	Export (full)	`/usr/local/bin/backup.plx`
	Export (iptables)	`/usr/sbin/iptables-save`
	Backup	Webadmin / Management / Backup/Restore
Checkpoint FW1	Backup	copy files in `%FWDIR%/conf/` (objects_5.C, rulebase.fws, *.W)
Checkpoint FW1	Export	Tools: cpdb2html/cpdb2web
Cisco IOS/PIX/ASA	View/Export	`show mem`, `show conf`
Citrix Netscaler	Backup	copy file `/nsconfig/ns.conf` (via SCP)
Juniper	Backup (Webadmin)	Admin / Update / Config / Copy&Paste
Juniper	Backup (FTP)	`request system configuration rescue save` (via FTP)
McAfee Web Gateway	Backup	Configuration / File Management / Configuration Data / Download Configuration Backup
Microsoft Windows 7 Firewall	Export (GUI)	Actions / Export List
Microsoft Windows 7 Firewall	Export (Shell)	`netsh advfirewall export [filename]`
Sidewinder G2	Export (ACL)	`cf acl export`
	Export (IP Filter)	`cf ipfilter export`
	Export (Proxy Settings)	`cf proxy export`
	Export (Application Filter)	`cf appfilter export`
StoneSoft StoneGate Firewall	Export	Configuration / File / Export / Export Elements

Grundsätzlich ist jedes Datenformat, welches die erforderlichen Grunddaten enthält, willkommen. Sollten keine Exportfunktionen vorgesehen sein, kann versucht werden mittels Copy&Paste (vor allem in Webfrontends) oder Screenshots zu arbeiten.

Dissection

Nachdem das Regelwerk mittels Export- oder Backup-Funktionen extrahiert wurde, gilt es dieses in ein Format zu konvertieren, mit dem die Analyse möglichst effizient vorangetrieben werden kann. Hierzu wird das Parsing der jeweiligen Dateien erforderlich.

Im Beitrag Firewall Rule Parsing am Beispiel von SonicWALL haben wir gezeigt, wie ein solches Parsing bei einer SonicWALL aussehen kann. Das Parsing ist sehr stark von der Struktur der vorliegenden Daten abhängig. So kann zwischen verschiedenen Datentypen der jeweiligen Produkte unterschieden werden, wie die folgende Tabelle zeigt.

Produkt	Apache	Array	CLI	INI	CSV	XML
Apache Reverse Proxy	x	–	–	–	–	–
USP Secure Entry Server	x	–	–	–	–	–
Astaro (backup.plx)	–	x	–	–	–	–
Checkpoint Firewall-1	–	x	–	–	–	–
Fortigate	–	x	–	–	–	–
iptables	–	–	x	–	–	–
Cisco IOS/PIX/ASA	–	–	x	–	–	–
Citrix Netscaler	–	–	x	–	–	–
McAfee Web Gateway	–	–	–	x	–	–
SonicWALL	–	–	–	x	–
Microsoft Windows 7 Firewall	–	–	–	–	x	–
StoneSoft StoneGate Firewall	–	–	–	–	x	–
Airlock	–	–	–	–	–	x
Clearswift MIMEsweeper	–	–	–	–	–	x
StoneSoft StoneGate Firewall	–	–	–	–	–	x
Totemo Trustmail	–	–	–	–	–	x

Das Parsing hat in der Regel zum Ziel, die einzelnen Regeln und ihre Attribute identifizieren und dediziert auf sie zugreifen zu können. Normalerweise wird das Regelwerk, welches komplexe Relationen und Verschachtelungen aufweisen kann, in eine tabellare Form gebracht. Als minimale Informationen eines Firewall-Regelwerks gelten:

Quelle (Host/Netz)
Ziel (Host/Netz)
Dienst (Protokoll/Port)
Aktion [Allow, Deny/Drop]

Viele Produkte bieten aber noch ein mehr an Attributen an, die sich einer Firewall-Regel oder den einzelnen Objekten zuordnen lassen. Dazu können gehören:

ID
Aktiv
Timeframe
Benutzer
Logging
Priorität/QoS
...

Ein normalisiertes Firewall-Regelwerk wird nachfolgend abgebildet, wobei sich sowohl in Bezug auf bei der Anzahl der eingebrachten Regeln als auch der berücksichtigten Attribute auf ein Minimum abgestützt wird.

Src Host	Src Port	Dst Host	Dst Port	Protocol	Action
*	>1023	192.168.0.10/32	80 (http)	TCP	ALLOW
10.0.0.0/8	>1023	*	80 (http)	TCP	ALLOW

Hierbei handelt es sich um die beiden typischen Outbound- und Inbound-Rules für Webkommunikationen über Port tcp/80. Im ersten Fall wird der Zugriff aus dem Internet in die DMZ erlaubt und im zweiten Fall werden den Clients im Klasse C-Netzwerk der Zugriff ins Internet gewährt und im zweiten .

Review

Nachdem eine Umformung und Normalisierung des Regelwerks vorgenommen werden konnte, kann sich um die eigentliche Analyse bemüht werden. Hierbei wird nach Schwachstellen Ausschau gehalten, die da sein können:

Erweiterte Zugriffsrechte

ANY Rules: Regelsatz enthält bei einem Attribut den Wert ANY, der als Wirdcard verstanden wird und den Zugriff für alle erlaubt.
Bidirektionale Rules: Innerhalb eines Regelsatzes wird eine hohe Deckungsgleichheit bei Quelle und Ziel vorgefunden.
Breitflächige Definition von Zonen/Ports: Aufgrund einer schlechten Eingränzung von Attributen (Gruppen oder Bereichen) werden ein Mehr an Zugriffen erlaubt, weder nötig sind.
Blacklisting: Es wird ein Blacklisting-Mechanismus eingesetzt, der naturgemäss zu False-Negatives beim Unterbinden von Zugriffen neigt.
DROP ALL Rule fehlt: Manche Firewall-Produkte erwarten explizit eine DROP ALL Rule, wodurch sämtlicher verbleibender nicht erlaubter Verkehr unterbunden wird.

Unsichere Rules

Unsichere Protokolle (z.B. telnet, ftp, snmp): Es werden als unsicher geltende Protokolle zugelassen. Dies ist nicht direkt ein Fehler innerhalb des Firewall-Setups. Viel mehr ist es ein Indikator, dass konzeptionell etwas verbessert werden kann.
Mash-up von Objekten: Es werden Objekte unterschiedlicher Kategorisierung und Klassen in einer Objektgruppe oder in einem Attribut zusammengefasst.
Überlappende Objekte: Es werden verschiedene Objekte genutzt, sich teilweise überlappen. Dies tritt in erster Linie bei Adressbereichen, Netzen und logischen Gruppen auf.
Verkapselte Objekte: Es werden Objektgruppen in anderen Gruppen verkapselt, wodurch die Übersichtlichkeit und Nachvollziehbarkeit des Regelwerks massiv leidet.

Unnötige Rules

Inaktive Objekte: Es werden Objekte verwaltet, die aber nirgends als Attribut in einem Regelsatz vorkommen.
Temporäre Rules: Es werden Regeln betrieben, die als temporäre Regeln gedacht und eingerichtet wurden. Manchmal haben diese Regeln schlichtweg nicht die Transition in feste Regeln geschafft – Oder es handelt sich um vergessene Überbleibsel.
Test Rules: Ähnlich wie temporäre Regeln können erweiterte und vergessene Test Rules ein Risiko darstellen.
Unnötige Rules: Unnötige Regeln, die keinen Nutzen erfüllen, stellen sowohl organisatorisch als auch technisch eine Gefahr dar. Dies kann zum Beispiel der Fall sein, wenn für längst deaktivierte oder verschobene Systeme noch immer die alten Regeln bestehen.

Dokumentation fehlt

Kein Comment/Description: Aufgrund fehlender Kommentare oder Beschreibungen ist die Funktionsweise einer Regel oder deren technischen, organisatorischen bzw. politischen Hintergründe nicht nachvollziehbar. Neben betrieblicher Reibung wird damit ebenfalls die gesamte Analyse als solche erschwert.
Whitelisting ohne Begründung: Es werden Whitelisting-Mechanismen angewendet, die nicht dokumentiert und damit auch nicht begründet sind. Deren Legitimität lässt sich nicht mehr nachvollziehen.
Logging nicht aktiviert: Es werden Regeln verwendet, die kein Logging aktivieren. Ein solches ist aber sowohl für eine Fehlersuche als auch für eine forensische Untersuchung erforderlich.

Lockdown fehlt

Lockdown Rules nicht vorhanden: Das Firewall-System selbst schützt sich nicht durch Angriffe, wodurch die Integrität dessen mittels direkten Attacken beeinträchtigt werden könnte.
Stealth Rules nicht vorhanden: Das Firewall-System setzt keine Mechanismen ein, um seine Existenz zu verschleiern. Zum Beispiel, indem auf das Dekrementieren des TTL-Werts im IP-Header verzichtet wird.
DENY anstatt DROP: Die für das Unterbinden von Kommunikationen angesetzten Regeln benutzen DENY und informieren deshalb über die Restriktion. Stattdessen kann ein stillschweigendes Verwerfen mittels DROP zum Einsatz kommen.

Sodann wird es möglich, dass im bestehenden Regelwerk die jeweiligen Schwächen markiert und dokumentiert werden. Ein Beispiel der Identifikation solcher Schwachstellen zeigt die nachfolgende Tabelle. Hierbei werden die in Ungnade gefallenen Attribute farblich markiert, um das Risiko (Low, Medium, High) anzeigen zu können. Hinter dem Attribut wird in eckigen Klammern das Stichwort der Schwachstelle festgehalten. Eine weiterführende Dokumentation mit zusätzlichen Details zu Risiken und Massnahmen kann daraus abgeleitet werden.

Src Host	Src Port	Dst Host	Dst Port	Protocol	Action
*	>1023	192.168.0.10/32	80	TCP	ALLOW
*	* [ANY Rule]	192.168.0.10/32	23 [Insecure]	TCP	ALLOW
10.0.0.0/8	>1023	*	80	TCP	ALLOW
192.168.0.10/24	1024-50000 [Inadequate]	10.0.0.0/8	22,902,8443 [Mashup]	TCP	ALLOW
* [ANY Rule]	* [ANY Rule]	192.168.0.10/24	3389	TCP	ALLOW
10.0.0.0/8	0	* [ANY Rule]	0,8	ICMP [Insecure]	ALLOW

Im Rahmen verschiedener Projekte pflegen wir ein eigens entwickeltes Framework zur computergestützten Umsetzung von Firewall Rule Reviews einzusetzen. Nachfolgendes Video zeigt den Import und die Analyse eines umfassenden Checkpoint-Regelwerks. Die Regeln und ihre Attribute werden anhand der bisher beschriebenen Betrachtungen auf etwaige Schwächen hin untersucht.

Zusätzliche Einstellungen

Viele Firewall-Systeme bieten abseits des zentralen Regelwerks globale oder zusätzliche Funktionen an. Vor allem Application Gateways nutzen systemweite Einstellungen für die jeweiligen Proxies. Diese sind bei einer umfangreichen Firewall-Analyse ebenso zu berücksichtigen. Nachfolgende Tabelle zeigt einen kleinen Ausschnitt der globalen Einstellungen einer McAfee Web Gateway Installation.

ID	Einstellung	Wert	Empfehlung	Risiko
...
1427	CheckFileSignatures	0	1 (=enabled)	Medium
1428	ChecksumMismatchWeb	‘Replace and Quarantine’	‘Replace and Quarantine’	Passed
1429	EmbdJavaAppletWeb	‘Allow’	‘Block’	Medium
1430	ExpiredContentWeb	‘Block’	‘Block’	Passed
1431	JavaScriptWeb	‘Allow’	‘Block’	Low
1432	MacroWeb	‘Replace and Quarantine’	‘Block Document’ (strict)	Passed
1433	UnsignedEXEWeb	‘Allow’	‘Block’	High
...

Hierbei wird ähnlich verfahren, wie bei der zugrundeliegenden Firewall Rule Analyse. So werden die einzelnen Einstellungen identifiziert und ihre gegenwärtigen Werte ausgemacht. Diese werden mit den sicherheitstechnischen Empfehlungen verglichen und bei Abweichungen ein Risiko ausgewiesen.

Es gibt zwei grundsätzliche Schwierigkeiten, die bei einer solchen Betrachtung aufstossen koennen. Einerseits wird bei einer detaillierten Betrachtung oftmals in Bereiche vorgestossen, die nicht oder nur ungenügend Dokumentiert sind. So kann es durchaus sein, dass Einstellungen vorgefunden werden, deren genaue Funktionsweise nicht bekannt ist. Wenn selbst das Handbuch des Produkts nicht weiterhelfen kann, kann versucht werden sich mit dem Hersteller in Verbindung zu setzen und um interne Details zu beten. Solche Anfragen werden aber relativ selten berücksichtigt. Dann können nur eine vage Ableitung oder konkrete Experimente helfen, die Funktionsweise der einzelnen Settings determinieren zu können. Eine absolute Deckungsgleichheit innert nützlicher Frist zu erreichen, ist oftmals unmöglich.

Andererseits können gerade im Rahmen von dateibasierten Analysen Konfigurationsmöglichkeiten aufgedeckt werden, die innerhalb der normalen Nutzung des Produkts nicht gesehen oder verändert werden können. Gerade wenn das Produkt normalerweise über eine grafische Oberfläche betreut wird, kann es zu Problemen und Missverständnissen bei der genauen Betrachtung kommen. Es wird sodann schwierig herauszufinden, welche Option in welcher Form auf der grafischen Oberfläche ausgewiesen wird und ob sie sich überhaupt innerhalb des üblichen Prozesses anpassen lässt. Dieser Nachteil kann aber auch zum Vorteil werden, wenn denn plötzlich versteckte Funktionen entdeckt werden, aus denen sich in unmittelbarer Weise ein Vorteil erschliessen lässt.

Bewertung bestehender Regelsätze

Nachdem das Regelwerk optimiert wurde, indem unsichere Einstellungen entfernt, ersetzt oder verbessert wurden, kann das bestehende Regelwerk bewertet werden. Hierbei geht es darum zwei Dinge zu bestimmen:

Welches Restrisiko verbleibt nach den Optimierungen?
Und welche Kommunikationsbeziehungen bergen das grösste Risiko?

Wir und andere Institute (z.B. ETH Zürich) forschen seit über 10 Jahren in diesem Bereich. Bis heute gibt es keine etablierten Mechanismen, um eine umfangreiche Bewertung von Kommunikationsbeziehungen durchzuführen.

Das nachfolgend gezeigte Beispiel orientiert sich am Common Vulnerability Scoring System (CVSS). Hierbei handelt es sich um ein System, welches zur Bewertung von Verwundbarkeiten verwendet wird. Einer Verwundbarkeit werden verschiedene Eigenschaften zugewiesen, die sich wiederum auf die als Score ausgedrückte Bewertung auswirkt. Doch anstelle von Verwundbarkeiten wird CVSS zur Bewertung der in der Firewall-Umgebung abgebildeten Kommunikationsbeziehungen verwendet.

Als erste Attribute für das Base Score werden Access Vector (AV), Access Complexity (AC) und Authentication (Au) verwendet. Damit wird definiert, welche Voraussetzungen gegeben sein müssen, um eine Schwachstelle ausnutzen zu können. Die nächsten Attribute sind Confidentiality Impact (CI), Integrity Impact (II) und Availability Impact (AI). Diese geben an, welche Auswirkungen ein erfolger Angriff nach sich führen wird.

Diese sechs Attribute erlauben laut CVSSv2 jeweils drei unterschiedliche Abstufungen. Diesen Abstufungen werden Werte zugewiesen, die sich zum Schluss in der Berechnung verwenden lassen. Auf der Webseite von NIST findet sich eine umfangreiche Dokumentation zu diesem System.

Beschreibung	Src	Dst	Srv	AV	AC	Au	CI	II	AI	Score
Extern Web zu öffent. Webserver	Inet	DMZ	t80	N	L	N	N	C	C	9.4
Extern Web für interne Clients (in)	LAN	Inet	t80	N	M	N	C	C	C	9.3
Extern Web zu Kundenseite	Inet	DMZ	t443	N	L	S	C	C	C	9.0
Extern Mail zu öffent. Webserver	Inet	DMZ	t110	N	M	S	C	C	C	8.5
Extern Fernzugriff zu Server	Inet	DMZ	t22	N	M	S	C	C	C	8.5
Intern zu Nameserver	LAN	DMZ	u53	L	L	N	C	C	C	7.2
Intern Intranet für Clients	LAN	DMZ	t80	L	L	N	P	C	C	6.8
Extern Web für interne Clients (out)	LAN	Inet	t80	L	L	S	C	C	C	6.8
Intern Fernzugriff für Clients	LAN	DMZ	t3389	L	M	S	P	C	P	5.5
Intern ICMP Echo für Server	DMZ	Inet	i0,8	L	M	S	P	P	C	5.5

Ohne auf die Beweggründe der Attributisierung der jeweiligen Kommunikationsmechanismen eingehen zu wollen, lässt sich anhand dieser Liste die kritischen Beziehungen ausmachen. In einem weiteren Schritt sieht man sich dank dieser Daten in der Lage, flankierende Massnahmen zur Mitigierung der Risiken anzustreben. Dabei handelt es sich aber in der Regel nicht mehr um Massnahmen, die sich in der Firewall-Umgebung anwenden lassen. Viel mehr müssen oftmals weitreichende technologische, architektonische/topologische, konzeptionelle oder organisatorische Massnahmen angestrebt werden.

Gründe für Fehler

Eine statistische Auswertung der letzten Projekte hat verschiedene Dinge aufzeigen können. Einerseits kann gesagt werden, dass gewisse Probleme einen Grossteil der Installationen betreffen. So finden sich immermal wieder ANY-Rules, temporäre Rules oder ein deaktiviertes Logging.

Firewall Rule Review Findings

Andererseits gibts aber auch Probleme, die an einzelne Kunden gebunden scheinen und bei diesen besonders häufig auftreten. So haben wir schon Regelwerke gesehen, bei denen konsequenz auf ein Logging verzichtet wird, sämtliche Dienste mit ANY-Rules betrieben werden oder gänzlich auf ein Logging verzichtet wird. Hierbei scheint es sich entweder um alteingesessene oder eingelebte Fehler zu handeln. Diese sind zwar oftmals mit unmittelbaren Massnahmen zu lösen, jedoch müssen diese Massnahmen mit viel Aufwand und Geduld in die bestehende Arbeitsphilosophie eingeflochten werden.

Im Rahmen einer statistischen Auswertung haben wir ebenfalls versucht herauszufinden, welches die Gründe für unsichere Firewall-Regelwerke sind. Diese lassen sich grob in die folgenden sechs Kategorien einteilen:

Fehler (falscher Klick, falsches Copy&Paste, ...)
Vergessen/Faulheit (“Ich werde das später noch optimieren…”)
Fehlinformationen (der Hersteller empfiehlt Ports 10000-50000)
Missverständnis (technisch, konzeptionell)
Unbekannte Funktionalität (versteckte Einstellungen)
Technische Fehler (z.B. fehlerhafter Backup-Import)

Diese Fehler lassen sich in der Regel mit dem Durchsetzen eines Vier-Augen-Prinzips verhindern. Ob dieses nun durch eine interne Peer-Review oder durch ein externes Beratungsunternehmen (z.B. im Rahmen eines Audits) geschaffen wird, ist zweitrangig. Hauptsache ist, dass subtil eingeschlichene Fehler möglichst früh erkannt und eliminiert werden können. Dadurch lässt sich das Zeitfenster für erfolgreiche Angriffe minimieren.

Zusammenfassung

Auch wenn vereinzelte Stimmen laut werden, dass Firewall-Systeme ausgedient haben, spielt Firewalling seit vielen Jahren eine zentrale Rolle im Bereich der modernen Informationssicherheit. Sie regulieren massgeblich den Datenfluss in einem Netzwerk, sind damit Dreh und Angelpunkt der angewandten Netzwerksicherheit.

Netzwerke und Netzwerkapplikationen weisen heutzutage eine gewisse Komplexität auf, der auch innerhalb des Firewallings Rechnung getragen werden muss. Da mit Komplexität stets das Risiko von Fehlern mitgeführt wird, ist es besonders wichtig, dass Firewalling mit äusserster Sorgfalt betrieben wird. Um Schwächen in einer Firewall-Installation frühstmöglich entdecken zu können, kann eine Firewall Rule Review angestrebt werden.

Als erstes wird das Firewall-Regelwerk extrahiert. Daraus werden die einzelnen Regeln, ihre Attribute und Relationen herausgelöst und normalisiert. Dadurch wird es möglich, sowohl einzelne Objekte als auch ganze Regeln auf ihre Korrektheit hin zu prüfen. Dabei sollten ebenfalls globale Einstellungen, die besonders bei Proxy-Systemen mitgeführt werden, berücksichtigt werden.

Unsichere und unschöne Regeln können optimiert werden. Das verbleibende Regelwerk lässt sich sodann bewerten, um risikoreiche Kommunikationskanäle ausfindig machen zu können. Diese können dann ausserhalb des Firewallings mit flankierenden Massnahmen – oftmals ist ein Mehr an Aufwand erforderlich – geschützt werden.

Marc Ruef | G+ und Rocco Gagliardi | G+ (3062 Wörter)

► 31.05.2012 – Blog Digest Mai 2012

13 Tips to Secure Your Virtual Machine Environment (stateofsecurity.com)
8 Breach Prevention Tips (govinfosecurity.com)
A Career in Forensics: 5 Key Steps (govinfosecurity.com)
Adobe Malware Classification Tool review (Michael Boman)
Algorithms: When is Random Really Random? (infosecisland.com)
Chromium Blog: A Tale of Two Pwnies (Part 1) (blog.chromium.org)
Data leakage in social media (isc2Blog)
Everything you ever wanted to know about building a secure password reset feature (troyhunt.com)
Google Chrome Becomes World’s No. 1 Web Browser; Still No. 2 In US (ibtimes.com)
Happily Anti-Social (hackerfactor.com)
How To Better Measure Botnet Size (darkreading.com)
How to Use a Web Application Firewall (The Right Way) (blog.port80software.com)
How To Use Service Providers To Manage DDoS Threats (darkreading.com)
Latest news on my hardware security research (cl.cam.ac.uk)
Linux 3.4 released (lkml.org)
Man in the Browser Attack vs. Two Factor Authentication (resources.infosecinstitute.com)
Meet ‘Flame’, The Massive Spy Malware Infiltrating Iranian Computers (wired.com)
Nmap 6 Release Notes (nmap.org)
Poorly Managed Firewall Rule Sets Will Flag An Audit (darkreading.com)
Prevent VoIP Toll Fraud with Proper Configurations (infosecisland.com)
Reversing 101 – Solving a protection scheme (corelan.be)
Ridley Scott’s New Blade Runner Film Will Be Sequel (wired.com)
Securing Your Company Against BYOD-Created Threats (infosecisland.com)
So What If You Detected Malware? (blog.damballa.com)
The Antivirus Uncertainty Principle (blog.damballa.com)
The Jericho Botnet – Why Break A Wall When You Can Just Sneak Through? (researchcenter.paloaltonetworks.com)
Twelve Security Best Practices for USB Drives (infosecisland.com)
When factors collapse and two factor authentication becomes one (isc.sans.edu)

Marc Ruef | G+ (467 Wörter)

► 29.05.2012 – Opinion: Flamer/sKyWIper – Facts & Myths in 5 Minutes

Dear reader, I’d like to point out that everything you will read below is purely based on the available information and my interpretation of those alleged facts. This is a writeup that was written on the very day the existence of Flame became public, so certain information may be subject to change and revised over the course of time. Check the bottom of the page for edits and errata.

Introduction

Discovered 2010, Stuxnet caused a lot of turbulence throughout the infosec landscape and beyond. The assumption, that this piece of malware could have been used to target and effectively, physically sabotage specific nuclear facilities in Iran, along with its complexity, caused strong interest within the technical crowd and quickened the interest of the mainstream media. Almost two years later, we know far more about Stuxnet than we did initially. A lot of research was done to figure out how it worked, what it targeted and – probably the most adventurous question – who was behind it. Felix ‘FX’ Lindner presented a great talk at last years hashdays, which I’d recommend in case you haven’t seen it yet. (http://www.youtube.com/watch?v=GVi_ZW-1bNg)

While the flame (no pun intended) of fascination sparked by Stuxnet is still alive, this article is in fact not about Stuxnet at all. Flamer, which we will talk about here, is a piece of malware that was recently discovered by the Iran National CERT (MAHER) and that, while apparently fairly complex, has almost nothing to do with Stuxnet or its alleged cousin Duqu. This is an important fact for many reasons. One of them being that people will try to fit Flamer in their fantasy-driven picture of cyber warfare and secret agents, while I think it’s important to keep the FUD low and analyze Flamer for what it is: A sophisticated piece of malware that provides a versatile framework of attack vectors and could, theoretically, be used by and against anyone.

What Flamer is

As far as we currently know, Flamer is an attack framework and as such not really easy to categorize clearly. We know that it infects a host persistently and works in combination with multiple C&C servers, so we could call it a backdoor. We could also go for the label ‘worm’, since there is strong evidence provided by CrySyS (the Laboratory of Cryptography and System Security at the Budapest University of Technology and Economics) that MS10-061 and MS10-046 are used among other techniques to attempt propagation, once an initial compromise was accomplished.

Once installed, Flamer seems to be multi-purpose by design. In fact, the whole malware package is 20 times bigger than Stuxnet in size and features a plugin-based infrastructure. It even provides easy extensibility using LUA scripting. Therefore, trying to tie Flamer down to a single category of malware is really not the smartest thing to do. Even as we speak and beyond, new functionality might be added, so we might never know what Flamer did and did not do originally.

From the information available at this point, Flamer was built to compromise systems and steal information, whereas information is a really generic term for whatever the attacker might be interested in. Some common functionality that seems to be in modules available out of the box includes network sniffing, recording audio using local devices, keylogging, taking screenshots – really nothing you wouldn’t expect from any trojan nowadays. However, Flamer seems to do all of these things exceptionally well (even including cryptography), even though there is a lack of publicly available information on what ‘exceptionally well’ means in this specific case.

What Flamer is not

Currently, I have no trouble whatsoever to explain what I know about Flamer in less than three minutes. This is partially because I am no malware researcher and do honestly believe that I’m partly ignorant on the technical specifications and more interested in the implications, as well as partly blatantly less well-informed than some of my friends working for big AV corporations.

What takes a lot of time at this point is to deduce what Flamer is most probably not. And there is a lot of things that Flamer is not. Starting with the assumption already stated above that Flamer is, to the best of our knowledge, not in any way related to Stuxnet/Duqu or any other product based on the so-called ‘Tilded’ platform.

There are a couple of other arguments that try to tie Flamer to Stuxnet/Duqu or similar cyberwar-related malware products. One of these arguments is the usage of MS10-061 and MS10-046 exploits. However, these techniques became common knowledge up to some degree after Stuxnet was discovered, so to assume a connection based upon this is adventurous at best, since these modules were not necessarily part of Flamer from the get-go, but might have been added later on during the development process.

The most popular argument however is that Flamer is mainly active in the Middle East. Kaspersky Labs published information earlier, stating that the top 7 countries are Iran (189 known infections), Israel/Palestine (98), Sudan (32), Syria (30), Lebanon (18), Saudi Arabia (10) and Egypt (5). While this is an interesting piece of data, it collides with the fact that the initial discovery and analysis of the malware took place in Iran. Apart from that: Even when we assume that these initial numbers are correct and there are no other infections (which is unprobable), a congregation of this size would not be a clear indicator for a targeted attack without any specialized payload that would indicate a specific target region. The current statement, linking the existent infections to possible cyberwar operations, is comparable to linking a series of bicycle thefts in Manhattan to possible terrorist activity. Further, the visibility of this type of threats is very limited based upon CERT activity in affected nations and/or availability of samples to AV vendors.

Of course, I cannot rule out that Flamer is in any way related to the goals that the masterminds behind Stuxnet pursued. Not only because we still don’t know what those goals were for Stuxnet, let alone Flamer. However, there is currently no solid evidence that supports those theories. The geographical spread is not significant enough, the usage of similar exploits is likely to occur since it would be ignorant to leave working, partly weaponized exploits unutilized, especially in a modular malware where activating/deactivating certain pieces of functionality is very easy. Also, while Stuxnet targeted industrial systems, there seem to be no specific target definitions for Flamer: It can infect private systems just as well as corporate ones and is designed to collect information without any hardcoded specification about the content, but with keywords supplied by the attacker.

Still, the reports of Flamer being some sort of crazy cyber warfare superweapon keep coming. With the right mindset, everything about it becomes an indicator to support that claim. Even the size: Flamer is over 20MB when extracted. This makes it, as mentioned earlier, 20 times bigger than Stuxnet. Does that mean that Flamer is 20 times better, faster, more complex and dangerous than Stuxnet? Of course not, at least not necessarily. Where Stuxnet was (supposedly) used in a very targeted attack against PLCs, Flamer features a variety of functionality along with several libraries (compression, database manipulation, .). When you start to pack zlib, sqlite3 and a full LUA virtual machine with your backdoor, it is bound to get a little bit softer around the edges. People I know and trust who know a lot more about malware than I do tell me, that while Flamer is more advanced than your everyday trojan, the level of complexity is not way off the charts. Even online banking trojans display a pretty astonishing amount of functionality these days.

Then there is the assumption that the possibility of ruling out other scenarios will leave no other options than to assume that Flamer is a state-sponsored malware. The common approach is to state that Flamer obviously is not used by crimimals since no bank information is being stolen and that, referring to its complexity, it is obviously not used by hacktivists. While I do not dispute these assumptions, I think that breaking down the threat landscape to criminals, hacktivists and warmongering nation-states is a little bit over-simplyfing our current situation.

Conclusion

No, I do not know who created Flamer. Nor do I know what the intended usage is. I am aware of those facts and I do not claim to know anything that is not publicly available up to this point is time. However, I’m writing this both for future reference and in advanced response to countless media inquiries our press office will undoubtedly receive during the next couple of hours and days.

We are living in a world where information is an asset. For corporations just as much as for individuals. Flamer is a piece of software that, no matter who is using it, targets this information with the purpose of disclosing it to whoever controls it. Therefore, our primary goal should not be the ‘who’, but the ‘how’. How Flamer works, how it exploits systems, how it remained undetected by all our security products for over nearly two years, how it gathers information and communicates with the C&C systems is essential to learn how we can defend against it, and its successors.

Stefan Friedli | G+ (1584 Wörter)

► 24.05.2012 – Windows 7 Stripping & Hardening, Part 1: OS Tools

Ever tried to install windows 7 in a virtual machine for testing purposes? Well… then you probably know that is a resource consuming task in terms of memory footprint.In test environment you may need to have more than one windows 7 machine running at time and if you like to use a laptop running VMware or Virtualbox or whatever virtualizing tool you may have, it will probably eat all your memory resources with just a few VM instances. This is where the stripping part of this article comes to count.

Out of the box Microsoft enables too many services and delivers all possible set of executable in standard installation. This means that on your hard disk you’ll find programs that you’ll probably never use; this is not only a waste of disk space but also a security concern. As a matter of fact, the more code you’ve installed in your operating system, the more “attack surface” you are presenting to malware events.

It is good practice in security hardening to remove first all part of functionality (executable code) that are not strictly needed inside an operating system as long the function needed are not affected. This is called “stripping” and we’ll talk about it here in the first part of this LAB article.

Using tools

The first approach would be to customize the windows installation making use of the WAIK (Windows Automated Installation Kit) a set of tools and documentation provided by Microsoft to support configuration and deployment of windows operating systems. This process requires manual interventions and a solid knowledge of the windows architecture and modules dependency. Of course the “doing by hand” philosophy provides many goodies and is surely the preferred way for the ones who want to have control of every step of the stripping process, but requires much more skill and time to accomplish.

RT Seven Lite

Here I want to present an easier way to accomplish such complex task with less hassle, and therefore I will introduce RTSe7enLite.

This tool has been developed by Rockers Team to customize windows OS allowing following features to be implemented:

OS Customization
Remove OS components
Tweaks
Unattended installation
Integration of service/language packs or 3.rd party software
Provide a bootable ISO or DVD

RT 7 Lite is free for personal and commercial usage and capable to customize and strip down Windows client & server versions but has following prerequisites:

MS .NET Framework 3.5
WAIK (needed only for Vista or Server 2008 platform)
A Windows Vista, 7, server 2003 or Server 2008 DVD or ISO image (you don’t need activation codes for testing)

How does it work?

Step	Menu	Description
1	Startup	During the firts startup RT7lite will ask you to provide the windows source files: a DVD/ISO image or a destination folder with the installation files inside
2	Destination	Select a destination folder where the files will be extracted to
3	Version	After the file extraction, you’ll be asked to select the windows version to configure
4		Here you’ll select how to proceed the customization: manually or selecting a preconfigured setting
5		This dialog will ask you to provide 3.rd party software (silent installer only) or windows security updates (this is an optional step)
6		Select components to deactivate and/or its related binaries to (optionally) remove
7		Here you may define tons of configuration customization (like services, security, desktop, system or custom registry settings)
8		Here you can select all default settings to make your installation running in silent mode providing license, usernames, system name, RunOnce settings and much more
9		Now may define your themes, wallpapers, logon screen, gadgets, ... to personalize your installation
10		When all your settings are done, click on the [APPLY] button
11		Now the LOG dialog will be diplayed and you’re ready to create the system image
12		start the procedure by clicking on the [COMMIT] button

Please beware that this process may take 60 to 90 minutes and MAY freeze your system until the image generation is done. So take your time and don’t panic is the system reacts slowly… But finally you’ll should get this log message:

Now select to create a bootable DVD or ISO image.

Once you have your image, do a test installation to see if the system is working as expected. Remember that removing critical system components (marked in red in the feature removal dialog) may create unstable system. With the right stripping configuration you will get 20-60% less memory footprint for the running system, thus helping to run more machines in your virtual environment.

Summary

In this article we covered stripping the OS using tools, next month we’ll focus on the hardening prodcedures, stay tuned.

Andrea Covello | G+ (884 Wörter)

► 16.05.2012 – Vortrag zu Firewall Rule Reviews

Am 10. Mai 2012 fand in Bern das 24. Meeting der Swiss Network Operators Group (SwiNOG) statt. Im letzten Slot der Vortragsreihe durfte ich einen Vortrag zur systematischen Umsetzung von Firewall Rule Reviews halten.

Sowohl die Slides als auch das Demo-Video werden hier bereitgestellt. Wir werden in rund einem Monat einen umfangreichen Artikel zu diesem Thema hier im Labs Blog veröffentlichen. Dieser wird zusätzliche technische Details und Hintergründe einer entsprechenden Analyse bereitstellen.

Slide Deck (Slideshare)

Demo Video zu Slide 16 (Youtube)

Marc Ruef | G+ (134 Wörter)

► 10.05.2012 – Structuring the Rule Name in Checkpoint Firewall

In the Checkpoint manual, the Rule Name is described as the:

Name used to indicate the significance of the specific rule. Rule Name appears throughout all the applications (for example, SmartView Tracker, SmartReporter, and so on), and offers a clue as to why it is being used.

During our firewall rule reviews, we see different usage of the Rule Name field: the most used value is “” (none, null, void …), then a plethora of strings ranging from “Test” to the lapalissian “Allow rule” (sometime in conjunction with a drop action).
Is the Rule Name really useless?

A reasonable case

Basically a rulebase consist of a set of rules used to partition the traffic between two areas in as small as possible channels to monitor/allow/block the traffic flow. Normally a rulebase may have hundreds of rules, grouped – or not – in higher level logical blocks reflecting some administrative properties not strictly related to the technical implementation (example inbound/outbound smtp traffic is usually placed nearby even if not technically necessary). Typically an organisation uses a management process, with some word/web/paper forms, to justify/document/monitor/create/remove the technical implementation of a rule:

an application requires communications paths
a programmer fills out an order describing the action (add/change/remove) and the src/dst/svc
an engineer designs a possible solution
a revisor accepts/rejects the request
an operator technically implements the rule

Keeping the process synchronized (all parties refer to the same rule), a necessary step to assure a high quality level of the rulebase, is a challenge and a common source of security issues.

A possible structure of the Rule Name

Use the Rule Name field to map the technical and the management level, creating a bijection between the rules described in the management process and the technical implementation. The requirements for the structured Rule Name are:

must be bijective: give an exact pairing of the elements of order and rulebase
must be readable: each rule already has a UUID but, even if unique, something like 99cffc66-0660-1001-abcd-00aa11bb22cc is “hard to remember”
must be simple enough to maintain

Based on the requirements, we could form our Rule Name considering the Enforcement Point where the rule would be installed, the order – or the application – needing the communication and the position of the rule in the order. A possible structure of our Rule Name field could be:

EP identification
order identification
line in the order

<fw-id>.<order-id>.<order-line>

This format is a little bit redundant in favor of readability, but visually clear and effective. It is possible to quickly identify the EP and the order which normally identify an application. In case of troubleshooting or revision every rule it is easier to classify and relate to an application (area), refer to a management order and/or a responsible person.

Using numerical or text identifier does not really matter, the important thing is to use normalized identifiers:

ext.mail.1, int.mail.1, ...
ext.av.1, int.av.1, ...
1.101.1, 2.202.2, ...

Based on the number of orders and how the internal process is organized, it may be more confortable to use numbers instead of strings.

The side effects

A really nice side effect of structuring the Rule Name is the new filtering possibilities of the logfile. Basically, we assigned some new management properties to each rule, so we can now use these properties to get some management results. Even in the simple case of a single firewall

Client(s)->FW01->Server(s)

naming each rule with format <fw-id>.<order-id>.<order-line> can help filtering all logs related to a specific order-nr or application without using complex src/dst filter.
Consider now the common case of a connection traversing multiple EPs with complications like proxies/gateways/NATs and so on.

Client(s)->FW01->DMZ-Server(s)->FW02->Internet

In this case it would be very difficult, or impossible, to filter the logfile via src/dst/svc, but a childs play using the Rule Name: just track logs containing ".<order-nr>." and follow how an internal client causes a new connection originating from a server in a DMZ. This method has proven to be very usefull in troubleshooting cases.

An example

Consider the case of allowing mail traffic from internet to intranet and vice versa. A normal configuration has a DMZ mail server accepting and controlling all incoming/outgoing mails; if mail passes all checks (antispam, virus, ...), it is forwarded to the final destination. On the firewalls we need to allow the communication between internet<->DMZ<->intranet.

The SmartDashboard configuration:

on fw-ext, the firewall placed between DMZ and Internet:

Nr.	Name	Source	Destination	VPN	Service	Action	Track	Install On	Time	Comment
56	3.ap101.1	Any	dmz_mail	Any Traffic	smtp	accept	Log	Policy Targets	Any	created, 20060103, rcc
57	3.ap101.2	dmz_mail	Any	Any Traffic	smtp	accept	Log	Policy Targets	Any	created, 20060103, rcc

on fw-int, the firewall placed between DMZ and Intranet:

Nr.	Name	Source	Destination	VPN	Service	Action	Track	Install On	Time	Comment
63	2.ap101.1	dmz_mail	int_mail	Any Traffic	smtp	accept	Log	Policy Targets	Any	created, 20060103, rcc
64	2.ap101.2	int_mail	dmz_mail	Any Traffic	smtp	accept	Log	Policy Targets	Any	created, 20060103, rcc

the SmartTracker with a filter [ Rule Name – Contains – .ap101. ], will show:

Nr.	Date	Time	Origin	Source	Destination	Svc.	Action	Rule	Rule Name
11	27Apr12	10:11:12	fw-ext	mx.google.com	ap101_dmz_mail	smtp	accept	56	3.ap101.1
22	27Apr12	10:11:12	fw-int	ap101_dmz_mail	ap101_int_mail	smtp	accept	63	2.ap101.1
33	27Apr12	11:12:13	fw-int	ap101_int_mail	ap101_dmz_mail	smtp	accept	57	3.ap101.2
44	27Apr12	11:12:13	fw-ext	ap101_dmz_mail	mail.yahoo.com	smtp	accept	64	2.ap101.2

With a single simple filter it is possible to also track DMZ gateway activities.

Summary

Structuring the Rule Name has some costs related to the manual maintenance of referential integrity; on the other side, we obtain a cheap and efficient tool that helps to synchronize the “should” with the “is” state and new tracking filter, which could help a lot in case of troubleshooting.

{$t:Structuring the Rule Name in Checkpoint Firewall,$a:rcc,$v:1}

Rocco Gagliardi | G+ und scip AG (1024 Wörter)

► 03.05.2012 – Schwache Typisierung und ihre Sicherheitsrisiken

Die Typisierung (engl. typing) wird in der Informatik verwendet, um Objekte im Rahmen der Nutzung einer Programmiersprache korrekt anzuwenden. Diese Idee der Typsysteme stammt aus der Mathematik, die ihrerseits in Bezug auf die Mengenlehre ohne Typisierung zu Widersprüchen geführt hat.

Man unterscheidet in der Programmierung zwischen zwei grundlegenden Typsystemen. Eine starke Typisierung (engl. strong typing) verhindert, dass auf Objekte Operationen angewendet werden, für die sie nicht vorgesehen sind. Zum Beispiel kann eine Zeichenkette nicht ohne weiteres mit einem Zahlenwert multipliziert werden. Der Compiler oder Interpreter verweigert in diesem Fall die Arbeit und gibt eine Fehlermeldung aus:

$x = "string2" * 3 // bei strenger Typisierung nicht möglich

Eine strenge Typisierung führt dazu, dass sich Entwickler in jedem Detail bewusst sein müssen, welche Typen die von ihnen genutzten Objekte darstellen und welche Operationen sich darauf anwenden lassen. Dies ist nicht immer einfach und so greifen diverse Programmiersprachen auf die schwache Typisierung (engl. weak typing) zurück. Bei einer solchen wird eine automatische Typenumwandlung durchgeführt, um möglichst einfach Resultate generieren zu können.

Es gibt eine Reihe von Programmiersprachen, die mit einer schwachen Typisierung daherkommen. Da sie freizügiger im Umgang mit Datentypen sind, gelten sie als leichter handzuhaben und deshalb eher einsteigerfreundlich. Zu den populären Sprachen mit einem schwachen Typensystem zählen Javascript, Objective-C, Perl und PHP.

Im zuvor genannten Fall der Multiplikation eines Strings mit einem Integer ist es sodann nicht untypisch, dass das Resultat $x den Wert 3 oder 6 annehmen wird. Die Sprache wird Integer als primitiven Datentyp vorziehen und den String in einen solchen umwandeln wollen. Da der String definiert ist, kann er entweder den Wert 1 (ein leerer String würde 0 lauten) oder den Wert 2 (das Eliminieren sämtlicher Teile, die nicht direkt als Integer verwendet werden können) annehmen. Wie das Resultat genau lautet, ist von der Definition und Implementierung der zugrundeliegenden Programmiersprache abhängig.

Dieser Effekt kann in Angriffen eine wichtige Rolle spielen. Gehen wir davon aus, dass eine Funktion eine Berechnung vornehmen soll. Der Anwender kann einen spezifischen Wert durch eine legitime Eingabe definieren. Durch eine Eingabeüberprüfung wird aber verhindert, dass der Wert 0 lauten kann. Dabei wird der Vergleichsoperator in folgender Form eingesetzt:

if($_GET['input'] == 0){
   echo 'Die Eingabe ist nicht zugelassen.';
}else{
   setPermissions($_GET['input']);
}

Da die Eingabe 0 nicht übergeben werden kann, kann versucht werden einen leeren String zu übergeben. Dieser wird eventuell aufgrund der schwachen Typisierung angenommen und im Rahmen der Funktion irgendwann doch noch als 0 verarbeitet.

Dieses Phänomen tritt ebenso bei der Nutzung von Vergleichsoperatoren bei unterschiedlichen Datentypen auf. Die folgende Tabelle illustriert das Verhalten von PHP, wenn die Werte mit dem typenneutralen Operator == verglichen werden:

	TRUE	FALSE	1	0	-1	“1”	“0”	“-1”	NULL	arr()	“php”	“”
TRUE	TRUE	FALSE	TRUE	FALSE	TRUE	TRUE	FALSE	TRUE	FALSE	FALSE	TRUE	FALSE
FALSE	FALSE	TRUE	FALSE	TRUE	FALSE	FALSE	TRUE	FALSE	TRUE	TRUE	FALSE	TRUE
1	TRUE	FALSE	TRUE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE
0	FALSE	TRUE	FALSE	TRUE	FALSE	FALSE	TRUE	FALSE	TRUE	FALSE	TRUE	TRUE
-1	TRUE	FALSE	FALSE	FALSE	TRUE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE
“1”	TRUE	FALSE	TRUE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE
“0”	FALSE	TRUE	FALSE	TRUE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE
“-1”	TRUE	FALSE	FALSE	FALSE	TRUE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE
NULL	FALSE	TRUE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	TRUE	TRUE	FALSE	TRUE
arr()	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	TRUE	TRUE	FALSE	FALSE
“php”	TRUE	FALSE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	FALSE	FALSE	TRUE	FALSE
“”	FALSE	TRUE	FALSE	TRUE	FALSE	FALSE	FALSE	FALSE	TRUE	FALSE	FALSE	TRUE

Auch hier sieht man, dass PHP den Vergleich "" == 0 mit TRUE beantworten würde. Dies ist ein Effekt, der bei Rückgabewerten von bestimmten Funktionen zu Problemen führen kann. Und zwar dann, wenn sie sowohl den Rückgabewert 0 als auch FALSE liefern können, diese Werte aber unterschiedliche Status ausweisen.

Ein klassisches Beispiel ist die Funktion strpos(), welche zum Auffinden eines Strings in einem anderen String genutzt wird:

$a = substr('abcd', 'a');  // liefert 0
$b = substr('abcd', 'b');  // liefert 1    
$c = substr('abcd', 'cd'); // liefert 2
$d = substr('abcd', 'x');  // liefert FALSE

Der erste Aufruf wird in $a den Rückgabewert 0 liefern, da das Zeichen a in der Zeichenkette abcd an Position 0 auftritt (es wird nicht bei 1 zu zählen begonnen). Diese Zählweise wird weitergezogen. Doch beim letzten Beispiel wird in $d der Wert FALSE gespeichert, da das Zeichen x nicht in der Zeichenkette abcd vorkommt. So mancher Programmierer benutzt irrtümlicherweise folgende Struktur, um das Vorkommen einer Zeichenkette zu determinieren:

$pos = substr('abcd', 'x');
if($pos != 0){
   return 'gefunden';
}else{
   return 'nicht gefunden';
}

Doch genau dieser fehlerhafte Vergleich kann nun herangezogen werden, um Eingabeüberprüfungen zu umgehen. Um dies zu verhindern, muss der typensensitive Vergleichsoperator === herangezogen werden. Denn dieser kann sehr wohl zwischen 0 (gefunden an erster Stelle) und FALSE (nicht gefunden) unterscheiden. Mittlerweile wird in der Online-Dokumentation von PHP explizit auf die Risiken dieser Art bei bestimmten Funktionen hingewiesen. Dennoch sieht man immerwieder Applikationen, die dieses Prinzip übersehen und sich so gegen geschickte Angriffe verwundbar machen.

Marc Ruef | G+ (1159 Wörter)

► 27.04.2012 – Blog Digest April 2012

10 Simple Tips for Boosting The Security Of Your Mac (securelist.com)
57 Small Programs that Crash Compilers (blog.regehr.org)
64-bit Process Replacement in Powershell (exploit-monday.com)
67% of ASP.NET websites have serious configuration related security vulnerabilities (troyhunt.com)
Algorithms: When is Random Really Random? (infosecisland.com)
Apple Security Grows Up With Pair Of Malicious Threats (blog.fortinet.com)
Beyond the firewall (software.co.il)
Checklists and Information Security (newschoolsecurity.com)
CIOs May Like To Talk The Social Media Talk, But Only 10% Walk The Walk (techcrunch.com)
Coding Horror: Learn to Read the Source, Luke (codinghorror.com)
Data Classification: Why it is Important for Information Security (infosecisland.com)
DDoS attacks on financial sector booming (itp.net)
DDoS, detailed analysis of the phenomenon (securityaffairs.co)
Estimating The Economics Behind BYOD Security (darkreading.com)
Exploiting XSS in Ajax Web Applications (superevr.com)
FBI: Smart Meter Hacks Likely to Spread (KrebsOnSecurity)
Five Schemes For Redeeming Trust in SSL (darkreading.com)
Getting your message across: Screenshots (blog.c22.cc)
Good for Enterprise Exploitation (blog.opensecurityresearch.com)
Hacking-Kung Fu: Aims and Objectives (petalocsta.com)
Hotel Wifi JavaScript Injection (justinsomnia.org)
Infectious Media Attack (pentestlab.wordpress.com)
MasterCard, VISA Warn of Processor Breach (KrebsOnSecurity)
Michael Hamelin on crafting a firewall maturity model (TufinBlog)
Nmap – Techniques for Avoiding Firewalls (pentestlab.wordpress.com)
OSINT and pre-game show for a on-site WLAN Penetration Test (resources.infosecinstitute.com)
Post Exploitation – Disable Firewall and Kill Antivirus (pentestlab.wordpress.com)
QArt Codes (research.swtch.com)
Security Alert: New Android Malware DKFBootKit Moves Towards (research.nq.com)
Segfaults (blog.uncommonsensesecurity.com)
Server-side Polymorphic Android Applications (symantec.com)
Shady Companies With Ties to Israel Wiretap the U.S. for the NSA (wired.com)
Speed Hashing (codinghorror.com)
SQL Injection through HTTP Headers (resources.infosecinstitute.com)
Static Code Analysis (altdevblogaday.com)
The value of HTTP 404 Errors (blog.rootshell.be)
Time magazine readers name Anonymous most influential person (zdnet.com)
Twelve Security Best Practices for USB Drives (infosecisland.com)
VLAN Network Segmentation and Security (infosecinstitute.com)
VMware confirms hackers stole source code (GrahamCluleysBlog)
Vulnerabilities, Exploits, and Good Dental Hygiene (blog.tenablesecurity.com)
Vulnerability Management Evolution: Core Technologies (securosis.com)
Vulnerability Management Evolution: Scanning the Infrastructure (securosis.com)
Watching the Watchers: Clouds Rolling In (securosis.com)
We Have A Winner! (hackerfactor.com)

Marc Ruef | G+ (657 Wörter)

► 26.04.2012 – BSides London 2012 – eine persönliche Zusammenfassung

Eines der Merkmale, dass die scip AG auszeichnet ist, dass unsere Mitarbeiter sich auch ausserhalb der Bürozeiten aktiv in der Infosec Landschaft bewegen. Marcs privates Blog, Computec, existiert seit 1997 und wird immer noch aktiv betreut. Unsere Labs Artikel, die wir hier an dieser Stelle auf scip.ch veröffentlichen, gründen oftmals auf persönlicher Initiative verschiedener unserer Teammitglieder. Auch Twitter sehen wir als wertvolle Ressource zur Kommunikation an, entsprechend oft trifft man verschiedene Exponenten der scip AG “privat” auch dort an.

Auch Konferenzen gehören zu unserem Alltag bis zu einem gewissen Masse dazu. Zum einen erlauben diese den direkten Austausch von Wissen, zum anderen dienen sie dem wichtigen Erschliessen von Kontakten zu Experten in den verschiedensten Spezialgebieten der Informationssicherheit. Seit längerem engagiere ich mich persönlich im Komittee der führenden Schweizer Sicherheitskonferenz hashdays, die dieses Jahr bereits zum dritten Mal in Luzern stattfindet.

Wer selber ein Auge auf die gängigen Konferenzkalender wirft wird schnell feststellen, dass die Anzahl verfügbarer Konferenzen sich in den letzten Jahren massiv erhöht hat. Umso wichtiger ist daher die Zusammenarbeit und Organisation unter den einzelnen Konferenzen, um ein möglichst solides, breites Spektrum an Themen ohne Terminkollisionen oder ähnlicher Unschönheiten anzubieten. Bei hashdays arbeiten wir sehr aktiv mit anderen europäischen Konferenzen wie z.B. Brucon zusammen und engagieren uns auch in aktiven Partnerschaften. Die BSidesLondon, die gestern in London (UK) stattfand, ist eine dieser Konferenzen.

Wir haben in der Vergangenheit schon über andere BSides Events gesprochen und ich kann an dieser Stelle nur wiederholen, dass die grundlegende Idee, technisches Wissen auf hohem Niveau kostenlos zur Verfügung zu stellen meines Erachtens eine sehr unterstützenswerte Sache ist. Mit hashdays ist dies aus logistischen Gründen (Kosten der Location, volle Deckung der Speaker-Spesen) nicht möglich, weshalb wir uns entschieden haben die BSidesLondon als “Grassroots-Sponsor” zu unterstützen. Eine Entscheidung, die wir heute, nach dem Event, nicht bereuen: Das Ergebnis war eine durchwegs solide Konferenz mit innovativen Themen und grossartiger Atmosphäre.

Den ersten Talk mit dem Titel “Breaking in to Security”, der eigentlich auf meiner Liste stand, hielt Robin Wood. Während ich wegen eines verspäteten Fluges leider noch nicht vor Ort war, sprach Robin über die Möglichkeiten im Bereich der Informationssicherheit Fuss zu fassen. Eine Thematik, die sicherlich auf regen Anklang stösst, erhalten wir bei der scip AG doch regelmässig Anfragen von Studienabgängern und Quereinsteigern, die wissen möchten welcher Pfad unserer Meinung nach der Beste ist, um in diesem Feld Fuss zu fassen. Wir werden den Talk, so wie alle anderen die in diesem Post genannt werden, an dieser Stelle verlinken sobald die Videos verfügbar sind.

Nachdem ich meinen Weg ins Innere von London etwas verspätet doch noch gefunden habe, sprach David Rook über die Sicherheit von Windows Phone 7. Während sich unser Fokus in den letzten Monaten eher auf iOS und Android Geräte verschoben hat, präsentierte David durchaus interessante Findings sowie ein paar nützliche Tools zur Analyse von Windows Phone 7 Applikationen.

Der nächste Talk, “Mapping The Penetration Tester’s Mind: 0 to Root in 60 Minutes”, fiel leider aufgrund ungeklärter Abwesenheit des Speakers aus, wurde aber kurzerhand durch eine Präsentation eines anwesenden Gasts zum Thema “Random Numbers” ersetzt. In knapp 50 Minuten ging es hier um gängige Fehler beim Generieren von Zufallszahlen, wie z.B. die Nutzung von Modulo-Funktionen oder Gleitkommaberechnungen. Was hier etwas trocken tönt, ist durchaus relevant und hat schon so manchen Applikationsentwickler mehr als nur Schweiss und Tränen gekostet. So wurde beispielsweise eine Lücke in einem Pokerportal, das an dieser Stelle ungenannt bleiben soll, demonstriert, bei dem die Zufallszahlen unter Zuhilfenahme des aktuellen Serverzeitstempels als Seed berechnet wurden. Mit ein wenig Kreativität und Geduld war es dadurch möglich, das komplette Kartendeck im Voraus zu berechnen. Und wer Poker spielt, der weiss dass die Kenntnis aller Karte doch einen kleinen Vorteil mit sich bringt…

Weiter ging es mit Robert McArdle Talk mit dem Titel “HTML5 – A Whole New Attack Vector”. Rob zeigte auf kurzweilige Art und Weise welche Neuerungen HTML5 bringt und was sich damit, im Hinblick auf Funktionalität, bewerkstelligen lässt. Während in diesem Teil primär neue Features demonstriert wurden, ging Rob anschliessend dazu über die Gefahren dieser Funktionen zu illustrieren. Während die Vektoren weitgehend bekannt sind, diente der Vortrag sicherlich vielen als guter Eyeopener, zumal HTML5 derzeit rasante Verbreitung findet.

Nach der Mittagspause referierte Dave Hartley zum Thema “SAP Slapping”. Hinter dem etwas obskuren Titel versteckte sich ein allgemeiner Talk zum Penetration Testing von SAP. Ich erlaube mir hier aufgrund der etwas trockenen Natur des Themas, auf Details zu verzichten, empfehle Interessierten aber die Lektüre der Slides sowie des Videos sobald dieses verfügbar ist.

Als Abschluss präsentierte Paul Marsh seine Erkenntnisse im Hinblick auf die Nutzung von Satelliten. Aus nachvollziehbaren Gründen wird dieser Talk nicht als Video verfügbar sein und ich werde aus denselben Gründen auch nicht auf Details eingehen. Wer aber gerne die Kommunikation somalischer Piraten abhören möchte, tut gut daran sich einmal näher mit dem Thema zu beschäftigen.

Als Abschluss gab es dann doch noch etwas Arbeit: Die von uns zur Verfügung gestellten Challenge-Preise wurden an die (hoffentlich) glücklichen Gewinner verteilt, danach verlagerte sich die Mehrheit der Anwesenden, wie sich das für London gehört, in ein angrenzendes Pub.

Ich für meinen Teil warte derzeit auf meinen Rückflug nach Zürich und kann auf einen durchwegs interessanten und aufschlussreichen Tag zurückblicken. Interessierten sei die Teilnahme im kommenden Jahr ans Herz gelegt. Wer nicht solange warten kann, kann natürlich derzeit auch günstig ein Ticket für die hashdays Ende Oktober erstehen.

Aus London,
Stefan Friedli

Stefan Friedli | G+ (995 Wörter)

► 19.04.2012 – Nicht-Eliminierbarkeit von Schwachstellen

Im Rahmen von breitflächigen Sicherheitsüberprüfungen pflegen wir eine besondere Philosophie zu verfolgen:

Sowohl jede mögliche als auch jede potentielle Schwachstelle, auch wenn sie (durch uns und im Rahmen des Projekts) nicht ausgenutzt werden kann, wird vermerkt und gemeldet. Es liegt sodann im Ermessen des Kunden darüber zu entscheiden, ob die potentielle Eintrittswahrscheinlichkeit und Auswirkung des Problems für ihn wahrgenommen werden will bzw. tragbar ist.

Wir melden also auch Schwachstellen, die durch andere oftmals nicht als solche verstanden werden. Ein typisches Beispiel ist die Möglichkeit eines Reverse DNS Lookup. Kennt ein Angreifer die IP-Adressen eines Zielnetzwerks, kann er versuchen anhand dieser die Hostnamen der im Nameserver vermerkten Systeme zu identifizieren:

maru@debian:~$ host 80.238.216.33
33.216.238.80.in-addr.arpa domain name pointer www.scip.ch.

In diesem Fall kann anhand der IP-Adresse 80.238.216.33 der Hostname www.scip.ch ausgemacht werden. Eine solche Auswertung der Zielumgebung ist in mancherlei Hinsicht von Nutzen:

Hostnamen …

erleichtern für Menschen den Umgang mit Systemen
sind Voraussetzung für Zugriffe/Angriffe (z.B. Shared Hosting)
ermöglichen Rückschlüsse auf Funktionalität zu (z.B. www.scip.ch ⇒ ^www\.(.*)$ ⇒ Webserver)
ermöglichen Rückschlüsse auf Technologien zu (z.B. cpfw1.scip.ch ⇒ ^cpfw1\.(.*)$ ⇒ Checkpoint Firewall-1)
identifizieren öffentlich zugängliche Systeme

Aus diesem Grund pflegen wir eine solche Möglichkeit als Schwachstelle der niedrigsten Einstufung Low (CVSS2 Base Score 5.0, CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) zu dokumentieren. Auch wenn damit kein direkter Angriff umgesetzt werden kann, können die daraus ableitbaren Informationen eine elementare Grundlage für weiterführende Auswertungen und Angriffe schaffen.

Obschon sich die meisten Kunden bei einem ersten Projekt an dem Ausweisen dieser und ähnlicher Schwachstelle stören, können sich nach einem klärenden Gespräch unsere Bedenken nachvollziehen. In manchen Fällen wird sich entsprechend darum bemüht, dass Reverse DNS Lookups bzw. Hostnamen gänzlich abgeschafft werden. Besonders bei Systemen, die nur für den internen Gebrauch bzw. nicht für Direktzugriffe durch Clients vorgesehen sind, ist dies ein gangbarer Weg.

Umso mehr erstaunt es dann die Kunden, wenn bei einem folgenden Re-Check das Fehlen eines Hostnamens bzw. der Möglichkeit einer Namensauflösung ebenfalls als Schwachstelle der gleichen Einstufung Low vermerkt wird. Auch dieser umgekehrte Zustand kann im Rahmen eines Angriffs von Nutzen sein:

Fehlende Hostnamen …

deuten auf nicht-öffentliche Systeme hin (z.B. Router, interne Server)
verunmöglichen Zugriffe (z.B. Shared Web Hosting)
erschweren menschliche Nutzung (IP-Adressen statt Hostnamen)
erschweren Debugging (Identifikation von Systemen/Funktionen)
widersprechen Empfehlung von RFC 1912, Absatz 2.1 (Every Internet-reachable host should have a name.)

Diese Schwachstelle ist ein typisches Beispiel dafür, das sich nicht eliminieren, sondern lediglich transformieren lässt. Es gibt eine Reihe von Schwachstellen dieser Art. Nachfolgende Tabelle listet die populärsten Vertreter auf, wobei die erste Spalte die übliche Form und die zweite Spalte die empfohlene Alternative der Schwachstelle zeigt:

	Schwachstelle 1 (Normalfall)	Schwachstelle 2 (Empfohlen)
Whois Footprinting	Eintrag von Unternehmen	Eintrag eines Stellvertreters
DNS Auswertung	Reverse Lookup möglich	Reverse Lookup nicht möglich
Route-Traceing	Traceroute bis zum Zielsystem	Traceroute bis zur Firewall
Mapping	ICMP Echo Reply vom Zielsystem	ICMP Host Unreachable von Firewall
Fingerprinting	OS Fingerprinting von Zielsysten	OS Fingerprinting von Proxy/Firewall

Da wir stets darum bemüht sind unseren Kunden einen Mehrwert zu bieten, suchen wir zu Beginn eines Projekts das Gespräch. Dabei legen wir unsere Philosophie vollster Transparenz dar. Sodann kann er festlegen, ob wir diese weiterhin verfolgen oder im Rahmen des Projekts gewisse Schwachstellen ausblenden sollen (Ein gänzliches Ausblenden findet dennoch nicht statt. Die Findings werden rapportiert, jedoch nicht als gleichwertige Schwachstellen, sondern in einem separaten Anhang/Dokument).

Hierbei geht es nicht darum, dass der Report mit nichtigen Findings aufgebläht werden soll. Viel mehr ist es wichtig, dass der aktuelle Zustand in all seinen Belang festgehalten wird. Nur so kann bei weiterführenden Prüfungen oder Untersuchungen dafür gesorgt werden, dass ein Informationsvorsprung und damit ein stabiles Mass an Qualität gewährleistet werden können.

Marc Ruef | G+ (696 Wörter)

► 12.04.2012 – 1960 bis 2000 – Frühe Geschichte der Computerkriminalität

Die Betrachtungen der Geschichte der Computersicherheit hilft zu verstehen, wie das Genre und die Subkultur gewachsen sind. Dabei wird ihre Entstehungsphase mit den Phone Hackern (Phreaker) in den 60er Jahren datiert, um danach die Etablierung der Personal Computer (PC) und dem Wandel zum Computer-Hacker Ende der 70er Jahre einzuleiten. Die rasante Entwicklung des Computerbereichs in den 90er Jahren hat auch dazu beigetragen, dass sich im Bereich der Informationssicherheit die Dinge überschlagen haben.

Phone Hacker der 60er und 70er Jahre

Der Ursprung des Themas Computersicherheit, so sagt man, findet sich in den 60er Jahren. Damals waren Computersysteme noch nicht für jedermann zugänglich und die schwindende Anzahl der an Technik interessierter Personen fokussierte sich auf Telefonsysteme. Durch die Manipulation dieser und dem Umgehen von Sicherheitsmassnahmen entstand der Bereich des Phreakings. Dies ist ein Kunstwort, das aus den beiden englischen Wörtern Phone (dt. Telefon) und Hacking (dt. Hacken) besteht. In der modernen Literatur populistischer Couleur wird wehmütig auf diese Zeit zurückgeblickt.

Das Buch Der Hacker (1997) von Christian Zimmermann bespricht sehr schön die technischen Aspekte damaliger Techniken. Allen voran das populäre Blueboxing. Bei diesem wird mittels einem speziellen Ton, der durch ein Telefon geschickt wird, Einfluss auf das Steuerungssystem genommen. Durch diesen exakt 2600 Hz hohen Ton liess sich beispielsweise der Gebührenzähler deaktivieren oder Umleitungen speichern. In Hackertales (2000) von Denis Moschitto und Evrim Sen wird die Geschichte der Entwicklung dieser Möglichkeit durch John T. Draper (aka. Captain Crunch) erzählt.

Zur damaligen Zeit entwickelte sich das Phreaking schon fast ein bisschen zu einem Volkssport. Vor allem Studenten mit Interesse für Elektronik und Elektrotechnik erachteten das staatliche Telefonnetz als Spielwiese. Immerwieder wurden neue Techniken entwickelt, mit denen gebührenfrei telefoniert oder andere Spielereien umgesetzt werden konnten. So entwickelten sich auch Untergrund-Gruppierungen und Magazine (z.B 2600). Damit war der Informationsaustausch der Phreaker gewährleistet, was den Telefongesellschaften natürlich gar nicht behagte, denn diese mussten sich von nun an mit immer raffinierterer Telefon-Piraterie herumärgern. Ursprünglich als kleines Übel abgetan, realisierten die Betreiber das Problem und versuchten sich in der Umsetzung effektiver Gegenmassnahmen.

Das Thema Phone-Hacking verlor in den 90er Jahren fortwährend an Reiz. Die Telefongesellschaften hatten mittlerweile ausgeklügelte Systeme etabliert, so dass das Umsetzen klassischer Boxing-Techniken nicht mehr ohne weiteres möglich war. Aber auch mit dem Fall der Telefon-Preise war das Interesse am freien Telefongespräch nicht mehr wirklich gegeben. Dennoch gab und gibt es weiterhin Techniken, die vereinzelt angewendet werden.

Das Thema Beigeboxing, bei dem sich in eine bestehende Telefonleitung eingeklinkt wurde, ist vor allem in Bezug auf öffentliche Telefone interessant geblieben. Durch das Wardialing werden Nummernbereiche nach verwertbaren Systemen (z.B. Voicemail-System oder Remote-Modem) abgesucht. Das Thema Chipkarten-Hacking ist nach wie vor interessant, erfordert aber ein sehr hohes Mass an technischem Verständnis und oftmals das Vorhandensein teurer Hardware. Mit der ISDN-Technologie wurden neue Möglichkeiten für Angriffe gewährt, die vor allem die 90er Jahre dominiert haben, aber nicht mehr zu einer sehr hohen Verbreitung des Phreakings beitragen konnten.

Das Thema GSM wurde bis vor einigen Jahren noch eher stiefmütterlich behandelt, wobei das zugrundeliegende System mittlerweile als gänzlich gebrochen angesehen werden muss. Nachfolgende Generationen wie UMTS wird voraussichtlich das gleiche Schicksal ereilen.

Gegenwärtig ist der Bereich von Voice-over-IP (VoIP) in aller Munde. Durch die Telefonnutzung über bestehende IP-Kanäle wird einmal mehr die Zusammenführung klassischer Phreaking-Technik und modernem Netzwerk-Hacking gegeben sein.

Die ersten Hacker der 70er und Anfang 80er Jahre

Als Ur-Hacker werden jene Persönlichkeiten bezeichnet, die sehr früh zur Entwicklung und Mitgestaltung der Computer-Technologien beigetragen haben. Der Begriff Hacker wurde dabei mehr als Titel für eine Person verliehen, die ein komplexes Problem sehr effizient adressieren und lösen konnte. Neben den Entwicklern traditioneller Betriebssysteme sind auch die Autoren von Programmiersprachen typische Hacker der alten Generation.

Spieltrieb und kriminelle Interessen haben dazu geführt, dass das Thema Computerkriminalität schon sehr früh gegeben war. Interessant dabei ist, dass schon zu Beginn der 70er Jahre computergestützte Betrugsfälle dokumentiert sind. Eine Auflistung zu wichtigen historischen Ereignissen im Bereich der Computersicherheit wird hier zur Verfügung gestellt. Beispiele:

1973 betrügt ein Angestellter der New York Time Savings Bank seinen Arbeitgeber um 1 Million US$.
1980 gelingt dem sechzehnjährigen Kevin Mitnick mit seiner Roscoe-Bande ein Einbruch in US Leasing.
1984 stellt der Berliner Chaos Computer Club (CCC) den BTX-Hack vor.
1987 dringen Mitglieder des Berliner Chaos Computer Clubs in das SPAN-Netzwerk der NASA ein.
1988 infiziert das Wurmprogramm von Robert Tappan Morris innerhalb weniger Stunden 6‘000 Internet-Hosts.

Die neue Generation der 90er Jahre

Mit der Popularisierung des Internets entwickelt sich das Thema Computersicherheit mit einer ebenso rasanten Geschwindigkeit. Errungenschaften auf der Seite von Sicherheitsspezialisten gehen mit neuen Angriffsvarianten der Hacker-Community einher. Neue Technologien, Techniken und Methoden werden am laufenden Band vorgestellt und übertrumpfen sich immerwieder mit einer neuen Qualität und Raffinesse. Es bilden sich eine Vielzahl an Hacker-Vereinigungen, die sich mitunter für das Aufdecken neuer Schwachstellen stark machen und die Internet-Gemeinschaft vor korrupten Übergriffen warnen wollen. Eine schöne Illustration der damaligen Entwicklungen ist im Artikel Die Entwicklung der (deutschsprachigen) Hacker-Szene festgehalten.

Der Spieltrieb und Neugierde der Angreifer hat Kosten für Industrie und Wirtschaft verursacht. Fortwährend werden neue Fällen von umfangreichen Einbrüchen oder Sabotage-Akten bekannt. Mitte der 90er Jahre spitzt sich der Fall um den US-Amerikaner Kevin Mitnick zu. Nach zweijähriger Fahndung wird er vom FBI verhaftet. Eine etwas einseitige literarische Erzählung der damaligen Ereignisse ist im Buch Data Zone (1996) von Tsutsomu Shimomura und John Markoff festgehalten. Ersterer war massgeblich an der Ergreifung von Mitnick beteiligt. Die mit dem Titel Takedown (2000) erschienene Verfilmung des Buches erschien ebenso voreingenommen und wurde durch eine Gegendarstellung der schönen Dokumentation Freedom Downtime (2001) von Emmanuel Goldstein, einem engen Freund Kevin Mitnicks, relativiert.

Historizismus: Was bringt die Zukunft?

Die Entwicklung im Computerbereich zeigt, dass eine immer grössere Abstraktion gegeben ist. Wobei früher noch mittels Assembler auf einzelne Register des Speichers zugegriffen wird, erfordern moderne Programmiersprachen wie Microsoft .NET nur noch das Ansteuern symbolischer Objekte. Das Verständnis für die innere Funktionsweise der Systeme schwindet aufgrund dieser Meta-Schichten zunehmends. Davon ist ebenfall der Bereich der Computersicherheit betroffen, in dem Transparenz und Verständnis für einzelne Abläufe unabdingbar bleibt. So gibt es immer mehr eine Kluft zwischen normalen Endanwendern ohne tiefschürfende technische Kenntnisse und semi-professionellen Angreifern mit solidem technischem Verständnis. Letztere sehen sich aber zunehmends mit einer Professionalisierung im Bereich der Computersicherheit konfrontiert, so dass moderne Schutzsysteme es überhaupt immer schwieriger machen, ein System erfolgreich anzugreifen. Dies ist mit einem militärischen Wettrüsten vergleichbar, bei dem Angreifer neue Angriffstechniken entwickeln und die Industrie neue Gegenmassnahmen dagegen verkaufen will.

Marc Ruef | G+ (1147 Wörter)

► 05.04.2012 – Missverständnis Ausfallsicherheit

In professionellen Umgebungen stellt Ausfallsicherheit ein sehr wichtiger Aspekt dar. Dieser versucht die Verfügbarkeit eines Objekts, dies kann beispielsweise ein Server oder ein Dienst sein, konstant bereitzustellen. Im Idealfall kann 100% Verfügbarkeit, also das Ausbleiben jeglichen Ausfalls, erreicht werden. Um dies mit grösstmöglicher Zuverlässigkeit gewährleisten zu können, müssen jedoch verschiedene Vorkehrungen getroffen werden.

Stabilität als Grundlage

Einerseits muss die intrinsische Stabilität der Komponente gewährleistet werden können. Sie muss also im täglichen Betrieb zuverlässig agieren und reagieren können. Ein Webserver muss beispielsweise mit den üblichen HTTP-Anfragen zurechtkommen. Zusätzlich muss aber ebenfalls die Zuverlässigkeit der Schnittstellen zu anderen Komponenten, zum Beispiel weiterführende Datenbank-Zugriffe auf das Backend, gegeben sein.

Es gibt jedoch immerwieder Situationen, in denen diese Stabilität nicht mit absoluter Stetigkeit erreicht werden kann. Dies ist vor allem dann mindestens auf theoretischer Ebene möglich, wenn unvorhergesehene Ereignisse eintreffen. Dies können beispielsweise auf Software-Ebene deformierte HTTP-Anfragen eines böswilligen Benutzers sein. Es kann sich aber auch nur um fehlerhafte Datensätze einer korrupten Datenbank handeln. Viel schlimmer und permanenter sind hingegen Hardware-Fehler, die sehr schnell zum kompletten Ausfall eines Systems führen können.

Redundanz erhöht Verfügbarkeit

Um diesen unerwarteten Situationen gerecht werden zu können, wird versucht mittels redundanten Komponenten das gewünschte Mass an Ausfallsicherheit wiederherstellen zu können. Dabei werden jene Komponenten, die das Risiko eines Ausfalls mit sich bringen, mehrfach verfügbar gemacht. Beispielsweise können zwei Internet-Anbindungen vorhanden sein, um im Fall von Problemen mit Anbindung 1 auf Anbindung 2 zu wechseln.

Redundante Komponenten können dabei in verschiedenen Betriebsmodi vorhanden sein. Werden beispielsweise zwei Festplatten als RAID-1 eingesetzt, können die Daten auf diese zeitgleich geschrieben werden. Ist ein Ausfall einer Platte gegeben, kann nun ganz auf die Daten der anderen Platte zugegriffen werden. Es befinden sich hier beide Platten stets im Betrieb und die Übernahme des Dienstausfalls geschieht unverzüglich. Dies ist Teil des Failover und wird Hot-Standby genannt.

Der Betrieb einer Komponente, vor allem beim Mütführen von viel Mechanik oder Elektronik, verringert zwangsweise die Lebensdauer eben dieser. Aus diesem Grund werden mancherorts redundante Komponenten nicht zeitgleich betrieben, sondern stehen im Fall eines Ausfalls als Ersatz bereit. Jenachdem muss die neue Komponente manuell in den Betrieb eingeführt werden. Beim Beispiel der Festplatten könnte dies das Einspielen des Backups voraussetzen, wodurch eine gewisse Ausfallzeit einberechnet werden muss. Dies wird als Cold-Standby bezeichnet.

Missverständnis im Cloud Computing

Im Zusammenhang mit Cloud Computing wird eben diesem immerwieder die vielgewünschte und schwierig zu gewährleistende Hochverfügbarkeit angedichtet. Es wird behauptet, dass in der Cloud keine Daten verloren bzw. Dienste ausfallen können, da sich diese stetig und in dynamischer Weise neu organisieren kann. Diese Deklaration ist jedoch nicht per se zu beobachten. Die Ausfallsicherheit innerhalb einer Cloud ist dabei den gleichen Gesetzen unterworfen, wie bei jedem anderen Rechenzentrum auch: Auch hier müssen die jeweiligen Komponenten redundant betrieben werden.

Gerade Dienstleistungen im PaaS/IaaS-Bereich (z.B. Amazon EC2) warten mit verteilten Rechenzentren auf. Ob diese jedoch effektiv redundant betrieben und darin ebenfalls redundante Komponenten enthalten sind, lässt sich damit nicht automatisch bejahen.

Beispielsweise war beim Ausfall von Amazon EC2 im April 2011 (Technische Analyse) ein Routing-Fehler verantwortlich, der zur Überlastung geführt hat und damit die Synchronisation der EBS-Nodes (Elastic Block Store) unterbrochen war. Ironischerweise also gerade jener Mechanismus, der die Verteilung zur Erreichung der Redundanz ermöglichen sollte, zeichnete sich für den Ausfall verantwortlich. Da aufgrund einer Race Condition keine Schreibzugriffe mehr durchgeführt werden konnten, gingen Daten unwiederruflich verloren. Zu einem Problem ähnlichen Ausmasses hat im August des gleichen Jahres ein Unwetter geführt (Zeitlicher Ablauf).

Fazit

Das redundante Betreiben kritischer Komponenten zur Erhöhung der Ausfallsicherheit ist unabdingbar. Dies setzt jedoch ein durchdachtes Konzept voraus, welches die Wichtigkeiten und Abhängigkeiten der Komponenten untereinander berücksichtigt.

Gerade das Beispiel der Zwischenfälle in Amazon EC2 zeigt auf, dass Ausfallsicherheit nicht einfachso erreicht werden kann. Und auch wenn diese erreicht scheint, gibt es – solange nicht jede Komponente mehrfach und unabhängig betrieben wird – stets die Möglichkeit eines Ausfalls.

Marc Ruef | G+ (725 Wörter)

► 29.03.2012 – Blog Digest März 2012

10 Movie Scenes Of Authentication Worth Rewatching (darkreading.com)
10 Tips to Fight Insider Fraud (govinfosecurity.com)
2012 Database Threats (pciguru.wordpress.com)
7 Problems with Cell Phone Forensics (feedproxy.google.com)
Actually, my name is Duqu – Stuxnet is my middle name (stratsec.blogspot.com)
Algorithms: When is Random Really Random? (infosecisland.com)
Clickjacking, Cursorjacking and Common Facebook Vulnerabilities (infosecinstitute.com)
Configuring Network Level Authentication for RDP (darkoperator.com)
Detecting Brazilian Banking Trojans with Snort http_inspect (SpiderlabsAnterior)
DGA’s vs Automated Malware Signature Generation (blog.damballa.com)
Doing Biz with Hackers: Do Bad Guys Make the Best Good Guys? (infosecisland.com)
Five Strategic Security Metrics To Watch (darkreading.com)
How to prepare for Google’s privacy changes (cnn.com)
How to Protect Yourself from Skimmers (infosecisland.com)
How Windows 8 Sharing Blows Mountain Lion Out of the Water (mashable.com)
iOS Data Security – Protecting Data on unmanaged Devices (securosis.com)
iPad 3 Out – Now Keep It Safe (blog.fortinet.com)
Linux 3.3 release (lkml.org)
Malware reporting study: more infomation leads to higher cleanup rate (StopbadwareBlog)
MS12-020 BinaryDiff (blog.binaryninjas.org)
Prevent VoIP Toll Fraud with Proper Configurations (infosecisland.com)
Quality Coding Takes A Break For The Holidays. But Why? (threatpost.com)
Reflections on a Past Vulnerability, Kind Of… (stateofsecurity.com)
Reliable Windows 7 Exploitation: A Case Study (ifsec.blogspot.com)
Safe Coding and Software Security Infographic (veracode.com)
Snort.org Blog: Rule Category Reorganization (Snort)
Social networks & Deactivated Friend Attack, the cybercrime paradise… (securityaffairs.co)
Some evidence on multi-word passphrases (lightbluetouchpaper.org)
Some random observations on Linux ASLR (scarybeastsecurity.blogspot.com)
The End of Vulnerabilities? (darkreading.com)
The Futility of Web Pen Testing (deadliestwebattacks.com)
The XOR Bypass (blog.damballa.com)
Top 10 Oracle Steps to a Secure Oracle Database (blog.opensecurityresearch.com)
Twelve Security Best Practices for USB Drives (infosecisland.com)
What They Don’t Teach You in ‘Thinking Like the Enemy’ Classes (infosecisland.com)
When Do I Need to Apply This Update – Adding Priority Ratings to Adobe (blogs.adobe.com)
When Was The Term Exfiltration First Used? (blog.zeltser.com)

Marc Ruef | G+ (590 Wörter)

► 22.03.2012 – Kompromittierung einer Sprachmailbox

Um auf eine Sprachmailbox (engl. Voice-Mail) zugreifen zu können, muss sich bei dieser Authentisiert werden. Hierzu werden zwei unterschiedliche Verfahren eingesetzt:

Identifikation anhand der Rufnummer
Authentisierung anhand einer PIN

Die erstgenannte Möglichkeit wird typischerweise genutzt, um die Nachrichten für die eigene Nummer abhören zu können. Die zweite Möglichkeit wird als Alternative eingesetzt, wobei durch Fernzugriffe auf ab anderen Geräten die Nachrichten abgehört werden können.

Angriffe auf Sprachmailbox

Das Klonen und Spoofen von Telefonnummern ist jenachdem möglich, bedingt aber ein relativ hohes Verständnis für die zugrundeliegenden Technologien. Zudem muss die Konfiguration der Umgebung und des Routings, welche durch den Telefonanbieter vorgenommen wird, verschiedene Schwächen aufweisen (z.B. kein Durchsetzen von Rufnummern, kein striktes Routing). Diese Angriffsmöglichkeit wird heutzutage am ehesten im Voice-over-IP Bereich interessant.

Das Kompromittieren einer Sprachmailbox wird aber typischerweise durch die Möglichkeit des Fernzugriffs umgesetzt. Diese Angriffstechnik ist verhältnismässig primitiv und auch aus anderen Bereichen übertragbar.

Hierzu wird ein Anruf auf die Sprachmailbox getätigt und dann versucht den PIN zu erraten. Viele Telekommunikationsanbieter erlauben 4- bis 8-stellige PINs. Diese sind oftmals bei der Aufschaltung einer Nummer vordefiniert und es wurde immerwieder berichtet, dass Standard-PINs (z.B. 1234 oder die letzten 4 Stellen der Telefonnummer) zum Tragen kommen. Der Benutzer kann in der Regel seinen PIN ändern und auch hier ist das altbekannte Problem der Wahl schwacher Passwörter zu beobachten. Gern genutze PINs sind in der Regel (in dieser Hinsicht ist die statistische Auswertung von Daniel Amitay wegweisend):

Einfach zu merkende Zahlenreihen (z.B. 1234, 1111)
Geburtsdaten, Jahrestage (z.B. 1102, 1981)
Muster auf der Tastatur (z.B. 1245, 2580)

Manche Anbieter erlauben ein beliebiges Durchprobieren des PINs bis zur erfolgreichen Authentisierung. Dadurch werden Bruteforce-Attacken, die sich mit entsprechenden DTMF-Lösungen automatisieren lassen, möglich. Bestimmte Anbieter benachrichtigen hingegen den Anschlussinhaber per SMS, falls eine mehrfache Falscheingabe erfolgt ist.

Konnte sich Zugriff auf die Sprachmailbox verschafft werden, können entsprechende Manipulationen vorgenommen werden. Einerseits lassen sich die Konfigurationseinstellungen ändern (z.B. Funktion abschalten, PIN ändern). Andererseits können die bestehenden Mitteilungen abgehört und gelöscht werden.

Desweiteren besteht in der Regel die Möglichkeit, einen Rückruf umzusetzen. Dabei wird der Absender einer vorliegenden Nachricht zurückgerufen. Interessant dabei ist, dass oftmals der Anruf selbst nicht vom externen Gerät, sondern vom Anschluss der abgehörten Sprachmailbox getätigt wird. Auf dem Display des zurückgerufenen Geräts wird sodann die Rufnummer Sprachmailbox angezeigt und auch auf diesen Anschluss eine Verrechnung vorgenommen.

Durch diese Angriffstechnik wird es möglich, dass zusätzliche Kosten generiert werden. Der Angreifer ruft von einer kostenpflichtigen Nummer, die sich in seinem Besitz befindet, auf die Sprachmailbox an. Danach wählt er sich in diese ein und initiiert einen Rückruf. Die dabei anfallenden Kosten werden dem Opfer aufgerechnet.

Gegenmassnahmen

In erster Linie kann sich der Telefonanbieter darum bemühen, Massnahmen zum Verhindern bzw. Erschweren dieser Angriffsmöglichkeit einzuführen. Fehlerhafte Login-Versuche auf die Sprachmailbox sollten protokolliert und ausgewertet werden. Mehrmalige Zugriffe dieser Art sollten eine Benachrichtigung des Anschlussinhabers und eine temporäre Sperrung von Fernzugriffen (diese kann auch nur ein paar Minuten anhalten) zur Folge haben.

Zudem kann der Telefonanbieter darum bemüht sein, mittels Anomaly Detection ein abnormales Anrufverhalten zu identifizieren. Normalerweise werden zum Beispiel innerhalb einer Woche 50 Anrufe getätigt, bei denen Kosten von CHF 200 anfallen. Werden die Woche darauf drei Mal so viele Anrufe und ein fünffaches Kostenvolumen identifiziert, sollte wiederum der Anschlussinhaber informiert und bei extremen Abweichungen eine Anrufsperre durchgesetzt werden. (Uns sind Fälle bekannt, bei denen die Kosten eines erfolgreichen Betrugs das hundertfache der üblichen Kosten erreicht hat.)

Der Telefonanbieter sollte beim Einrichten der Sprachmailbox entweder Fernzugriffe gänzlich sperren oder einen zufällig gewählten PIN vordefinieren. Ebenso sind Benutzer angehalten, die von ihnen gewählten PINs möglichst lang und komplex ausfallen zu lassen. Ein regelmässiges Ändern der PINs (z.B. einmal pro Jahr) reduziert das Fenster für erfolgreichen Missbrauch erheblich.

Marc Ruef | G+ (671 Wörter)

► 15.03.2012 – RSS-Feeds als Angriffsvektor

Das Akronym RSS steht für Really Simple Syndication. Hierbei handelt es sich um eine Familie um Formaten, die zur strukturierten Veröffentlichung von Informationen entwickelt wurde. Vorzugsweise werden durch Webseiten RSS-Feeds angeboten, auf denen die jeweiligen Neuigkeiten verteilt werden.

RSS-Feeds sind XML-basiert. Sie bestehen aus einem Header, der allgemeine Informationen zum Feed bereitstellt. Zum Beispiel der Titel des Feeds, ein Link zur Webseite, eine Beschreibung und Copyright-Informationen. Im weiteren folgen einzelne Items, die die eigentlichen Informationsteile bereitstellen. Diese beinhalten ebenso verschiedene Felder, wie zum Beispiel Titel, Link, Veröffentlichungsdatum und Beschreibung. Beispiel:

<item>
   <title>Eine interessante Meldung für unsere Leser</title>
   <link>http://www.scip.ch/?news.20120125</link>
   <guid isPermaLink="true">http://www.scip.ch/?news.20120125</guid>
   <pubDate>Thu, 15 Mar 2012 07:15:00 +0100</pubDate>
   <dc:creator>scip AG</dc:creator>
   <description>
      <![CDATA[Hier stehen weitere Details drin.]]>
   </description>
</item>

In der Regel stellen also Webseiten (Server) diese Feeds bereit. (Auf unserer Webseite bieten wir ebenfalls verschiedene RSS-Feeds an.) Diese werden durch RSS-Clients bei Bedarf oder in regelmässigen Abständen (z.B. alle 60 Minuten) abgefragt. Entdeckt der Client, dass ein neues Item publiziert wurde, wird es entsprechend als ungelesen dargestellt. Ein Benutzer kann mit einer solchen Abonnierung komfortabel und unkompliziert die neuesten Informationen (z.B. News, Änderungen) zusammentragen. Es gibt sowohl dedizierte RSS-Clients, die als eigenständige Anwendungen fungieren. Ebenso bieten viele Mail-Clients und Browser-Implementierungen von Haus aus oder durch zusätzliche Addons eine entsprechende RSS-Funktionalität zur Verfügung. Zusätzlich gibt es webbasierte RSS-Clients, die zum Beispiel als Plugin in ein bestehendes CMS eingebunden werden können.

Viele Entwickler von RSS-Clients – egal ob nun als eigenständige Applikationen, Addons oder Web-Plugin – vernachlässigen die Risiken einer solchen Lösung. Dabei wird gerne übersehen, dass es sich bei diesem Modell im Grundprinzip um das Gleiche handelt, welches auch beim klassischen Web (Webserver/Webbrowser) zum Tragen kommt:

Der Server liefert die angeforderten Daten an den Client aus (1), der seinerseits für die Interpretation (2) und Darstellung (3) dieser zuständig ist.

Dies kann einerseits zu typischen Eingabeungültigkeiten kommen. Vor allem dann, wenn die Interpretation des XML-Gerüsts durch einen proprietären Parser durchgeführt wird. Durch fehlende, fehlerhafte, verschachtelte, korrupte oder doppelte Tags können sich anwendungsbasierte Angriffsvektoren erschliessen. Dazu gehören beispielsweise Denial of Service-, Pufferüberlauf- oder Format String-Schwachstellen. Der Einsatz eines verlässlichen XML-Parsers, der mittlerweile bei allen modernen Hochsprachen zur Verfügung gestellt wird, vermag diese Gefahr zu bannen.

Weiterführend wird aber auch gerne übersehen, dass RSS-Feeds als Träger für korrupte Inhalte eingesetzt werden können. Durch das Einbetten von bösartigen Elementen können Angriffe auf Clients angestrebt werden. Hierzu bieten sich in einem ersten Schritt Multimedia-Inhalte (Bilder/Videos) an. Aber auch ausführbare Elemente auf der Basis von Javascript, Java und ActiveX können missbraucht werden. Ein sicherer RSS-Client sollte deshalb darauf bedacht sein, lediglich unkritische Inhalte nachzuladen und auszuführen.

Einen Fehler dieser Art haben wir vor einigen Jahren im RSS-Widget von IBM Lotus Notes ausgemacht. Hier war es mitunter möglich, Javascript durch RSS-Feeds verteilen zu lassen. Zusätzlich spielte hier aber noch ein anderer Effekt mit, der die Tragweite der Angriffsmöglichkeit erweiterte. Und zwar wurden sämtliche RSS-Inhalte nach dem Download lokal gespeichert und im lokalen Kontext des Internet Explorer ausgeführt. Dies führte dazu, dass für die aktiven Inhalte verringerte Sicherheitseinstellungen gelten sollten, wodurch sich erweiterte Zugriffe durchführen liessen.

Marc Ruef | G+ (571 Wörter)

► 08.03.2012 – Video zu Code Plagiarism an Hashdays 2011

An den vergangenen Hashdays in Luzern wurde durch Luca Dal Molin und meine Person ein Vortrag mit dem Titel Code Plagiarism – Technical Detection and Legal Prosecution gehalten. In diesem wird anhand meines Attack Tool Kit Project die Geschichte von kommerziellem Code-Dienstahl erzählt. Luca Dal Molin zeichnete sich für das Aufzeigen der juristischen Eckdaten dieser Geschichte verantwortlich.

Das Video des Vortrags wurde mittlerweile durch die Organisatoren online gestellt und kann mitunter auf YouTube gesehen werden. Die Slides zum Vortrag stehen auf Slideshare zur Verfügung. Die Geschichte selbst ist umfassend in den drei Blog-Posts dokumentiert.

Marc Ruef | G+ (153 Wörter)

► 29.02.2012 – Blog Digest Februar 2012

8 Breach Prevention Tips (govinfosecurity.com)
A Career in Forensics: 5 Key Steps (govinfosecurity.com)
Algorithms: When is Random Really Random? (infosecisland.com)
A Milestone in IPv6 Deployment (ddos.arbornetworks.com)
Android malware employs steganography (f-secure.com)
Attackers Use Fake Friends to Blend into Facebook (barracudanetworks.com)
Block a country with my Cisco Router or Firewall (blogs.cisco.com)
Chinese Hackers Suspected in Nortel Breach (wsjonline.com)
Cybercriminals Moving Over To TLD .su (abuse.ch)
Designing enterprise systems for the accidental incident (Wh1t3Rabbit)
Digital Exams on the iPad (speirs.org)
ESET researchers on Windows Phone 8 Security (ESET)
Exploring Your Browser LocalStorage (blog.opensecurityresearch.com)
Five principles to better your security monitoring (darkreading.com)
Five Schemes For Redeeming Trust in SSL (darkreading.com)
Five Strategic Security Metrics To Watch (darkreading.com)
How (And Why) Attackers Choose Their Targets (darkreading.com)
How Companies Learn Your Secrets (nytimes.com)
How To Defend Your Database From Malicious Insiders (darkreading.com)
How to navigate Google’s privacy options (GrahamCluleysBlog)
Incident Response: Have You Got a Plan? (infosecisland.com)
JSON CSRF with Parameter Padding (blog.opensecurityresearch.com)
Kippo is being detected by Metasploit (bruteforce.gr)
Maximizing Value in Pen Testing (pen-testing.sans.org)
Mobile Devices Just Another Endpoint (darkreading.com)
Nessus 5.0 Released! (blog.tenablesecurity.com)
NYPD Developing THz Body Scanners to Detect Weapons (thznetwork.net)
Penetration Testing for iPhone Applications (resources.infosecinstitute.com)
Prevent VoIP Toll Fraud with Proper Configurations (infosecisland.com)
Quantifying Risk Reduction with an Unknown Denominator (Wh1t3Rabbit)
Redesigning the Windows Logo (windowsteamblog.com)
Server-side Polymorphic Android Applications (symantec.com)
Some IDS comments (erratasec.blogspot.com)
The Aftermath Of A Breach (darkreading.com)
The Differences Between Security Certifications (infosecisland.com)
Timing Analysis Attacks in Anonymous Systems (resources.infosecinstitute.com)
Twelve Security Best Practices for USB Drives (infosecisland.com)
When in the Cloud, Trust – but Verify (technewsworld.com)
When Was The Term ‘Exfiltration’ First Used? (blog.zeltser.com)
Who has better privacy laws: USA or European Union? (GrahamCluleysBlog)
Why stream ciphers shouldn’t be used for hashing (rdist.root.org)

Marc Ruef | G+ (652 Wörter)

► 23.02.2012 – Vereinheitlichen von Schwachstellen als Schwachstellenklassen

In einem privaten Blog-Beitrag habe ich vor rund einem Jahr ein Problem beschrieben, welches bei systematischen Sicherheitsüberprüfungen immerwieder zu Diskussionen führt:

Wann ist eine Schwachstelle eigenständig, wann eine individuelle Manifestation einer allgemeinen Schwachstelle in einem spezifischen Produkt und wann eine dedizierte Schwachstelle einer Schwachstellenklasse?

Nachfolgende Grafik illustriert den logischen Aufbau einer bestimmten Schwachstellenklasse. Die Wurzel des Baums ist definiert durch Fingerprinting. Dieses wird exemplarisch in OS Fingerprinting und Application Fingerprinting unterteilt. Letzteres ist wiederum exemplarisch in Webserver Application Fingerprinting (auch HTTP-Fingerprinting genannt) und CMS Application Fingerprinting unterteilt. Und auch hier ist letzteres exemplarisch in TYPO3 Fingerprinting und WordPress Fingerprinting unterteilt worden.

Beispiel der Gruppierung von Schwachstellen

Als Beispiel der Identifikation von WordPress werden sodann Merkmale wie Pfadnamen, Dateinamen, Cookies, und Klassennamen aufgelistet. Das Prinzip einer solchen Analyse haben wir vor rund zwei Jahren im Beitrag Identifikation von Webapplikationen besprochen.

Die Frage ist nun, ob der Genauigkeit halber jedes gefundene Identifikationsmerkmal als separate Schwachstelle dokumentiert werden soll. Schliesslich weist jede von ihnen ein individuelles Exploiting – spätestens beim Erkennen des jeweiligen Merkmals – auf. Und so ist auch das Umsetzen von Gegenmassnahmen bei allen ähnlich, dann aber doch anders (z.B. Dateinamen zu ändern ist etwas gänzlich unterschiedliches weder Cookie-Strukturen anzupassen).

Das Problem einer solchen Aufgliederung ist jedoch, dass sich Fehlerquellen nur schwer einfachso vergleichen lassen. Werden zwei Systeme geprüft, kann nicht einfach die Aussage getroffen werden, ob Schwachstelle X auf beiden Systemen zutrifft. Dies ist schliesslich spätestens dann nicht der Fall, wenn auf beiden unterschiedliche Content-Management-Systeme zum Einsatz kommen (zwar können sowohl bei TYPO3 als auch bei WordPress das Produkt anhand der Cookie-Namen identifiziert werden, jedoch ist das zu suchende Pattern gänzlich unterschiedlich):

(Exploiting A ≠ Exploiting B) ⇒ (Schwachstelle Produkt A ≠ Schwachstelle Produkt B)

Das Zusammenfassen von Schwachstellen ist die Folge davon. Will man also ein TYPO3 mit einem WordPress vergleichen, darf man sich nicht an produktspezifische Eigenarten klammern. Doch diese Details sind genau das, was eine gute Sicherheitsüberprüfung ausmachen.

Die einzige Lösung besteht darin, zwar mit granularen Details zu arbeiten. Diese jedoch auf einer Meta-Ebene zu gruppieren. Die Identifikation eines Cookies muss also unabhängig vom betroffenen Produkt vergleichbar sein:

[(Schwachstelle X ∧ Produkt A) ⇒ Klasse X] = [(Schwachstelle X ∧ Produkt B) ⇒ Klasse X]

Die Schwierigkeit besteht darin, diese logischen Gruppen zu etablieren. Die Frage kann nämlich nun weitergetrieben werden, ob denn nun ein bekannter Pfadname bei einem Installations-Paket vergleichbar ist mit dem bekannten Pfadnamen einer Standardinstallation.

Wir arbeiten seit geraumer Zeit daran, dieses Problem zu lösen und damit unseren Kunden den Mehrwert aus Modularität/Genauigkeit und Homogenität/Vergleichbarkeit bereitstellen zu können. Dies erfordert sehr viel Formalisierung und Verständnis für die jeweiligen Schwachstellen. Ein Problem, das ursprünglich nur philosophischer Natur angemutet hat, hat sich damit eindeutig in der Praxis manifestiert.

Marc Ruef | G+ (489 Wörter)

► 16.02.2012 – Backdooring mittels Outlook Rules

Das Fernsteuern von kompromittierten Systemen ist ein wichtiger Aspekt bei der Durchführung von Penetration Tests. Denn nur so kann eine weitreichende Manipulation des Zielobjekts vorgenommen, Rechte erweitert und sensitive Daten exfiltriert werden.

Klassisches Remote-Controlling fusste auf Client-/Server-basierten Tools wie BackOrifice, Netbus und SubSeven. Diese müssen aber als ausführbare Komponenten auf dem Ziel abgelegt und gestartet werden. Das Einschleusen und Ausführen von vorkompilierter Malware gestaltet sich aber im Zeitalter von NAT, Proxies, Antivirus und IPS-Lösungen nicht mehr so einfach.

Im Rahmen eines kundenspezifischen Projekts waren wir darum bemüht, die Fernsteuerung eines Systems über Outlook vorzunehmen. Zu diesem Zweck wurden auf dem kompromittierten System verschiedene E-Mail Rules erstellt. Diese führen beim Eintreten eines bestimmten Ereignisses eine vordefinierte Aktion aus. Nachfolgende Abbildung illustriert eine der eingebrachten Rules.

Remote-Control mit Outlook

Als externe Angreifer wurde es damit möglich, mit dem Versand eines Emails an die Zieladresse die gewünschte Aktion zu provozieren. Durch Ausführen von Applikationen liessen sich vorinstallierte Software, erweiterte Kommandos und eigene Skripte initiieren. Das Beispiel mit notepad.exe ist noch relativ harmlos. Stattdessen könnten auch neue Benutzer mittels net user sciphacker backdoor2012 /ADD angelegt werden.

Rules lassen sich exportieren und importieren, wodurch sie auch projektübergreifend genutzt werden können. Zur Absicherung eines kompromittierten Hosts – damit keine Fernsteuerung durch Dritte durchgesetzt werden kann -, kann ein an Portknocking angelehntes Verfahren eingebracht werden (z.B. bestimmte Struktur in der Betreff-Zeile).

Dieser Ansatz des Backdooring führt verschiedene Vorteile ein. Einerseits sind viele Sicherheitsmechanismen nicht in der Lage, eben diese manipulativen Zugriffe zu erkennen und abzuwenden. Ebenso gestaltet sich auch eine manuelle forensische Untersuchung als schwierig, da hier ein Bereich angegangen wird, der von Analysten gerne ausgelassen wird.

Marc Ruef | G+ (300 Wörter)

► 09.02.2012 – Systematik einer praktikablen Kryptoanalyse

Ein klassischer und nach wie vor wichtiger Bestandteil moderner Informationssicherheit ist die Kryptologie. Und mit ihr wird im Rahmen von Sicherheitsüberprüfungen auch die Kryptoanalyse von zentraler Wichtigkeit. Durch sie sollen kryptografisch geschützte Mechanismen verstanden und gebrochen werden.

Es gibt eine Vielzahl an Büchern und Fachpublikationen zum Thema Kryptografie. Und auch einige Schriften zur Kryptoanalyse. Die meisten von ihnen setzen sich jedoch auf rein technischer Ebene mit dem Thema auseinander. Anhand konkreter Vorgehensweisen werden die jeweiligen Mechanismen illustriert, ohne die generischen konzeptionellen Hintergründe der Herangehensweise zu besprechen.

Dieser Beitrag soll also auf nicht-technischer Ebene zeigen, wie ein kryptografisches System gebrochen wird. Eine praktikable Kryptoanalyse in einem Real-World Penetration Test durchläuft dabei unterschiedliche Phasen, auf die wir einzeln eingehen werden:

Erkennen kryptografischer Mechanismen
Ermitteln der Aufgabe des Mechanismus
Identifizieren der Technologien
Generische und bekannte Attacken auf die Technologie
Individuelle Attacken auf die Implementierung

Erkennen kryptografischer Mechanismen

Als erstes muss der Analyst überhaupt erkennen, dass ein kryptografischer Mechanismus zum Einsatz kommt. Ist eine Kryptoanalyse lediglich ein (kleiner) Teil eines Penetration Test oder Reverse Engineering, dann geschieht dies spätestens bei der allgemeinen Durchsicht des Zielobjekts. Zum Beispiel bei der Betrachtung einer Webapplikation, die für einen aufmerksamen Benutzer an verschiedenen Stellen kryptografische Mechanismen einzusetzen pflegt. Beispielsweise:

Benutzerauthentisierung
Passwort-Hashing
Challenge-Response-Verfahren
Session-ID
Captchas
Kommunikationsauthentisierung
Kommunikationsverschlüsselung
Datenverschlüsselung

Grundsätzlich deutet jede willkürlich erscheinende Zahlen- oder Buchstabenreihe auf einen etwaigen kryptografischen Mechanismus hin. Besonders hexadezimale Darstellungsformen gelten als starke Indikatoren hierfür. Diese können beispielsweise im Aufbereiten und Darstellen von Dokumenten sowie im Austausch von Informationen und Daten vorkommen.

Ermitteln der Aufgabe des Mechanismus

Das Erkennen kryptografischer Mechanismen definiert in einem späteren Schritt die möglichen Angriffsvektoren in Bezug auf eine Kryptoanalyse. Doch zuerst muss überhaupt verstanden werden, was die Aufgabe (das Ziel) des jeweiligen Mechanismus ist:

Mechanismus	Aufgabe
Benutzerauthentisierung	Authentisierung und Identifizierung des Benutzers
Passwort-Hashing	Schutz übermittelter/abgelegter Passwörter
Challenge-Response-Verfahren	Strenge Authentisierung
Session-ID	Schutz temporärer Sessions
Captcha	Schutz vor automatisierter Verarbeitung (z.B. Spam, DoS)
Kommunikationsauthentisierung	Schutz vor Identitätsdiebstahl (Spoofing, Replay-Attacken)
Kommunikationsverschlüsselung	Schutz des Datenaustausch (Sniffing, Man-in-the-Middle)
Datenverschlüsselung	Schutz vor unerlaubter Einsicht

Es ist zu sehen, dass die verschiedenen kryptologischen Mechanismen gänzlich unterschiedliche Ziele verfolgen. Einige bemühen sich um die Vertrauenswürdigkeit (Confidentiality), andere um die Wahrung der Integrität (Integrity) und wiederum andere um die Verfügbarkeit (Availability). Zusätzlich ist mancherorts die Authentizität (Authenticity) sowie die Non-Repudiation (wird an dieser Stelle ausser Acht gelassen) gegeben.

Mechanismus	Co	In	Av	Au
Benutzerauthentisierung	•			•
Passwort-Hashing	•			•
Challenge-Response-Verfahren	•			•
Session-ID	•			•
Captcha	•		•
Kommunikationsauthentisierung		•		•
Kommunikationsverschlüsselung	•	•
Datenverschlüsselung	•	•

Identifizieren der Technologien

Anhand der Erkennung der kryptografischen Methoden und der Ermittlung ihrer Aufgaben wird der Grundstein dafür gelegt, die (möglicherweise) eingesetzten Technologien zu ermitteln. Es ist zum Beispiel naheliegend, dass für den Schutz gespeicherter Passwörter ein Hash-Algorithmus verwendet wird. In Frage kommen populäre Algorithmen wie MD5 oder SHA1. In diesem Fall kann aufgrund des Einsatzgebiets die Nutzung einer symmetrischen Verschlüsselung “ausgeschlossen” werden. Symmetrische Blockverschlüsselungen wie DES/AES oder Blowfish/Twofish können in diesem Fall (vorerst) vernachlässigt werden.

Mechanismus	Technologie
Benutzerauthentisierung	Hashing, Verschlüsselung, Zertifikate
Passwort-Hashing	Hashing
Challenge-Response-Verfahren	Zufallszahlen
Session-ID	Zufallszahlen
Captchas	Zufallszahlen
Kommunikationsauthentisierung	Hashing, Verschlüsselung, Zertifikate
Kommunikationsverschlüsselung	Verschlüsselung
Datenverschlüsselung	Verschlüselung

Sodann kann versucht werden, die konkret eingesetzten Technologien als solche auszumachen. Zum Beispiel kann die Länge eines Hash-Werts Rückschlüsse auf den eingesetzten Hash-Algorithmus zulassen. Ein MD5-Hash umfasst in der hexadezimalen Schreibweise typischerweise 32 Bytes – Ein SHA-512 kommt dagegen mit 64 Bytes daher. Eine hexadezimale Zeichenkette dieser Länge lässt eben diesen Algorithmus vermuten. Es gibt verschiedene Methoden zum Fingerprinting der jeweiligen Mechanismen (werden mitunter im Entropia-Projekt erforscht), wobei sich gerade eine sichere Lösung das Erkennen aufgrund des generischen Verhaltens besonders schwierig gestaltet. Hinweise auf Technologien geben:

Einsatzgebiet (Authentisierung, Verschlüsselung, Hashing, ...)
Implementierungsbezogene Hinweise (z.B. Namen von Datenfeldern, Cookie-Namen, ...)
Ressourcen-Verbrauch (CPU, RAM, Datenspeicher)
Timing-Verhalten (Ausführungszeit)
Struktur der Ausgabe (Darstellung, Zeichensatz, Länge, Entropie)
Resultate/Verhalten bei Nutzung (z.B. Chosen-Plaintext Attacke)

Generische und bekannte Attacken auf die Technologie

Sind die verwendeten Technologien einmal identifiziert worden, kann versucht werden bekannte und generische Attacken auf diese anzuwenden. Dabei geht es jeweils darum, die definierten Ziele des Mechanismus zu verhindern. Bei einer Benutzerauthentisierung wird versucht den Zugriff trotz fehlender Authentisierungsinformationen vorzunehmen (Umgehen oder Vortäuschen einer legitimen Authentisierung) und der Angriff auf einen Passwort-Hash versucht ein legitimes Passwort zu ermitteln (Bruteforce-Attacke oder Erzwingen einer Kollision).

Gerade bei populären Technologien können zu diesem Zweck auf öffentliche Arbeiten zurückgegriffen werden. Es gibt eigentlich keinen öffentlichen Algorithmus, der nicht schon einer Kryptoanalyse unterzogen wurde. Die meisten Resultate werden in Facharbeiten, Journals, Artikeln oder Büchern publiziert.

In manchen Fällen stehen zusätzliche Software-Implementierungen bereit, um einen praktikablen Angriff vereinfachen oder automatisieren zu können. Zum Beispiel können durch Bruteforce-Tools entsprechende Attacken umgesetzt werden. Stehen keine Tools oder Exploits zur Verfügung, kann versucht werden eine eigene Implementierung für einen spezifischen Angriff voranzutreiben. Dies setzt natürlich ein hohes Mass an Verständnis für eben diesen sowie genügend Zeit zur Umsetzung einer Automatisierung voraus.

Individuelle Attacken auf die Implementierung

Weitaus interessanter als generische/bekannte Attacken auf Technologien sind individuelle Angriffe auf die konkret gegebene Implementierung. Vor allem proprietäre Mechanismen mit geschlossenem Hintergrund weisen in der Regel ein praktikables Mass an Angreifbarkeit auf (z.B. Angriff auf X-pire!).

Hierbei können klassische Angriffstechniken, die auf die jeweilige Implementierung abgestimmt werden, eingesetzt werden:

Klassische Kryptoanalyse
- Bruteforce-Angriff
- Häufigkeitsanalyse
- Kasiski-Test
- Koinzidenzindex
Symmetrische Algorithmen
- Boomerang-Angriff
- Davies’-Angriff
- Differentielle Kryptoanalyse
- Integrale Kryptoanalyse
- Lineare Kryptoanalyse
- Meet-in-the-Middle Attacke
- Mod-n Kryptoanalyse
- Related-Key Angriff
- Sandwich-Angriff
- Slide-Angriff
- XSL-Angriff
Hash-Funktionen
- Birthday-Attacke
- Preimage-Angriff
- Rainbow Table
Seitenkanalattacken
- Power Analysis
- Timing-Attacke
Netzwerkangriffe
- Man-in-the-Middle Attacke
- Replay-Angriffe

Das Umsetzen individueller Attacken auf eine spezifische Implementierung erfordert ein hohes Mass an Verständnis für die eingesetzten Technologien und die darauf anwendbaren kryptoanalytischen Mittel. Im Rahmen allgemeiner Sicherheitsüberprüfungen, bei denen kryptografische Attacken nur eine verhältnismässig kleine Rolle spielen, sind hierzu nur beschränkte mathematische Fähigkeiten erforderlich. So kann zum Beispiel eine Häufigkeitsanalyse sehr schnell und mit relativ wenig Aufwand brauchbare Resultate für eine weiterführende Kryptoanalyse liefern. Soll hingegen eine deterministische Beweisbarkeit von Angriffsszenarien dargelegt werden, muss eine solide mathematische Beweisführung miteinbezogen werden.

Im Beitrag Kryptoanalyse von Session-IDs wird am Beispiel von Session-IDs aufgezeigt, wie eine nicht-mathematische Kryptoanalyse einer individuellen Implementierung vorgenommen werden kann.

Marc Ruef | G+ (1127 Wörter)

► 02.02.2012 – Ursache und Wirkung

Im Bereich der Computersicherheit, namentlich in Bezug auf Sicherheitüberprüfungen, wird oftmals mit Terminologien gehadert. Abseits von diffusen technischen Definitionen treten aber auch in der allgemeinen Umgangssprache potentielle Missverständnisse auf. In diesem Zusammenhang soll das Fehlen einer klaren Definition der folgenden Beiden Begriffe diskutiert werden:

Ursache: Als Ursache wird ein Zustand oder eine Handlung verstanden, die zu einer Schwachstelle führen kann oder wird.

Wirkung: Als Wirkung wird ein Zustand oder eine Handlung verstanden, die durch das Ausnutzen einer Schwachstelle herbeigeführt werden kann oder wird.

Das Ausnutzen einer Schwachstelle setzt also stets eine Ursache voraus. Durch das Heranziehen einer Technik zur Ausnutzung dieser wird die gewünschte Wirkung provoziert:

Ursache ⇒ Ausnutzung ⇒ Wirkung

Als Ursache kann das Fehlen einer Eingabeüberprüfung verstanden werden. Diese kann zu einer Reihe von Angriffsmöglichkeiten führen. Beispielsweise kann eine SQL-Injection gegeben sein, deren Ausnutzung zu erweiterten Zugriffsmöglichkeiten auf der Datenbankebene führen kann:

Fehlerhafte Eingabeüberprüfung ⇒ SQL-Injection ⇒ Erweiterter Datenbankzugriff

Oftmals herrscht Verwirrung darüber, was nun eine Ursache und was eine Wirkung ist. Nachfolgende Liste versucht exemplarisch aufzuzeigen, wie die verschiedenen Fehlerquellen, Angriffstechniken und Auswirkungen kategorisiert werden können:

Informationen
⇒	Fehlerhafte Zugriffe		Sonderzeichen, nicht abgeschlossene Eingaben
	⇒	Sensitive Informationen	Benutzernamen, Passwörter, ...
	⇒	Personenbezogene Informationen	Namen, Anschrift, Mailadressen, ...
	⇒	Technische Informationen	Technische Details (z.B. interne IP-Adressen)
Eingabeüberprüfung
⇒	Pufferüberlauf		Überlange Eingaben überschreiben Speicherbereiche
	⇒	Ausführen von Programmcode	Ändern des EIP zum Laden eigenen Programmcodes
	⇒	Denial of Service	Fehlerhaftes Überschreiben von Speicherbereichen
⇒	Format String		Formatierungstoken verändern Programmverhalten
	⇒	Ausführen von Programmcode	Ändern des EIP zum Laden eigenen Programmcodes
	⇒	Denial of Service	Fehlerhaftes Überschreiben von Speicherbereichen
⇒	SQL-Injection		SQL-Statements erlauben Datenbankzugriffe
	⇒	Datenbankleserechte	Injizieren von lesenden SQL-Statements
	⇒	Datenbankschreibrechte	Injizieren von schreibenden SQL-Statements
	⇒	Ausführungsrechte	Ausführen von Programmen (z.B. `xp_cmdshell`)
	⇒	Denial of Service	Überlasten von Ressourcen, Löschen von Objekten
⇒	Script-Injection		Injizieren von Script-Anweisungen
	⇒	Leserechte	Lesezugriffe auf Webseite/Webbrowser
	⇒	Schreibrechte	Schreibzugriffe auf Webseite/Webbrowser
	⇒	Ausführungsrechte	Ausführung von Scripten auf Webseite/Webbrowser
	⇒	Denial of Service	Überlasten von Ressourcen (z.B. Loops)
⇒	Directory Traversal		Injizieren von Pfadanweisungen (z.B. `../`)
	⇒	Dateileserechte	Lesezugriffe auf geschützte Bereiche
	⇒	Dateischreibrechte	Schreibzugriffe auf geschützte Bereiche
	⇒	Dateiausführungsrechte	Ausführung von geschützten Programmen
	⇒	Denial of Service	Überlasten von Ressourcen
⇒	OS Command Injection		Injizieren von Programmanweisungen
	⇒	Systemausführungsrechte	Ausführung von geschützten Programmen
	⇒	Systemleserechte	Lesezugriffe auf geschützte Bereiche
	⇒	Systemschreibrechte	Schreibzugriffe auf geschützte Bereiche
	⇒	Denial of Service	Überlasten von Ressourcen
Verschlüsselung
⇒	Kryptoanalyse		Brechen eines kryptografischen Mechanismus
	⇒	Lesezugriffe	Einsehen geschützter Kommunikationen/Bereiche
	⇒	Manipulationen	Verändern geschützter Kommunikationen/Objekte
	⇒	Analyse	Indirektes Verständnis für Kommunikationen/Objekte
	⇒	Denial of Service	Überlasten v. Ressourcen, Löschen v. Informationen
Ressourcen
⇒	Überlastung		Ausschöpfen verfügbarer Ressourcen
	⇒	Denial of Service	Verhindern legitimer Abarbeitung/Zugriffe
	⇒	Downgrade	Schutzmechanismen (z.B. Verschlüsselung schwächen)

Die Anzahl der Unterkategorien zeigt auf, dass die meisten Sicherheitsprobleme in Applikationen auf fehlerhafte oder fehlende Eingabeüberprüfungen zurückzuführen sind. Werden solche nämlich vollumfänglich und richtig umgesetzt, dann lassen sich klassische und bisweilen verhältnismässig simple Angriffstechniken wie SQL-Injection und Cross Site Scripting nicht ohne weiteres umsetzen. Eine Einführung in die Umsetzung von effektiven Eingabeüberprüfungen sind in den folgenden drei Beiträgen bereitgestellt:

Eingabeüberpüfung? Wozu?! (Einführung)
Systematische Eingabeüberprüfungen (Grundlagen)
Eingabeüberprüfung par Excellence (Umsetzung)

Marc Ruef | G+ (649 Wörter)

► 27.01.2012 – Blog Digest Januar 2012

20 Questions to Ask Your Cloud Provider (blogs.mcafee.com)
Android Approved By Pentagon For DoD Usage, Major Setback For iPhone (muktware.com)
Breaking CAPTCHA with automated humans (Troy Hunt)
Can Simplicity Scale? (blog.regehr.org)
DLP (blogs.securiteam.com)
Five principles to better your security monitoring (darkreading.com)
Fuzzing – Mutation vs. Generation (infosecinstitute.com)
Hacking Web Authentication – Part 1 (infosecinstitute.com)
iPhone Forensics (infosecinstitute.com)
Is Your Online Bank Vulnerable To Currency Rounding… (blog.acrossecurity.com)
It’s All About Interfaces (blog.regehr.org)
It’s Official: The Windows Server GUI Is (Slowly) On the Way Out (redmondmag.com)
ModSecurity Mitigations for ASP.NET HashTable DoS Vulnerability (SpiderlabsAnterior)
New Platforms, Old Mistakes (veracode.com)
Rock Solid: Will Digital Forensics Crack SSD’s? (infosecinstitute.com)
Symantec’s Norton AntiVirus source code exposed by hackers (GrahamCluleysBlog)
Symantec tells customers to disable pcAnywhere software (reuters.com)
The Art of Reporting in IT Security (resources.infosecinstitute.com)
Three Surefire Ways To Tick Off An Auditor (darkreading.com)
Top 10 PCI Compliance Mistakes (darkreading.com)
VoIP Penetration Testing & Security Risk (resources.infosecinstitute.com)
What To Do When Your Business Partner Is Breached (darkreading.com)
When Good Apps Go Bad (darkreading.com)
Where Has All My Blogging Gone? (ThePhoneBoyBlog)
Wi-Fi Protected Setup PIN brute force vulnerability (sviehb.wordpress.com)
Windows Timestamp Tampering (blog.opensecurityresearch.com)

Marc Ruef | G+ (395 Wörter)

► 19.01.2012 – WLAN absichern: 15 Tipps

Im Zeitalter mobiler Geräte spielen drahtlose Netze eine wichtige Rolle. Das Absichern eines WLAN wird nach wie vor gerne vernachlässigt, da entweder die Risiken von Angriffen oder die Möglichkeiten der Sicherung nicht bekannt sind. In der nachfolgenden Liste sollen 15 praktikable Tipps aufgezeigt werden, wie ein WiFi-Netz möglichst sicher betrieben werden kann.

Verschlüsselung

Verschlüsselung aktivieren: Durch das Aktivieren der WLAN-Verschlüsselung wird ein virtuelles Netzwerk geschaffen, dessen Beitritt nicht mehr ohne weiteres möglich ist. Ein Nutzer muss in der Regel um das entsprechende Passwort wissen, um Teil des drahtlosen Netzes werden zu können. Auf die Nutzung des veralteten WEP sollte verzichtet und stattdessen auf WPA2 gesetzt werden.

Zusätzliche Verschlüsselung einsetzen: Als Erweiterung zur WLAN-Verschlüsselung kann eine zusätzliche Verschlüsselung für sensitive Daten eingesetzt werden. Dies kann beispielsweise ein IPsec-, SSL- oder SSH-Tunnel sein, wodurch das Abhören und Manipulieren der Kommunikation zusätzlich – und vor allem auch für die legitimen Teilnehmer des drahtlosen Netzes – erschwert wird.

Passwörter regelmässig ändern: Die für die Verschlüsselungen eingesetzten Passwörter sollten in regelmässigen Abständen geändert werden. Im privaten Bereich ist mindestens die jährliche Neuvergabe des WLAN-Passworts empfohlen. In Umgebungen mit einer höheren Anforderung an die Sicherheit kann ein manueller Wechsel alle 90 Tage angeraten sein.

Nutzung

MAC-Filter aktivieren: Viele WLAN Access Points unterstützen die Filter-Möglichkeit anhand der MAC-Adresse eines Clients. Die auf der Liste vermerkten Clients können sich sodann mit dem Access Point verbinden. Alle anderen Clients, die als fremd gelten, können gar keine Verbindung herstellen. Ein Angreifer muss zuerst mit absehbarem Aufwand die MAC-Adresse legitimer Clients herausfinden und vortäuschen, um eine erste Verbindungsaufnahme anstreben zu können.

SSID nicht nachvollziehbar auswählen: Die für den Access Point gewählte SSID sollte möglichst zufällig gewählt werden und keine offensichtliche Assoziation mit dem Besitzer bzw. Betreiber aufweisen. Durch das Anhängen der Zeichenkette _nomap wird zudem Google angewiesen, den Access Point nicht in einer allfälligen Lokalisierung zu berücksichtigen. Dadurch wird es zielgerichteten Angriffen erschwert, das richtige Netz zu finden.

SSID Broadcast deaktivieren: Auf das Broadcasting der SSID sollte zudem verzichtet werden. Zwar müssen die Clients die SSID wissen, bevor sie eine Verbindung herstellen können. Aber ebenso wird es für Angreifer erforderlich, dass sie diese zuerst herausfinden müssen. Der Aufwand für einen kurzweiligen Angriff wird damit erhöht.

Netzwerkzugriffe

DHCP deaktivieren: Nach der Verbindung mit dem Access Point sollte auf die automatische Vergabe von IP-Adressen mittels DHCP verzichtet werden. Indem mit möglichst untypischen statischen IP-Adressen gearbeitet wird (man sollte dennoch die privaten Bereiche aus RFC1918 berücksichtigen), wird eine effektive Nutzung und die automatische Identifikation von anderen Systemen (z.B. Default Gateway und Nameserver) erschwert.

Firewalling aktivieren: Viele Access Points unterstützen grundlegende Firewalling-Mechanismen, wodurch die Zugriffsmöglichkeit verbundener Clients eingeschränkt werden kann. Hier sollte eine möglichst restriktive Zugriffsmöglichkeit durchgesetzt werden, wodurch sich Missbräuche verhindern oder mindestens erschweren lassen. Zusätzlich kann ein dedizierter Proxy, der eine zusätzliche Authentisierung erfordert, zum Einsatz kommen.

Logging und Monitoring aktivieren: Sämtliche Zugriffe auf den Access Points sowie weiterführende Netzwerkkommunikationen sollten – wenigstens in ihren Grundzügen (IP-Adressen und Ports) – protokolliert werden. Ein zusätzliches Monitoring dieser Aktivitäten kann gerade in hochsicheren Umgebungen helfen, Angriffsversuche frühstmöglich erkennen und auf diese reagieren zu können.

Erreichbarkeit

Sendeleistung minimieren: Die Erreichbarkeit drahtloser Netze sollte auf ein Minimum reduziert werden. Durch das Verringern der Sendeleistung wird beispielsweise verhindert, dass der Empfang auch ausserhalb eines Gebäudes oder in anderen Stockwerken gegeben ist. Die Möglichkeit unerwünschter Zugriffe durch externe Personen – vorzugsweise im Rahmen eines Wardriving – wird damit minimiert.

Abstrahlung eindämmen: Durch ein physisches Eindämmen der Abstrahlung werden externe Zugriffe zusätzlich verhindert. Die baulichen Gegebenheiten eines Gebäudes können hier zum Vorteil genutzt werden. Durch das zusätzliche Anbringen von Dämmfolien können punktuelle Einschränkungen durchgesetzt werden (z.B. bei Holztüren).

Netzwerkelemente abschalten: Nicht benutzte Elemente sollten abgeschaltet werden. Beispielsweise können WLAN Access Points ausserhalb der Büroöffnungszeiten oder an Feiertagen vom Netz getrennt bzw. ausgeschaltet werden. Die Angriffsfläche über diese wird damit gänzlich auf Null reduziert. Manche Geräte erlauben eine Zeitsteuerung der Netzwerkfähigkeit, von der in gleicher Weise Gebrauch gemacht werden kann.

Management

Management Benutzerdaten ändern: Die für das Management des drahtlosen Netzwerks genutzten Daten sollten regelmässig geändert werden. Dadurch werden Zugriffsversuche durch Dritte verhindert. Auch hier sollten möglichst starke Passwörter, die regelmässig geändert werden, genutzt werden.

Remote Management einschränken: Die Zugriffsmöglichkeit auf das Remote Management eines drahtlosen Netzwerks sollte deaktiviert oder mindestens eingeschränkt werden. Manche Access Points lassen beispielsweise nur eine Konfiguration mittels Kabel zu oder lassen entsprechende Netzwerkzugriffe über das Internet unterbinden. Im Zweifelsfall sollte eine zusätzliche Firewalling-Komponente zum Einsatz kommen, um derlei Einschränkungen durchsetzen zu können.

Netzwerkelemente aktualisieren: Sämtliche Netzwerk- und WLAN-Komponenten sollten in den üblichen Patch-Prozess integriert werden. Auch hier müssen also regelmässig Firmware-Updates und Patches eingespielt werden, um Schwachstellen und Fehler schnellstmöglich beheben und damit das Zeitfenster für erfolgreiche Attacken minimieren zu können.

Marc Ruef | G+ (899 Wörter)

► 12.01.2012 – Windows 8 Developer Preview Sicherheit

Microsoft stellt seit einigen Wochen die Developer Preview von Windows 8 zum Download zur Verfügung. Diese Pre-Beta kann durch Entwickler genutzt werden, um sich mit den neuen Gegebenheiten der nächsten Windows-Generation auseinanderzusetzen.

Wir haben mehrere Instanzen von Windows 8 in unserem Labor eingerichtet, um mittels funktionalen und sicherheitstechnischen Tests erste Rückschlüsse auf zukünftige Entwicklungen machen zu können. Unsere Erkenntnisse sollen in diesem Beitrag zusammengefasst werden.

Installation

Die Installation war sehr effizient und einfach. In rund 20 Minuten liess sich ein System ohne grössere Komplikationen installieren. Dies war ebenfalls als virtuelle Instanz in VirtualBox möglich. Während der Installation lassen sich rudimentäre Einstellungen definieren. Zum Beispiel kann schon hier das Verhalten für das automatische Installieren von Patches bestimmt werden.

Die Standardeinstellungen entsprechen zu grossen Teilen jenen Definitionen, wie wir sie zu empfehlen pflegen. Vor allem Privatanwender werden grosse Vorteile durch die klaren Regelungen für sich gewinnen können. Unkompliziert lässt sich so ein funktionales und sicheres System aufbauen. Im professionellen Umfeld muss natürlich mit einem Mehr an Anpassungen gerechnet werden.

Login

Noch während der Installtion fragt Windows 8, ob die Installation an ein Live-Konto geknüpft werden soll. Entweder kann ein solches eingerichtet oder auf ein bestehendes zurückgegriffen werden. Die Registrierung erfolgt per Benutzername und Passwort. Dabei wird ein Email an das verknüpfte Mailkonto geschickt, in dem ein Aktivierungslink enthalten ist. Dadurch kann die Legitimität der Installation und des daran gebundenen Kontos bestätigt werden.

Das Einloggen mit dem Live-Konto ist interessant, da sich damit cloudähnliche Mechanismen realisieren lassen. Microsoft ist darum bemüht, dass Einstellungen systemübergreifend definiert und durch den entsprechenden Login synchronisiert werden können. Ein ähnliches Verhalten wird durch Mozilla Firefox mit den Sync-Optionen realisiert.

Neue Oberfläche

Das Credo beim grafischen Design von Windows 8 ist Simplizität. So kommen viele grafische Elemente mit sehr einfachen, oftmals rechteckigen Strukturen daher. Die neue Oberfläche namens Metro scheint dabei in erster Linie auf Tablets ausgerichtet zu sein. Relativ grosse Icons zeigen die einzelnen Anwendungen an, die durch einen Klick gestartet werden können. Diesen Stil hat Microsoft schon mit Windows Phone 7 auf ihren Mobiltelefonen eingeführt und bei der Xbox360 weitergenutzt.

Windows 8 Beta neue Metro-Oberfläche

Traditionelles System

Durch das Klicken auf das Icon Windows Explorer kann die klassische grafische Oberfläche geladen werden. Hier wird bestens bekannt die Taskleiste am unteren Rand des Bildschirms eingeblendet. Durch das Klicken auf den Windows-Button wird jedoch nicht mehr das Start-Menu geöffnet, sondern stattdessen wieder zum neuen GUI gewechselt. Programme, Dokumente und Einstellungen müssen neu aus dem Explorer heraus gestartet werden.

Einzig in einigen Bereichen haben Fenster ein kleines Redesign erhalten. So werden nun grössere Icons, wie man sie schon von Office 2010 her kennt, eingesetzt. Dies macht die Fenster auf den ersten Blick attraktiver und soll in erster Linie die MacOS X-Klientel ansprechen.

Durch Start/Ausführen können wie üblich Programme direkt angesteuert werden. Nach wie vor lässt sich damit die MS DOS-Eingabeaufforderung durch die Eingabe von cmd.exe starten. Sie begrüsst den Benutzer vorerst mit der Version 6.2.8102.

Windows 8 Beta alte Oberfläche

App Store

Ein bisschen abgeschaut von Apple, ist im Betriebssystem ein Store für den Download von Apps vorgesehen. In der ersten offiziellen Preview war dort lediglich ein Hinweis eingebracht, dass diese Funktion noch nicht freigegeben ist. Inwiefern sie sich verhalten wird, wird sich also zeigen.

Microsoft geht damit den Weg eines Walled Garden, der sicherheitstechnisch Vorteile mit sich bringen wird. Dadurch wird es möglich, Software auf Qualität und Sicherheit hin zu untersuchen, bevor eine offizielle Freigabe erteilt wird. Unsichere Produkte und Malware liessen sich so verhindern.

Dadurch fällt jedoch auf Seiten Microsoft ein Mehr an Aufwand an, was wiederum die Veröffentlichung von neuen und aktualisierten Produkten verzögert. Sicherheit wird diesem Fall zu Lasten von Offenheit und Flexibilität eingetauscht.

Internet Explorer

Als Standardbrowser kommt noch immer Microsoft Internet Explorer zum Tragen. Dieser hat in der Metro-Darstellung ein grundlegendes Re-Design erfahren und versucht sich an der Simplizität von Google Chrome anzuknüpfen. Die Menu-Elemente sind auf ein Minimum reduziert und so wird nur noch eine Adressleiste und Buttons für die wichtigsten Aktionen (z.B. zurück, neu laden) angezeigt. Während des Browsens werden gar auch diese Komponenten ausgeblendet, wodurch die Webseite in maximaler Grösse – schon fast Vollbild – dargestellt werden kann. Wem das nicht gefällt, der kann mit einem Mausklick in die klassische Ansicht wechseln.

Windows 8 Internet Explorer

Leider kann man in der Preview das About des Browsers und damit die Version nicht ohne weiteres darstellen lassen. Als User-Agent gibt sich der neue Browser als Internet Explorer 10 aus. Ob es sich hierbei wirklich um die nächste Browser-Generation handelt, ist nicht sicher.

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

Die Einstellungsmöglichkeiten und das Verhalten bleiben damit eigentlich die gleichen, wie bei Internet Explorer 8 und 9. Hardening-Mechanismen, die schon bei Windows 7 zum Tragen gekommen sind, können entsprechend auch hier appliziert werden.

Sicherheitseinstellungen

Das Control Panel auf Metro kommt einmal mehr mit einer starken Vereinfachung daher. So werden nur die wichtigsten Einstellungsmöglichkeiten dargestellt, die sich jeweils mit einem Regler aktivieren oder deaktivieren lassen. Erst wenn auf More settings geklickt wird, wird die Systemsteuerung im klassischen Stil angezeigt. Sowohl die Darstellung als auch die Einstellungsmöglichkeiten orientieren sich an jenen von Windows 7.

Windows 8 Control Panel

Der detaillierte Vergleich der Auslieferung von Windows 7 und Windows 8 – in Bezug auf NTFS-Rechte und Registry-Einstellungen – fällt nahezu identisch aus. Nur in einigen wenigen Punkten sind Abweichungen festzustellen, die in vielen Fällen aber sowieso den individuellen Bedürfnissen der Umgebung angepasst werden müssen.

Fazit

Auf den ersten Blick wirkt Windows 8 wie eine komplett neue Windows-Generation. Dafür verantwortlich ist in erster Linie die Metro-Oberfläche. Lässt man die für mobile Geräte entwickelte Oberfläche aber ausser Acht und arbeitet mit dem klassischen Desktop, dann findet man sich in einer zu Windows 7 sehr ähnlichen Umgebung wieder.

Das Ziel von Windows 8 war sicherlich, die Einfachheit und Effizienz zu erhöhen, um mit iOS von Apple mithalten zu können. Ob dies gelungen ist, kann erst mit dem Einsatz auf entsprechenden Tablets bestätigt werden. Der erste Eindruck, wie zum Beispiel das Aufstarten des Systems, zeigen spürbare positive Verbesserungen.

Die ersten Sicherheitsmechanismen von Windows 8 sind aus Windows 7 übernommen und haben sich in den letzten Jahren bewahrheitet. Die Standardeinstellungen, die schon bei der Installation der neuen Windows-Generation angepasst werden können, versuchen eine Ausgewogenheit zwischen Sicherheit und Praktikabilität zu erreichen. Vor allem Privatanwender werden daraus einen Nutzen ziehen können. In professionellen Umgebungen, in denen zusätzliche Anforderungen an die Sicherheit gestellt werden, müssen zusätzliche Anpassungen angegangen werden.

Marc Ruef | G+ (1174 Wörter)

► 05.01.2012 – Cross-Site-Scripting und Script Injection verhindern: Ein kurzer Leitfaden

XSS und Script Injection Schwachstellen gehören nach wie vor zu den verbreitesten Problemen in Webapplikation bis dato. Diese zu mitigieren wird oft als trivial verstanden, aber ebenso oft erfolgen Gegenmassnahmen nur teilweise korrekt, was in einem nicht zu vernachlässigenden Restrisiko resultieren kann. Es ist nicht ausreichend, ausschliesslich spezifische Zeichen zu enkodieren (z.B. wie htmlentities) oder gewisse Zeichen komplett zu filtern. Die nachfolenden Punkte zeigen auf, welche Schritte berücksichtigt werden sollten, um eine korrekte, funktionale Eingabevalidierung zu implementieren. Diese Empfehlungen sind als Grundlage zu verstehen, um individuelle, auf die jeweilige Applikation zugeschnittene Massnahmen definieren und umsetzen zu können.

In Content-Elementen (div und body)

<div>Ihre Eingabe lautet: USER DATA</div>

Es muss sichergestellt werden, dass signifikante Zeichen als HTML Entitäten enkodiert werden, damit der Benutzer keine Daten ausserhalb des Datenkontextes injizieren kann. Die signifikanten Zeichen lauten:

Bezeichnung	Darstellung	HTML-Entity
Grösser-als-Zeichen	<	`<`
Kleiner-als-Zeichen	>	`>`
doppeltes Anführungszeichen	“	`"`
einfaches Anführungszeichen	‘	`'`
Kaufmännisches Und	&	`&`
Schrägstrich	/	`/`

Hinweise und Erläuterungen:

Der Forward Slash (/) wird in Closing Tags genutzt, weshalb es Sinn macht und gemeinhin als gute Praxis betrachtet wird, ihn ebenfalls zu enkodieren.
Das einfache Anführungszeichen (') wird oft mit der Named Character Reference ' enkodiert. Dies ist inkorrekt: ' wird zwar in XML 1.0 definiert, ist aber kein gültiges HTML Symbol. Zwar sind die meisten Browser in der Lage, damit problemlos umzugehen, der korrekte Weg ist aber der oben illustrierte mittels '

In regulären HTML-Atributen

Die nachfolgende Regel gilt nicht für komplexe Attribute wie JavaScript Event Handler (z.B. onmouseover) oder Style-Attribute. Siehe dafür den nachfolgenden Abschnitt.

<input value="USERDATA" />
<input value='USERDATA' />
<input value=USERDATA />

Wie aus dem Beispiel ersichtlich wird, existieren hier mehrere mögliche Fälle. Oft werden, obwohl dies inkorrekt ist, Attribute ohne Anführungszeichen verwendet. Speziell in diesem Fall könnte ein Angreifer sehr einfach aus dem Kontext des Attributes ausbrechen.

Aus diesem Grund sollten hier alle Zeichen, die nicht alphanumerisch sind und einen ASCII-Wert unter 256 haben im Format &#xHH; encodiert werden. Der Grund liegt hier im vorgängig beschriebenen Umstand, dass oftmals Attribute ohen Anführungszeichen verwendet werden, aus denen mit verschiedensten Zeichen (inklusive einem simplen Leerzeichen) ausgebrochen werden kann. Werden Attribute korrekt von Anführungszeichen eingeschlossen, so kann nur mit einem korrespondierenden Anführungszeichen daraus ausgebrochen werden. Trotzdem empfiehlt es sich hier, auf Nummer sicher zu gehen.

In Javascript-Funktionen oder CSS-Definitionen

<script>alert('USERDATA');</script>

Das Verwenden unvertrauenswürdiger Daten innerhalb von Javascript-Blöcken ist enorm gefährlich und sollte mit höchster Vorsicht vorgenommen werden. Werden Werte explizit als Daten innerhalb eines Skripts benötigt, so sollten wiederum alle Zeichen, die nicht alphanumerisch sind und einen ASCII-Wert unter 256 haben im Format &#xHH; enkodiert werden. Allgemein sollte diese Praxis aber, wann immer möglich, vermieden werden.

Die goldene Regel

Die Versuchung für viele Entwickler ist gross, einen einfacheren Weg zu wählen und ein simples HTML Encoding anzustreben. Während jede Massnahme besser ist, als gar keine Massnahmen, so ist dies leider kein gangbarer Weg. Die obenstehenden Empfehlungen geben wertvolle Grundlagen, grundsätzlich sollte aber die Prämisse lauten:

Unvertrauenswürdige Daten sollten nie an Orten platziert werden, die nicht explizit dafür vorgesehen und mit entsprechenden Massnahmen geschützt sind.

So ist es problemlos möglich, die Verwendung von Daten innerhalb eines div-Tags akkurat zu schützen. Es ist aber vergleichsweise schwierig, das selbe innerhalb eines script-Tags zu erreichen.

Jeder Kontext, in dem derartige Daten genutzt werden sollen, muss sorgfältig geprüft werden. Niemals aber sollten unvertrauenswürdige Daten in folgenden Kontexten eingesetzt werden:

in einem HTML Kommentar
in einem Attributs-Namen
in einem Tag-Namen
direkt in einem Script

Die obenstehenden Empfehlungen decken sich weitgehend mit den Empfehlungen des OWASP Projektes und dienen der scip AG als offizielle Empfehlung.

Stefan Friedli | G+ (658 Wörter)

Labs Übersicht