-
ACHTUNG - NEUES BLOG
Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
|
Hilfe! Ich werde verändert!
22.12.08 - Entwicklung, .NET, Grundlagen, Security Beitrag von Norbert Eder| | Im Artikel Ich werde beklaut! habe ich darüber geschrieben, wie einfach Ressourcen aus einer WPF-Anwendung entwendet werden können und warum es sich - aus meiner Sicht - nicht lohnt, diese Inhalte mit hohem Aufwand zu schützen.
Nun ist das Stehlen von Ressourcen (Layouts, Styles, Grafiken, etc.) wohl eine der häufigsten Arten, aber nicht die Schlimmste. Seltener, aber dennoch nicht zu unterschätzen ist es, wenn Software von Fremden bewußt verändert wird. Für viele Anwendungsbereiche mag das vielleicht kaum eine Relevanz haben, aber gerade im Security-Bereich kann dies äußerst unangenehme Folgen mit sich bringen. Aber wie kann man sich davor schützen?
Strong Named Assemblies
Der erste Ansatz ist, den eigenen Assemblies einen Strong Name zu verpassen. Die Identität der Assembly besteht hierbei aus ihrem Namen, der Versionsnummer und Informationen der Kultur (sofern diese gesetzt wurde) inklusive eines öffentlichen Schlüssels (Public Key), als auch einer digitalen Signatur. Dies ist ein einfacher Weg, der frei Haus durch .NET mitgeliefert wird, hat jedoch so seine Tücken als dass ein Strong Name sehr einfach entfernt werden kann. Danach kann die Software normal verwendet und auch verändert werden. Die veränderte Assembly kann zwar ohne Signatur nicht im den Global Assembly Cache (GAC) installiert werden, was aber in vielen Fällen auch nicht vorgesehen ist.
Nichts desto trotz sollte Strong Named Signing dennoch verwendet werden, da es doch eine zusätzliche Hürde darstellt und es daher für viele weniger attraktiv ist, die Software zu verändern. Alle Angreifer können damit allerdings nicht ausgeschlossen werden.
Wie vor Veränderung schützen?
Ein vollständiger Schutz ist nie möglich. Man kann es dem Angreifer aber erheblich schwerer machen. Es gibt zahlreiche Tools, die hier Abhilfe schaffen wollen. In diesem Zusammenhang werden oft Obfuscating-Tools genannt, die jedoch nicht vor Veränderung schützen. Andere Produkte fahren weit größere Geschütze auf. Eines davon ist CodeVeil. Dieses Tool bietet nicht nur Obfuscating-Mechanismen, sondern verschlüsselt zusätzlich auch MSIL. Weiters werden entschlüsselte Informationen nicht im selben Speicherbereich der Assembly geladen, wodurch eine Speicher-Dump erheblich erschwert wird.
Es gibt also durchaus Mechanismen, um sich bestmöglich zu schützen. Eine 100%ige Garantie wird es allerdings nie geben. Man kann also immer nur versuchen, einen Schritt vor den bösen Jungs zu sein bzw. es ihnen so schwer zu machen, dass die Attraktivität, die Software zu manipulieren, möglichst gering ist.
Wichtig ist zusätzlich, dass man sich als Entwickler über die Möglichkeiten der Angreifer informiert. Einen interessanten Einstieg bietet hier der Artikel Assembly Manipulation and C#/VB.NET Code Injection.
PS: Viele Tools unterstützen in den aktuellen Versionen weder WPF noch Silverlight. Hier bleibt zu hoffen, dass die Hersteller Mittel und Wege finden, uns Entwickler auch bei diesen Technologien mit Security zu unterstützen.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Sichere Kommunikation im Alltag, privat als auch geschäftlich
18.12.07 - Security Beitrag von Norbert Eder| | Abstract
Eines meiner Lieblingsthemen ist definitiv das Thema Security, zumal hier sehr gut philosophisch heran gegangen werden kann. Aus einer kleinen Diskussion heraus entstanden mehrere Kritikpunkte, die ich hiermit gerne loswerden möchte. Diese beschäftigen sich nicht nur mit Spionageangriffe auf Unternehmen, sondern auch mit dem Privatanwender und den Schwierigkeiten, die darauf warten, gelöst zu werden.
Security im Privatbereich
Vielleicht noch nicht so verbreitet, aber immer wieder kommen Fälle von Identitätsklau auf. Durch vermeintlich nicht interessante Informationen können Daten-Entwender recht schnell die Identität einer anderen Person einnehmen und so zu eventuell wichtigeren Informationen gelangen. Geschehen kann dies durch unterschiedlichste Kommunikationsarten. Allen voran sind hier sicherlich Instant Messenger (ICQ, MSN, Skype, etc.) als auch durch das Mitlesen von Emails.
Wie kann dem vorgebeugt werden? PGP-, S/MIME-Erweiterungen sind ein guter Ansatz. Auch andere Mittel und Wege können verwendet werden. Die Lösung klingt einfach, nicht? In der Praxis sieht wieder einmal alles ganz anders aus. Wie erkläre ich einer hübschen Dame am anderen Ende der Leitung, dass wir ab sofort nur mehr sicher kommunizieren und sie nun Plugin A installieren und so und so konfigurieren muss. Eventuell noch machbar. Möchte sie das ihren Freundinnen erklären, dann gestaltet sich dieser Weg schon wesentlich schwieriger.
Zudem fehlt einfach das notwendige Verständnis für diese Thematik. Es wird angenommen, dass bestimmte Informationen für andere einfach unwichtig sind. Klar, für die meisten sicher. Für einen möglichen Angreifer eventuell aber nicht. Und dieser hat es einfach: Kaum jemand verwendet entsprechende Hilfsmittel. Schließlich ist es schon Aufwand genug, alle Freunde und Bekannte auf ein und denselben Messenger zu bekommen. Da möchte man sie nicht noch mit Security-Dingen überfordern (und selbst dann eventuell stundenlange Konfigurationsarbeit leisten).
Thematiken wie Schlüsselstärke, Algorithmus und die entsprechenden Gesetze und Verordnungen, die pro Land verschieden sind, lasse ich mal lieber außen vor, da dies alles noch um ein gutes Stück erschweren würde.
Security im Geschäftsbereich
Auch hier sieht es nicht viel besser aus. Dass große Unternehmen Ziele von Spionage werden ist mehr oder weniger bekannt. Wie sieht es aber mit der kleinen Softwareschmiede um die Ecke aus?
Ich denke, dass ein sehr großer Anteil bezüglich Innovation aus den sogenannten KMUs (Klein- und Mittelunternehmen) stammt. Gerade in diesem Bereich würde sich also Spionage lohnen - neue innovative Ideen wollen natürlich bekannt sein, schließlich möchte man mit eigenen Geldmitteln wesentlich schneller zu einem derartigen Produkt kommen oder schon im Vorfeld wissen, welches Unternehmen aufgekauft werden will.
Security bedeutet Aufwand. Aufwand setzt sich aus Zeit und Geld zusammen. Beides ist möglicherweise in kleineren Unternehmen nicht ausreichend vorhanden. Daher findet sich Security eher in der Schublade der zu vernachlässigbaren TODOs wieder. Da hat es aber eindeutig noch mehr:
- Um sichere Kommunikation zu gewährleisten muss der Kommunikationspartner mitziehen. Dies gestaltet sich gerade bei kleineren Unternehmen als schwierig, da der Kommunikationspartner in vielen Fällen größer ist und sich somit nicht so einfach zu dieser Maßnahme bewegen läßt. Der Größere sitzt einfach am Hebel.
- Produkte, die sichere Kommunikation gewährleisten, sind großteils für Unternehmen mit hunderten Beschäftigten ausgerichtet und für Kleinunternehmen oft nicht erschwinglich.
- Die Gesetzeslage muss bekannt sein, ist es aber meist nicht. Hier würde definitiv Aufwand entstehen, der von vielen Unternehmen nicht geleistet werden möchte.
- Kleine Unternehmen müssen schnell Ergebnisse liefern, d.h. Marktanteile gewinnen, Gewinne erzielen usw. Durch fehlende Ressourcen kann es hier schon mal für das eigentliche Produkt knapp werden. An andere Umsetzungen zu denken ist da oft nicht drinnen.
Wie man sieht, sind hier einige Punkte nicht einfach umzusetzen. Die richtige Lösung fehlt und wird wohl auch so schnell nicht zu finden sein.
Fazit
Wer sicher kommunizieren möchte, der hat natürlich einige Möglichkeiten, muss mit diesen jedoch auch vertraut sein. Es gehört eine gute Portion Verständnis dazu. Etwas, was von einem Nicht-IT-Fachmann nur schwer erübrigt wird/werden kann. Für Unternehmen stehen andere Punkte im Vordergrund, schließlich muss man erst einmal am Markt überleben.
Und solange es nicht per Knopfdruck, oder besser nicht mal das, funktioniert, wird es schwierig, zumal da andere Institutionen noch ihre Hand drauf halten (siehe Gesetze etc. in Frankreich usw.).
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
iPhone und die liebe Sicherheit
24.07.07 - Internet, Security Beitrag von Norbert Eder| | Einen sehr netten Artikel zum Thema iPhone und Sicherheit hat Frank veröffentlicht. Zwar recht lustig geschrieben, dennoch trifft der Beitrag durchaus des Pudels Kern. Da wird Apple wohl noch einmal ein paar alte Aussagen überdenken müssen ...
| | | 4 Kommentare
- 1011 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Rückblick Livecast Rootkits
11.04.07 - Security Beitrag von Norbert Eder| | Gestern hat er nun stattgefunden. Der lang erwartete Livecast über Rootkits von Frank Solinske. Und ich muss sagen, dass es mich schon irgendwie getroffen hat.
Ansich bin ich in den gestrigen Cast mit doch ein wenig Vorwissen über das Thema Security gegangen. Zumindest getraue ich mir zu, doch ein wenig mehr über das Thema zu wissen, als der Großteil der Menschen, die Computer verwenden. Ernüchternd war allerdings zu sehen, wie "einfach" es gehen kann. Mit der richtigen Strategie, ein wenig Know-How und den richtigen Tools kann es schon ganz gewaltig abgehen.
Eigentlich wollte ich ja bereits gestern nach dem Livecast einen kleinen Rückblick schreiben, aber dann musste ich doch noch eine Nacht darüber schlafen, um alles sickern zu lassen. Und selbst jetzt bin ich noch etwas aufgewühlt.
Da glaubt man doch tatsächlich ein wenig paranoid zu sein, was die Sicherheit am eigenen Rechner betrifft, um dann zu raffen, dass dem eigentlich überhaupt nicht so ist. Mehr muss es sein.
Nun gut, auf jeden Fall werden wir den Mitschnitt auf .NET Casts bereitstellen, damit sich jeder Interessierte sein eigenes Bild darüber machen kann.
Nochmal ein herzliches Dankeschön an Frank für diesen absolut genialen Vortrag, der sicherlich allen Teilnehmern gewaltig die Augen geöffnet hat.
PS: Wie es nun mit den Livecasts weitergeht, ist noch nicht ganz geklärt. Sobald es eine gute Lösung gibt (die auch qualitätsmäßig in Ordnung ist), werden wir dies entsprechend bekannt geben. Möchte uns jemand unterstützen (zum Beispiel durch gutes Zureden, etc.) dann möge man sich direkt bei mir melden. Danke.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Sicherheitsloch in Visual Studio 2005
02.11.06 - Security Beitrag von Norbert Eder| | So, nun hat es also auch Visual Studio 2005 erwischt. Laut Microsoft [1] steckt der Fehlerteufel in einem von Visual Studio 2005 verwendeten ActiveX Control.
Ganz genau handelt es sich um das WMI Object Broker Control, welches in der Library WmiScriptUtils.dll zu finden ist.
Durch die Sicherheitslücke ist es dem Angreifer möglich, Code auszuführen. Ein Update ist geplant und wird wohl bald entsprechend verteilt werden.
[1] Microsoft Security Advisory (927709)
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Encryption-Framework BouncyCastle
27.10.06 - .NET, Allerlei, Security Beitrag von Norbert Eder| | Vor Jahren hatte ich aufgrund eines Projektes mit der Java-Version von Bouncycastle zu tun. Stichwörter: S/MIME, PGP. Auch damals gab es schon eine rudimentäre C#-Umsetzung [1], welche ich hier nun einmal kurz erwähnen möchte.
Am 24. Oktober 2006 (also vor ein paar Tagen) gab es ein weiteres Beta-Release, welches ansich schon recht gut funktioniert und auch zahlreiche Funktionalitäten bietet. Wer also Bedarf an einem Encryption-Framework hat, tut gut daran, sich BouncyCastle näher anzusehen.
[1] BouncyCastle C# Framework
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Security unter dem .NET Framework 2.0
06.02.06 - Security Beitrag von Norbert EderBürgerkarte, A-Trust und der Spaß am Signieren
28.01.06 - Security Beitrag von Norbert Eder| | ... der sich aber vielleicht bald aufhört. A-Trust scheint es ja derzeit nicht besonders gut zu gehen. Noch dazu will niemand für A-Trust die Hand ins Feuer legen - zumindest sieht alles danach aus.
Was passiert aber, wenn A-Trust den Bach runter geht? Nun, einige mögen sagen: "Hey, die Zertifikate von A-Trust sind eh noch eine Zeit gültig.". Theoretisch schon. Praktisch wirds wohl eher ein Fall für die Revocation List. Sprich, die Zertifkate werden dann als abgelaufen bzw. zurückgezogen markiert und schon ists wieder vorbei mit der Bültigkeit des eigenen Zertifikats (Beispiel Bürgerkarte bzw. Signaturfunktion auf den Bankomatkarten).
Zahlen dann alle umsonst für ihre Signaturfunktion? Traut sich dann in Österreich überhaupt noch jemand über dieses Thema drüber? Oder müssen wir es vielleicht den großen Konzernen überlassen unsere Daten zu verwalten? Da hab ich meine Daten doch lieber beim Staat bebunktert, der hat diese Informationen ohnehin schon. Also Vater Staat, vielleicht weniger über ein paar Gemälde diskutieren und viel mehr A-Trust retten.
Und beim Thema "Fax und Signatur" stellts mir sowieso gleich die Haare auf ... aber das ist ein Thema für einen anderen Eintrag.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Bürgerkarte: Des Usability-Problems 2. Teil
05.12.05 - Security Beitrag von Norbert Eder| | Zum Thema Bürgerkarte/Signaturkarte habe ich doch glatt noch einen weiteren Punkt(ursprüngliche Post ist hier zu finden), den ich aus Usability-Sicht nicht ganz nachvollziehen kann.
Die Bürgerkarte/Signaturkarte soll doch eigentlich für jeden sein - und zwar nicht nur für Online-Bankgeschäfte, sondern auch zum Signieren von Emails. Nur, viele Bürger gehen doch einer Beschäftigung nach und manche machen auch Dienst in einem Büro. Diejenigen, die im Büro arbeiten (und da bin ich mir ganz sicher), rufen auch ihre privaten Emails ab bzw. schreiben mit ihrer privaten Adresse Nachrichten. Diese wollen eigentlich auch signiert werden.
Der Haken an der Geschichte? Wer schleppt das unhandliche externe Kartenlese-Gerät mit? Vielleicht 2, 3 Tage und dann nicht mehr. Daher gibt es dann genau zwei Möglichkeiten:
- entweder zu Hause oder in der Firma wird signiert
- Anschaffung eines zweiten Kartenlese-Gerätes
Zwei sehr gute Alternativen. Warum werden nicht handlichere Geräte angeboten? Die Technik dazu ist vorhanden und würde allen Beteiligten das Leben um sehr viel einfacher gestalten.
Hinweis: Natürlich besitzen die neuen Laptops zum Großteil integrierte Kartenleser. Diese sind aber zum Großteil nicht zertifiziert. Dies bedeutet, dass eine signiert Email unter Verwendung eines nicht zertifizierten Lesegerätes genauso viel Gültigkeit vor Gericht hat, wie eine nicht signierte Email. Sogesehen ist deren Verwendung ziemlich sinnlos.
Schöne neue Technik ...
| | | 1 Kommentar
- 1196 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Bürgerkarte und schnelles, einfaches Signieren ...
04.12.05 - Security Beitrag von Norbert Eder| | ... denkste!!
Ein kleines Übungsbeispiel:
Man gehe zur Bank und besorge sich eine signaturfähige Karte. Danach einfach einen notwendigen Termin ausmachen (Daten angeben, PINs festlegen etc.). Nun schnell einen externen, zertifizierten Cardreader gekauft und am Rechner alles notwendige installieren und schon kann es losgehen mit signierten Emails.
Das klingt in der Theorie ganz einfach, birgt aber in der Praxis das eine oder andere Problem. Denn, nach dem Einrichten des Zertifikates im entsprechenden Mailclient war ein Email (und zwar ein signiertes) schnell geschrieben. Beim Absenden kommt dann die PIN-Abfrage, dieser wurde eingegeben und schon war das Testemail weg. Ein paar Augenblicke später war es im Posteingang und wollte verifiziert werden. Fehlgeschlagen! Welches Problem liegt da wohl vor? Oh. Verdammt. Das Stammzertifikat der Zertifizierungsstelle muss noch installiert werden. Gesagt, getan! Und die Verifizierung? Fehlgeschlagen. Was kann das jetzt schon wieder sein? Autsch. Da wollen noch ein paar Zwischenzertifikate installiert werden, damit der Zertifizierungspfad verfolgt werden kann. Gemacht und schon kann das Email verifiziert werden. Juhu, dieses Email ist eindeutig von mir.
Tja, das klingt ja eigentlich gar nicht so schwer. Nur bergen auch die unterschiedlichen Email-Clients so ihre Eigenheiten. Zum Beispiel müssen beim Thunderbird die Zertifikate direkt importiert werden, denn der Windows Root Certificate Store wird hier nicht ausgelesen. Etwas nervig, aber Thunderbird-Benutzer wissen das ja ;-)
Auch Outlook hat so seine Problemchen damit. So sollte unter den Optionen/Lasche Sicherheit der Punkt "Signierte Nachrichten als Klartext senden" nicht angehakt sein, wenn HTML-Mails versendet werden (dies sollte das eine oder andere Mal vorkommen, vor allem wenn man die Standard-Konfiguration von Outlook verwendet). Hier werden anscheinend nach dem Erstellen der Signatur erst die Änderungen im Body vorgenommen, wodurch die Signatur ungültig wird.
Diese und weitere Probleme warten auf den Otto-Normal-Verbraucher, der sich einbildet, seine Email ab sofort signiert versenden zu müssen. Hier sind noch einige Usability-Experten gefragt, um dies für den allgemeinen User transparenter und vor allem einfacher zu machen. Denn selbst Personen, die sich damit auskennen haben das eine oder andere Problem damit ...
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
|
|
|
|
|
|
|
