Die BSI-Schwachstellenampel für Mängel in Softwareprodukten

Verbraucherschützer fordern sie schon länger: Die Ampel aus deren Rot-Gelb-Grün-Schema man leicht nachvollziehen kann, wie es um die Inhaltsstoffe von Lebensmitteln, das Hygieneverständnis von Gastronomen usw. bestellt ist. Und Wirtschaftslobbyisten arbeiteten in der Vergangenheit ebenso vehement wie erfolgreich dagegen an. Die Ampel sei zu einfach, zu grob und überhaupt schade zu viel Transparenz dem Geschäft und würde Verbraucher nur verunsichern.

Währenddessen hat kürzlich das Bundesamt für Sicherheit in der Informationstechnik (BSI) ein solches Ampelsystem zur Bewertung von Schwachstellen in verbreiteten Softwareprodukten veröffentlicht. Im Rahmen der sog. „BSI-Analysen zur Cyber-Sicherheit“ soll dieser Ampel-Indikator einen raschen Überblick über Sicherheit und Qualität der so gerateten Softwareprodukte geben. Derzeit werden für die Schwachstellenampel Sicherheitslücken in Produkten dieser Hersteller berücksichtigt:

•    Adobe Systems (Adobe Reader, Adobe Acrobat und Adobe Flash Player)
•    Apple Inc. (OS X, Safari und Quicktime)
•    Google Inc. (Google Chrome)
•    der Linux-Kernel
•    Microsoft Corporation (Windows, Office und Internet Explorer)
•    Mozilla Foundation (Firefox und Thunderbird)
•    Oracle Corporation (Java Development Kit (JDK) und Java Runtime Environment (JRE))

Das BSI ist der wohl zutreffenden Ansicht, dass Mängel in diesen Produkten aufgrund deren weiten Verbreitung in Unternehmen, Behörden sowie bei Privatanwendern potenziell schwerwiegende und flächendeckende IT-Sicherheitsvorfälle nach sich ziehen können. Die Behörde verfolgt daher u.a. auch den Lebenszyklus von Schwachstellen von der Entdeckung bis zur Beseitigung mit.

Daher bewertet es im Rahmen einer regelmäßig aktualisierten Schwachstellenampel offene Schwachstellen sowie deren Schweregrad auf einer 10er-Skala und visualisiert das entsprechend. Die Schwachstellenampel wird vom BSI regelmäßig aktualisiert. Die Termine der Aktualisierungen orientieren sich dabei hauptsächlich an den Patchdays und Aktualisierungszyklen der Anbieter. Zusätzlich werden Links auf weiterführende Sicherheitshinweise der Hersteller angeboten.

In dieser Form bietet die BSI-Schwachstellenampel einen guten ersten Überblick zur Sicherheits- und Qualitätslage von verbreiteter Standardsoftware. Wobei auffällt, wie gut vor allem quelloffene Open-Source-Produkte wie der Linux-Kernel oder Firefox und Thunderbird abschneiden. In jedem Fall kann so Druck auf die Hersteller entstehen, verstärkt auf die Sicherheit und die generelle Qualität ihrer Softwareprodukte zu achten.

Wenn Programmierer sich zum Affen machen

„Easter Eggs“ sind kleine Überraschungen, die Programmierer in den Code ihrer Programme einbauen. Oftmals schwer zugänglich, z.B. durch exotische Tastenkombinationen, die nur in bestimmten Situationen funktionieren, erzeugen sie oft unerwartete und meistens witzige Effekte. So enthielt Microsofts weit verbreitete Tabellenkalkulation Excel lange Zeit einen kleinen Flugsimulator. Diese „Ostereier“ im Programmcode stellen aber auch ein Sicherheitsrisiko dar, da sie ja versteckt und an jeder Form von Qualitätskontrolle durch Testen, Reviews usw. vorbei implementiert wurden.

Wer daher nach potentiellen Schwachstellen in Programmen sucht, hält meist auch nach solchen Ostereiern Ausschau. Das taten wohl auch die Stuxnet-Entwickler sowie andere, an den programmtechnischen Innereien von Prozessrechnern aus dem Hause Siemens interessierte Leute. Die Siemens-Geräte rückten ins Blickfeld, nachdem bekannt wurde, dass man über Manipulationen dieser i.d.R. eher schlecht gesicherten Rechner teure Technik in Kraftwerken oder Produktionsanlagen über gezielte Veränderung der zulässigen Betriebsparameter angreifen kann.

So stellten experimentierfreudige Hacker auf der letzten Black-Hat-Konferenz in Las Vegas ihre Erkenntnisse beim Hacken von Industriesteuerungsanlagen von Siemens vor. In Geräten der Serie Simatic S7-300 fanden sie sogar hartcodierte Nutzer und Passwörter. „Ich konnte mich per telnet und http einloggen, den Speicher auslesen, Dateien löschen und Befehle geben“, so Dillon Beresford, der dieses Sicherheitsleck entdeckte.

Wie viele der Anlagen von Sicherheitsproblemen betroffen sind, ist kaum abzuschätzen. Die Simatic-Anlagen gelten weltweit als Standard für die Steuerung industrieller Prozesse aller Art. Neben den fest vergebenen Passwörtern hat Beresford allerdings noch ein Dutzend weiterer Sicherheitslücken in den Siemens-Kontrollanlagen entdeckt. Er konnte zeigen, wie sich die Systeme so manipulieren lassen, dass sie falsche Kommandos ausführen oder verfälschte Daten an ihre Leitstellen schicken.

Aus Sicht von Siemens wären nur bestimmte, ältere Geräte mit einer nicht mehr aktuellen Firmware betroffen. Allerdings werden solche Prozesssteuerungsanlagen nicht wie PCs in kurzen Abständen gepatcht, wenn ein Leck auftaucht. Stattdessen werden an die Software generell höhere Ansprüche hinsichtlich Qualitätseigenschaften gestellt. Ansonsten wäre ihr Betrieb im hochregulierten Industrieumfeld auch gar nicht genehmigungsfähig.

Neben den Sicherheitslücken fand Beresford allerdings noch ein klassisches „Easter Egg“ in der Siemens-Software. Programmierer hatten darin eine rote Website untergebracht, auf der Zeichnungen von spielenden Affen zu sehen sind und der Satz „Nix hören, nix arbeite, einfach nur…“. Ein Zeichen davon, was sie von der Siemens-Kultur in dem von Shareholder-Value und managerialer Übersteuerung geprägten Konzern hielten?

Ob sich dieser Programmierscherz aufgrund darin enthaltener Schwachstellen dazu benutzen lässt, um Schadcode in die Maschinen einzuschmuggeln, ist noch unklar. Das Siemens-Management allerdings habe sehr aufgeregt reagiert, als Beresford dem Unternehmen von seinem kuriosen Fund berichtete, wie er in einem Wired-Interview erklärte: „Sie waren nicht gerade glücklich.“

Buchrezension: Web-Sicherheit – Wie Sie Ihre Anwendungen sicher vor Angriffen schützen

Dieses von Sebastian Kübeck verfasste Buch aus dem mitp-Verlag befasst sich mit den Methoden sicherer Softwareentwicklung speziell für webbasierte Anwendungen. Die zugrunde liegenden Überlegungen  sind aber größtenteils auch auf andere Bereiche der Softwareentwicklung übertragbar. Das Buch richtet sich an Softwareentwickler, die sich noch nicht intensiver mit Informationssicherheit und dem Schreiben sicheren Codes befasst haben. Und die somit einen Einstieg in die Themen Informationssicherheit sowie Methoden sicherer Webentwicklung suchen. Aber auch Administratoren webbasierter Systeme können davon profitieren.

Das Buchh ist in drei Teile gegliedert. Im ersten Teil werden nach einer kurzen Einführung in die Geschichte der Informationssicherheit Grundkonzepte der IT-Sicherheit speziell aus der Sicht des Softwareentwicklers erläutert. Dazu zählen Dinge wie die Prinzipien sicherer Softwareentwicklung, Authentisierungsverfahren oder sichere Datenübermittlung durch den Einsatz kryptografischer Verfahren.

Teil zwei befasst sich mit häufig auftretenden Schwachstellen in Softwareprodukten sowie Wegen zu deren Vermeidung. Dazu zählen Filterung und Aufbereitung nahezu jeder Form von Eingabe durch Anwender, um z.B. Code-Injection- und Scripting-Angriffen vorzubeugen. Oder die Vermeidung von Webserver-Konfigurationen durch die Teile der Systemkonfiguration per Suchmaschine erfassbar (Google Hacking) oder durch manuelles Suchen (Path Traversal) erreichbar werden.

Oftmals beginnen Probleme mit der Applikationssicherheit jedoch bereits bei der Verwendung von altbewährten und weit verbreiteten Bibliotheksfunktionen gerade der C-Sprachen, welche direkte Speicherzugriffe ermöglichen und die aufgrund von Implementationsfehlern zu Sicherheitsproblemen wie Pufferüberläufen, Code Injection-Schwachstellen u.ä. führen und daher nicht mehr verwendet werden sollten.

Webanwendungen können auch anfällig für DDOS-Attacken werden, wenn sich in ihnen Code aufspüren lässt, der zu Speicherlecks, Endlosschleifen, Rekursionen mit fehlerhafter Abbruchbedingung führt oder der Wartezeiten auf (schwächere) nachgelagerte Systeme wie z.B. entfernte Datenbanken generiert.

Schließlich gibt Teil drei konkrete Tipps und Hinweise wie man durch qualitätssichernde Maßnahmen wie Pen-Tests, Code Reviews, Softwaretests sowie der Berücksichtigung von Prinzipien sicherer Entwicklung von Webapplikationen seine Software sicherer macht. Hier wird z.B. auch auf (meist quelloffene) Testing-Tools wie Schwachstellen-Scanner, Mustersucher für die Quellcodeanalyse oder Tools zur Testautomation eingegangen.

Stets werden die Erläuterungen im Buch von entsprechenden Codebeispielen (meist in Java oder Javascript sowie in SQL für Datenbankzugriffe) begleitet, in denen die problematischen Stellen nachvollziehbar erläutert werden.

Alles in allem ein  sehr lesenswertes Buch speziell für Softwareentwickler aber auch für generell am Thema sicherer Software interessierter IT-Fachleute. Wobei das Thema Entwicklung sicherer webbasierter Anwendungen gerade im Zeitalter von Cloud Computing und mobiler Apps drastisch an Bedeutung gewinnen dürfte.

Alles beginnt mit den Anforderungen

So könnte man den Gang der Dinge bei der Softwareentwicklung, eigentlich aber bei fast jedem ingenieurshaft angegangenen Entwicklungsprojekt beschreiben. Daher gewinnt das Anforderungsmanagement im Systementwicklungsprozess auch laufend an Bedeutung. Denn der 10er-Regel der Fehlerkosten folgend, verzehnfachen sich die Kosten der Behebung von Fehlern mit jeder weiteren Projektphase in etwa. D.h. möglichst viele Fehler gleich zu Beginn des Projekts durch systematisches Vorgehen zu vermeiden, kann immense Summen Geld einsparen (oder im Falle des Unterlassens verschlingen).

Das macht das Anforderungsmanagement zu einer wichtigen Disziplin für all jene, die sich mit Aspekten der Informationssicherheit oder der Qualität von Softwareprodukten befassen. Anforderungen sind die Grundlage für alle Eigenschaften des späteren Produkts (zumindest sollten sie es sein). Anforderungen können Gegenstand späterer Prüfungen des Produktes sein und bilden die Grundlage für das Testmanagement zur Erstellung und Auswahl von Teststrategien und Testfällen. Im Bereich der Produktdokumentation bilden die Anforderungen den Kern des später zu Dokumentierenden und sind Basis für Anwenderschulungen. Auch die spätere Wartung und Weiterentwicklung des laufenden IT-Systems ist auf gut dokumentierte Anforderungen angewiesen.

Daher kann man sich bereits seit geraumer Zeit im Bereich des Anforderungsmanagements nicht nur fortbilden sondern auch ein Fachzertifikat, den „Certified Professional for Requirements Engineering (CPRE)“ mit Prüfung und Siegel erwerben, das auf einem Lehrplan basiert, der vom International Requirements Engineering Board (IREB) e.V. entwickelt wurde. Einem Verband, der sich mit der Kodifizierung von etablierten „best practices“ in diesem Teilbereich der Softwareentwicklung beschäftigt.

Zu den „Klassikern“ der Probleme beim Umgang mit Anforderungen zählen ungenaue, unvollständige, in sich widersprüchliche oder auch gar nicht vorhandene Anforderungen. Beispielsweise weil bei der Produktplanung wichtige Beteiligte übergangen wurden. Weil Dinge als selbstverständlich vorausgesetzt und daher nicht weiter erwähnt wurden. Weil das mit dem Produkt zu lösende Problem nicht wirklich verstanden wurde. Oder weil man es mal wieder zu eilig hatte – „husch husch – time to market – profit profit“ – und daher zu wenig in die konzeptionellen Vorarbeiten der Produktentwicklung investiert hatte. Daher gibt es auch regelmäßig Studien (wie z.B. den sog. „Chaos Report“ der Standish Group), die sich mit den Erfolgs- und Misserfolgsfaktoren in IT-Projekten beschäftigen und dabei regelmäßig die Bedeutung guten Anforderungsmanagements und guten Projektmanagements unterstreichen.

Grundsätzlich hat ein Anforderungsmanager vier Aufgaben, denen er sich zu widmen hat. Er soll Anforderungen erheben, dokumentieren, sie prüfen und mit den Beteiligten abstimmen sowie sinnvoll verwalten und verfügbar machen. Dort wo es die Rolle des Anforderungsmanagers nicht in Reinform gibt, fallen diese Aufgaben den Entwicklern, IT-Architekten, Projektleitern, Produktverantwortlichen etc. zu, was häufig nicht unbedingt zu ihrer vollständigen und zufriedenstellenden Erledigung beiträgt. Zumal ein Anforderungsmanager eigentlich weniger ein technischer Spezialist als ein Experte im Gebiet der Schlüsselqualifikationen und der Methodenkompetenz ist. Denn ihm fallen die „menschlichen Aspekte“ der Produktplanung zu: Er soll die Beteiligten des Vorhabens ausfindig machen, mit ihnen reden und sich so ein Gesamtbild des zu entwickelnden Softwareproduktes verschaffen. Und es so aufbereiten, dass die Entwickler darauf basierend etwas Brauchbares entwickeln können.

Anforderungsmanagern fällt somit die „Verwaltungswirtschaft“ der Softwareentwicklung zu, da ein Großteil ihrer Arbeit aus dem bereits erwähnten Erheben, Dokumentieren, Prüfen und Abstimmen sowie dem Verwalten der Anforderungen, mithin also aus dokumenten- und personenorientierter Arbeit besteht.

Dort wo Softwareentwicklung aber vom „Handwerk“ zur Ingenieurstätigkeit werden soll, also einem Industrialisierungsprozess unterliegt, kommt man um das Anforderungsmanagement ebenso wenig herum wie um das Plänezeichnen und Prototypenbauen im Automobilbau.

Zumal vollständige, konsistente und genau spezifizierte Anforderungen wie bereits erwähnte die Grundlage für testbare Produkte und prüfbare Prozesse zu deren Entwicklung bilden – somit also die Basis der Qualitätssicherung bilden. Zumal so aus Anforderungen auf dem Papier ausführbarer Testfallcode oder die Grundlage einer sicherheitstechnischen Bewertung des fertigen Softwareproduktes werden kann.

Do wo genau findet das Anforderungsmanagement denn statt?

Bei „klassischen“ Vorgehensmodellen der Softwareentwicklung wie z.B. dem V-Modell XT ist das Anforderungsmanagement eine klar definierte Phase, die der Entwicklung vorangeht und die Basis des zu entwickelnden Systems bildet. Zu einem bestimmten, vorab festgelegten Zeitpunkt wird der Stand der Anforderungen „eingefroren“ und bildet die Ausgangsbasis der weiteren Entwicklungsphasen. Später noch hinzukommende Änderungswünsche werden als genau das behandelt: Änderungswünsche, welche zu nachträglichen Änderungen der Planung und Kostenkalkulation führen können.

Im Gegensatz dazu ist das Anforderungsmanagement bei „agilen“ Vorgehensmodellen wie SCRUM ein Begleitprozess der Entwicklung und es werden nur jeweils die erforderlichen Anforderungen für den nächsten Teilabschnitt in der Entwicklung durch iteratives Vorgehen, inkrementelle Fortschreibung und Präzisierung abschlussfertig ausgearbeitet und umgesetzt.

Doch das Anforderungsmanagement trägt auch auf weitere Weise zu einer besseren Softwarequalität bei. So gilt es z.B. auch die Anforderungen an sich hinsichtlich Inhalt, Abgestimmtheit und Dokumentation qualitätszusichern und dabei Methoden des Qualitätsmanagements wie Beteiligung der Betroffenen, Mehraugenprinzip, Trennung von Fehlersuche und Fehlerkorrektur oder auch Prüfung aus unterschiedlichen Perspektiven anzuwenden. Nicht nur Code sondern bereits die dokumentierten Anforderungen an das spätere System lassen sich durch formale Methoden wie Audits, Inspektionen, Walkthroughs oder Reviews prüfen.

Doch woher kann man als im Bereich IT-Sicherheit und / oder Softwarequalität Tätiger das Know-how zu diesem breiten Thema nehmen? Beginnen kann man mit einschlägiger Fachliteratur, für ein tieferes Eindringen in das Thema Anforderungsmanagement kann ein entsprechendes Seminar oder eine Zertifizierung wie das bereits erwähnte IREB-Zertifikat sinnvoll sein. Letztlich entscheidend dürften dann aber die Erfahrungen der gelebten Projektpraxis „im Feldeinsatz“ werden.

Wie man unsichere Software entwickelt

Generelle Sicherheitseigenschaften von guter Software wie die Wahrung von Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität der Daten und Dienste sind auch Qualitätseigenschaften und damit Gegenstand von Überlegungen zum Thema Softwarequalität. Während man sich üblicherweise fragt, was man tun kann, um in diesen Eigenschaften bessere Software zu entwickeln, geht Markus Wutzke, Security Consultant bei Secaron AG, den umgekehrten Weg. Er kündigte für das Softwareforum Leipzig am 29./30. November den Workshop „Sicherheit und Datenschutz in der Entwicklung von Geschäftsanwendungen“ an, in dem er darstellen will, was man alles tun sollte, um seine Software möglichst gut bestückt mit Sicherheitslücken und Schwachstellen auszuliefern.

Wutzke sieht dafür im Wesentlichen sieben Schritte als erforderlich an und empfiehlt für den geplanten Software-GAU provokativ folgende Fehlentscheidungen auf Management-Ebene:

•    Planen Sie kein Budget für Sicherheitseigenschaften ein.
•    Verankern Sie keine Sicherheitsaktivitäten in Ihrem Entwicklungsprozess.
•    Ermitteln Sie nur funktionale Anforderungen aber keine Sicherheitsanforderungen.
•    Schulen Sie ihre Entwickler nicht in Sicherheitsthemen.
•    Erfinden Sie stets das Rad neu.
•    Vermeiden Sie Security-Tests.
•    Installieren Sie die Software auf einer Standardbetriebsumgebung.

Mehr als 2/3 aller Probleme in der IT-Sicherheit sind softwarebezogen. Jedoch wird Sicherheit oftmals erst als Reaktion auf eine Bedrohung oder nach einem Angriff als wichtiges Qualitätsmerkmal eines Softwareprodukts erkannt. Sie bedarf jedoch der kontinuierlichen Integration in den Entwicklungsprozess, wie es z.B. Initiativen wie das Clean Code Development (CCD) oder Microsofts Security Development Lifecycle (SDL) vorsehen.

Letztlich bildet sichere Softwareentwicklung auch eine Schnittmenge aus Ansätzen der Informationssicherheit und der Softwarequalität.

Wenn Hacker gehackt werden – wie sicher sind Hackertools?

Zu den prägendsten (und oft auch letzten) Kriegserfahrungen mancher Soldaten zählen Fehlfunktionen ihrer Waffen. Der sprichwörtlich „nach hinten losgehende“ Kanonenschuss, die in der Hand explodierende Wurfgranate, das einen Looping drehende und dann zurückkommende Lenkwaffengeschoss.

Das scheint in der Welt der Cyber-Söldner nicht anders zu sein. Dort ist es üblich, beim Angriff auf IT-Systeme auf selbstgebaute Hackertools zurückzugreifen. Diese werden oft „quick & dirty“ für das gebaut, was sie machen sollen. Ohne große Qualitätssicherung, ohne Test, mit oftmals nur wenig peer-review durch Dritte.

Und das macht Hacker selbst angreifbar, wie kürzlich die BBC berichtete. Im Kampf gegen Internetkriminalität haben Sicherheitsexperten von TEHTRI-Security häufig verwendete Tools der Hacker untersucht und dabei zahlreiche Sicherheitslücken entdeckt. Die Programme, die dabei verwendet werden, wären in vielen Fällen leicht zu knacken, so das Fazit der Experten nach eingehender Analyse der Programme. Das gilt insbesondere für Hackertools die im Internet frei verbreitet, aber kaum weiterentwickelt werden. Denn bei ihnen greift das qualitätssichernde Element einer breiten Fachöffentlichkeit und des Zugangs vieler Experten zum Quellcode nicht.

Viele der Lücken sind dabei offenbar so leicht zu finden, dass sie ohne Weiteres für Gegenangriffe und „proaktive Abwehr“ ausgenutzt werden können. Mit diesen Erkenntnissen ging der Sicherheitsexperte Laurent Oudot bereits im Rahmen der SyScan 2010 Security Conference in Singapur an die Öffentlichkeit und nannte dabei dreizehn Sicherheitslücken, die er in einigen der populärsten Hackertools entdeckt hatte.

In vielen Fällen würde das Ausnutzen solcher Exploits es Sicherheitsexperten ermöglichen, ihre Gegner zu identifizieren und bis zu deren Rechnern zurück zu verfolgen, Informationen über sie und ihre Methoden zu sammeln, zum aktiven Gegenangriff überzugehen und sogar Vergeltungsschläge gegen Cyber-Kriminelle zu führen. Auch wenn das in den wenigsten Fällen legal sein dürfte, gilt auch hier das „elfte Gebot“ (du sollst dich nicht erwischen lassen).

Und so wies auch Oudot in seinem Konferenzbetrag darauf hin, dass dieses Vorgehen vor allem rechtlich problematisch sein könnte. Die praktische Anwendung stünde momentan auch nicht im Vordergrund. Die Ergebnisse der Untersuchung sollten dazu dienen, im Bereich der Internet-Sicherheit neue Möglichkeiten anzudenken.

Auch Skript-Kiddies, die sich schon als „großer Hacker“ fühlen, nachdem sie es erfolgreich geschafft haben, ein einschlägiges Programm aus dem Internet herunterzuladen und auf ihrem Rechner zu starten, sollten sich daher künftig besser überlegen was sie tun. Schließlich fehlt es ihnen meist an den Kenntnissen, um die tatsächliche Qualität und Wirkung des Programms beurteilen zu können.

Die 10 gefährlichsten Schwachstellen in Webanwendungen

Die Experten des Open Web Application Security Project (OWASP), einer Community die sich mit den Aspekten sicherer Programmierung in Webanwendungen beschäftigt, haben kürzlich ihre alle drei Jahre neu erstellte Top-10-Liste gefährlicher Schwachstellen und qualitativer Mängel in Webapplikationen neu veröffentlicht. Grundlage der Klassifizierung der darin enthaltenen Probleme sind Risikobewertungen, die die OWASP-Experten mittels einer eigenen OWASP Risk Ratig Methodology bewertet haben. Genauere Erläuterungen dieser Schwachstellenklassen sowie Hinweise zu ihrer Eindämmung geben sie in einer 22-seitigen Broschüre „OWASP Top 10 – 2010 The Ten Most Critical Web Application Security Risks“, die man als PDF (2,5 MB) herunterladen kann.

Die Broschüre enthält eine übersichtliche Darstellung der zehn Problemklassen und stellt Bezüge zu weiteren frei verfügbaren Referenzen her, so z.B. zu den OWASP-Projekten Enterprise Security API (ESAPI) und Application Security Verfication Standard (ASVS). Gegenstand dieser Projekte ist die Entwicklung prüf- und testbarer Standards zur Implementierung von Sicherheitsfunktionen in Webanwendungen.

Bei den zehn Risiken für Webentwickler, die laut OWASP 2010 am ehesten ernst zu nehmen sind, handelt es sich um:

•    Code Injection
•    Cross-Site Scripting (XSS)
•    Broken Authentication and Session Management
•    Insecure Direct Object References
•    Cross-Site Request Forgery (CSRF)
•    Security Misconfiguration
•    Insecure Cryptographic Storage
•    Failure to Restrict URL Access
•    Insufficient Transport Layer Protection
•    Unvalidated Redirects and Forwards

Das Ziel sicherer und qualitativ hochwertiger Software wird inzwischen von mehreren Organisationen mit jeweils eigenen Schwerpunkten verfolgt. So legten die Institute MITRE und SANS im Auftrag mehrerer Unternehmen und Organisationen, darunter auch OWASP, die zweite Auflage ihrer 25 gefährlichsten Programmierfehler erst kürzlich vor.

Dave Wichers, Mitglied des OWASP-Vorstandes betont, die zunehmende Bedeutung der Risiken, die letztlich hinter den einzelnen Schwachstellen stehen. Sicherheitslücken nur zu priorisieren ohne das dazugehörige Anwendungsumfeld zu betrachten, ergäbe keinen Sinn so Wichers.

Diese neue Konzentration auch auf denkbare Risiken soll Organisationen helfen zu einem reiferen Verständnis von Anwendungssicherheit zu kommen sowie ihre Prozesse bzgl. sicherer Programmierung, Testmanagement und Softwarequalität entsprechend weiterzuenwickeln.

Die 25 häufigsten Programmierfehler

Jährlich untersucht eine Gruppe von 30 international auftretenden Sicherheitsunternehmen und -organisationen welche Arten von Programmierfehlern in Softwareprodukten vorkommen. So entstand eine jährlich aktualisierte Liste der 25 gefährlichsten Programmierfehler, durch die es zu groben Sicherheitslücken in Softwareprodukten kommt und die spektakuläre Exploits erst möglich machen.

Damit wird seitens der Organisationen das Ziel verfolgt, Programmierern das Wissen zu vermitteln, wie man Code schreibt, der frei von diesen Top-25-Programmierfehlern ist.

Die Ursachen für gefährliche Software-Schwachstellen sind unter Sicherheitsexperten hinreichend bekannt. Vielen Softwareentwicklern ist jedoch bis heute nicht bewusst, welche Gefahren durch unsichere Programmierung drohen. Hauptziel der Veröffentlichung der Sammlung ist es daher, Softwareentwickler auf häufig gemachte Programmierfehler hinzuweisen und somit durch sichere Programmierung Schwachstellen gar nicht erst aufkommen zu lassen – so Alexander Neumann auf Heise Developer.

Die gefundenen Schwachstellen wurden grob in drei Kategorien gegliedert:

1. Angriffspunkte beim Datenaustausch zwischen Systemen.
2. Schwachstellen beim Umgang mit wichtigen Ressourcen.
3. Fehlerhaft implementierte Sicherheitsmaßnahmen.

Angriffe wie Cross-Site-Scripting und Code-Injection zielen i.d.R. auf Schwachstellen der ersten Kategorie, Buffer-Overflow-Attacken oder DoS-Angriffe auf solche der zweiten. Und in jedem geknackten Kopierschutz, jedem umgangenen Passwort und jeder gebrochenen Kryptomethode wurden Fehler der dritten Art gefunden und ausgenutzt.

Auf Common Weakness Enumeration – Community-Developed Dictionary of Software Weakness Types wird die aktuelle Liste sowie weiterführende Informationen für Entwickler und Security-Experten bereitgestellt. Dazu zählen auch generische Empfehlungen zur Qualitätssicherung und Risikobegrenzung im Entwicklungsprozess.

Gegen ein Sicherheitsproblem der speziellen Art sind jedoch auch solche Listen machtlos: Den Versuch von Entscheidern, Software-Entwicklungsprojekte durch unrealistisch gesetzte Termine und schlampig berechnete Budgets zunächst unter Druck zu setzen und dies später durch Einsparungen bei der Qualitätssicherung korrigieren zu wollen.

Hier wird es wohl noch den ein oder anderen großen Datenskandal sowie die schonungslose Aufklärung und Aufdeckung seines Zustandekommens einschließlich Nennung aller Namen von verantwortlichen Entscheidern brauchen.

Wann und wie sich Daten von verschlüsselten Datenträgern wiederherstellen lassen

Wer Werkzeuge einsetzt, sollte sich zuvor mit deren Möglichkeiten und Grenzen vertraut machen. Das gilt insbesondere für Tools im Bereich der IT-Sicherheit und des Datenschutzes. Unsachgemäßer Gebrauch kann größere Sicherheitslücken erzeugen, als zuvor mit dem Tool geschlossen werden sollten.

Das zeigte auch ein Test mit der Verschlüsselungssoftware TrueCrypt. Mit ihr lassen sich verschlüsselte Containerdateien als „Datentresore“ anlegen und verwalten, aber auch komplette Laufwerke durch Verschlüsselung schützen. Anwender schätzen dies insbesondere bei mobilen Endgeräten, bei denen das Risiko des Abhandenkommens und damit die darauf gespeicherten Datenbestände abzusichern ist.

Marko Rogge beschreibt das Testvorgehen auf Searchsecurity folgendermaßen:

Im Test wurde ein USB-Stick verwendet, mit dem bereits Daten transportiert wurden, verschlüsselt oder unverschlüsselt. Die Daten, die sich auf dem Stick befanden, wurden nach dem Transport gelöscht, um Speicherplatz wieder frei zu geben. Dann wurde der USB-Stick mit TrueCrypt formatiert und mit einem neuen Passwort  versehen. Hierbei ist es besonders wichtig zu wissen, dass nicht alle Daten überschrieben werden und die Verschlüsselung somit noch nicht vollkommen greift. Daten die vorher auf dem jetzt neu verschlüsselten Device waren, sind unter forensischen Aspekten wieder herstellbar. Im Szenario wurde getestet, wie sich das Device unter forensischen Gesichtspunkten verhält, nachdem mittels TrueCrypt eine vollständige Formatierung und neue Verschlüsselung durchgeführt wurde. Fast alle Datenblöcke sind überschrieben worden, jedoch nicht alle! Der Test hat gezeigt, dass selbst nach einer Formatierung noch eindeutige Daten einsehbar waren und so Rückschlüsse zulassen.

Man sollte bei der Verwendung von Software zur Datenträger-Verschlüsselung also idealerweise neue, noch nicht anderweitig genutzte Datenträger verwenden und diese komplett durchverschlüsseln, ohne Restkapazität übrigzulassen.

Eine gebrauchte Festplatte sollte zunächst mit einem Tool zur sicheren Datenlöschung wie z.B. Recuva vorbehandelt werden, bevor man anschließend mit TrueCrypt die Containerdatei anlegt oder die Datenträgerverschlüsselung einsetzt.

Grundsätzlich gilt stets, dass Daten, die mit Hilfe betriebssystemeigener Funktionen gelöscht werden, nur als „freier Speicherplatz“ markiert aber nicht wirklich physisch gelöscht und damit abschließend entsorgt werden.

Internet-Security-Vollpakete – ist mehr wirklich mehr?

Wer die aktuelle Ausgabe 5/10 der Fachzeitschrift c’t aufschlägt, findet darin einen interessanten und durchaus provokativen Testbericht (eine gekürzte Version davon ist auch online abrufbar). Die c’t-Tester sind der Frage nachgegangen, was die diversen Security-Vollpakete verschiedener Anbieter tatsächlich taugen. Ausgewählt wurden Anbieter wie Avira, BitDefender G Data, Kaspersky und Norton, deren Virenscanner-Komponente als Standalone-Produkt oftmals bereits kostenlos verfügbar ist und ihre Tauglichkeit in vergangenen Tests bereits unter Beweis stellen konnten. Anbieter also, deren Produkte grundsätzlich gut dazu geeignet sind, ihre Nutzer vor Schadsoftware zu schützen.

Die in der Regel für zwischen 40-60 € für die Jahreslizenz erhältlichen Vollprodukte werden i.A. mit ihrem Mehr an Funktionalität und dem damit möglichen Rundumschutz beworben. Sie bringen Dinge wie Firewall, Spamfilter und einen Kinderschutz für die WWW-Nutzung sowie eine einheitliche integrierte Oberfläche für alles zusammen mit.

Doch der Test ergab für eigentlich alle Produkte löchrige, leicht zu durchdringende Firewall-Komponenten, Spamfilter die Mailkontenpasswörter im Klartext unverschlüsselt versenden, wenn sie auf Mailkonten zugreifen sowie Kindersicherungen, die einfach über das Booten des Rechners im abgesicherten Modus auszutricksen waren.

Und so raten die c’t-Tester ihren Lesern sich zunächst einen guten Antivirenschutz zu installieren und bei Zusatzkomponenten auf das reichhaltige Angebot an kostenlosen und oft genug sehr guten Zusatzprodukten zurückzugreifen Beispielsweise über die Rubrik „Sicherheit“ des Heise Software-Verzeichnisses. Die Security-Vollpakete sind vom technischen Reifegrad her betrachtet meist noch nicht das Geld wert, für das sie angeboten werden.