INSO – Industrial SoftwareInstitut fur Information Systems Engineering | Fakultat fur Informatik | Technische Universitat Wien
Security for Systems Engineering –VO 02: Sichere Programmierung
Thomas StipsitsRaphael KiefmannAndreas EhringfeldFlorian Fankhauser
Security for Systems Engineering SS20 | Sichere Programmierung
Agenda
2 / 57
Einfuhrung in die sichere Programmierung
Eingabe- & Ausgabevalidierung
Bibliotheken und Frameworks
Exception Handling
Logging
Umgang mit sensiblen Informationen
Vererbung
Einfuhrung in die sichere Programmauslieferung
Code Obfuscation
Code Encryption
Code Signing
Encrypted Configuration
Zusammenfassung
Security for Systems Engineering SS20 | Sichere Programmierung
Aktuelles aus dem Securitybereich
3 / 57
■ (05.03.2020) Intel x86 Root of Trust: loss of trust
■ (10.03.2020)
LVI - Hijacking Transient Execution with Load Value Injection
■ (20.03.2020)
Datenleck bei Coronavirus-Seite des Gesundheitsministeriums
■ (19.03.2020)
Cyber-Erpresser versprechen Corona-Pause fur Krankenhauser
■ (16.03.2020)
Slack fixes vulnerability exploitable for session hijacking, account takeovers
Security for Systems Engineering SS20 | Sichere Programmierung
Grunde fur unsichere Software
4 / 57
■ Inhaltliche Fehler bedingt durch
■ Komplexitat, haufige Modifikation, Zeitdruck
■ Fehlende Kommunikation im Entwicklungsteam (inklusive QS
und PM)
■ Keine ausreichende Testabdeckung
■ Programmierfehler
■ Fehlerhafte / keine Eingabe- bzw. Ausgabevalidierung
■ Hardcoding von sensiblen Informationen
■ Designschwachen im / beim
■ Applikationsworkflow, Datenmodell
■ Logging bzw. Exception Handling
■ Falsche Annahmen in Bezug auf Sicherheit
Security for Systems Engineering SS20 | Sichere Programmierung
Schutzziele, Sicherheitsanforderungen und
Sicherheitsbewusstsein in Bezug auf die Softwareentwicklung
5 / 57
■ Identifikation des Umfeldes
■ Schutzguter (Assets) & deren Schutzbedarf erheben
■ Bedrohungen modellieren
■ Organisatorische Maßnahmen
■ Berucksichtigung der Schutzziele
■ Definition von zusatzlichen funktionalen und
nicht funktionalen Sicherheitsanforderungen
■ Security-Awareness im Entwicklungsteam schaffen
(Vergleiche ESSE Introduction to Security – VO Sicherheit in der
Softwareentwicklung)
Security for Systems Engineering SS20 | Sichere Programmierung
Eingabe- & Ausgabevalidierung – Einfuhrung
6 / 57
■ Uberprufen des Formats
■ Uberprufen des Datentypes
■ Uberprufen des Wertebereiches
■ Uberprufen auf Schadinformationen
Security for Systems Engineering SS20 | Sichere Programmierung
Eingabe- & Ausgabevalidierung – Filtern vs. Sanieren
7 / 57
■ Filtern
■ Blacklist Filter
■ Whitelist Filter (zu praferieren)
■ Sanieren
■ Konvertieren (Escapen) von Sonderzeichen/Anweisungen
■ Integritat der Daten darf nicht verloren gehen
■ Beispiel - Sanitizing gegen Directory Traversal:
-”../“ wird durch Sanitization entfernt.
- Problem:”....//“ umgeht Mechanismus
GET / v u l n e r a b l e . php HTTP/1 .0
Cookie : TEMPLATE= . . / . . / . . / . . / . . / . . / . . / . . / . . / e t c /passwd
Security for Systems Engineering SS20 | Sichere Programmierung
Eingabe- & Ausgabevalidierung – Problematik
8 / 57
(Vergleiche JStill: mostly static detection of obfuscated malicious JavaScript
code, Xu, 2013)
Security for Systems Engineering SS20 | Sichere Programmierung
Eingabe- & Ausgabevalidierung – Validierungsmoglichkeiten
9 / 57
■ Client
■ Performanter
■ Sehr fruhe Validierung moglich
■ Kann allerdings umgangen werden
■ Server
■ Validierung erfordert Systemresourcen
■ Server-seitige Validierung ist verpflichtend
Security for Systems Engineering SS20 | Sichere Programmierung
Eingabe- & Ausgabevalidierung – Beispiel Logging (Go)
10 / 57
Ausgabevalidierung beim Schreiben eines Log-Files – Bad Style
func l o g i nCheck ( username s t r i n g ) {
l o g i n S u c c e s s f u l := l o g i n ( username )
i f l o g i n S u c c e s s f u l {
l o g . Wi thF i e l d ( ” u s e r ” , username ) . I n f o ( ” Log in succeeded . ” )
} e l s e {
l o g . Wi thF i e l d ( ” u s e r ” , username ) . I n f o ( ” Log in f a i l e d . ” )
}
}
Wo gibt es Schwachen in dieser Losung?
Security for Systems Engineering SS20 | Sichere Programmierung
Eingabe- & Ausgabevalidierung – Beispiel Logging
Auswirkung (Go)
11 / 57
Ausgabevalidierung beim Schreiben eines Log-Files – Bad Style
1. Angreifer meldet sich als user_eve an
INFO[20200310141910] User l o g i n f a i l e d . u s e r=u s e r e v e
2. Angreifer verwendet neuen”Benutzername“
u s e r e v e
INFO[20200310141910] User l o g i n succeeded . u s e r=admin
3. Angreifer erreicht damit 2 Eintrage im Log-File
INFO[20200310141910] User l o g i n f a i l e d . u s e r=u s e r e v e
INFO[20200310141910] User l o g i n succeeded . u s e r=admin
Security for Systems Engineering SS20 | Sichere Programmierung
Eingabe- & Ausgabevalidierung – Beispiel Logging (Go)
12 / 57
Ausgabevalidierung beim Schreiben eines Log-Files – Good Style
func l o g i nCheck ( username s t r i n g ) {
username=san i t i z eU s e r n ame ( username )
l o g i n S u c c e s s f u l := l o g i n ( username )
. . .
}
func s a n i t i z eU s e r n ame ( username s t r i n g ) s t r i n g {
match , := regexp . MatchSt r ing ( ” [A−Za−z0−9 ]+” , username )
i f match {
r e t u rn username
}
r e t u rn ” u n a u t h o r i z e d u s e r ”
}
Security for Systems Engineering SS20 | Sichere Programmierung
Bibliotheken und Frameworks – Einfuhrung
13 / 57
■ Verwendung sicherer Funktionen
■ Verwendung existierender Frameworks / Bibliotheken
■ Sind meist bereits gut getestet und sicher
■ Verbessern den Lesefluss des Codes
■ Vermeiden von zusatzlichen Fehlerquellen
■ Abhangigkeit zu Framework / Bibliothek
■ Aber: Kein blindes Vertrauen!
■ Verwendung existierender Tools zur statischen Codeanalyse
■ Auffinden von bereits bekannten unsicheren Funktionen
■ Statische Uberprufung der Einhaltung von Coderichtlinien
Security for Systems Engineering SS20 | Sichere Programmierung
Sichere Funktionen – Beispiel C Bad Style
14 / 57
Offnen und Schreiben einer Datei
char ∗ f i l e n ame ;
FILE ∗ f p ;
/∗ I n i t i a l i z e f i l e n am e ∗/
f p = fopen ( f i l e n ame , ”w” ) ;
i f ( ! f p ) {
/∗ Handle e r r o r ∗/
}
Welche Schwachen gibt es in dieser Losung?
(Vergleiche https://www.securecoding.cert.org/ - FIO03-C)
Security for Systems Engineering SS20 | Sichere Programmierung
Sichere Funktionen – Beispiel C Erlauterung
15 / 57
Offnen und Schreiben einer Datei – Bad Style
■ Die Datei kann in ein unsicheres Verzeichnis generiert werden
■ Default-Dateiberechtigungen werden vom OS vergeben
■ Ein Angreifer
■ Kann Command Injection durchfuhren
■ Kann Zugriff auf verschiedene Verzeichnisse erlangen
■ Kann existierende Dateien uberschreiben
Security for Systems Engineering SS20 | Sichere Programmierung
Dateierzeugung – Beispiel C Good Style
16 / 57
Offnen und Schreiben einer Datei
// Standard C
char ∗ f i l e n ame ;
FILE ∗ f p
e r r n o t r e s = f o p e n s (&fp , f i l e n ame , ”wx” ) ;
i f ( r e s != 0) {
/∗ Handle e r r o r ∗/
}
(Vergleiche https://www.securecoding.cert.org/ - FI003-C)
Security for Systems Engineering SS20 | Sichere Programmierung
Exception Handling
17 / 57
■ Bezeichnet die explizite Abarbeitung eines nicht vorhergesehenen
bzw. nicht definierten Softwareverhaltens,
z.B. Offnen von nicht existierenden Dateien
■ Keine sensible Information preisgeben, falls Exception auftritt
■ Software muss sich wieder in einem sicheren Status nach der
Exception-Behandlung befinden
■ Faustregeln bei der Implementierung
■ throw early
■ catch late
■ Be specific (Benutzersicht) vs. be general (Sicherheitsicht)
Security for Systems Engineering SS20 | Sichere Programmierung
Exception Handling – Bad Style
18 / 57
func r e a d F i l e ( path s t r i n g ) s t r i n g {
f i l e , e r r := os . Open ( path )
i f e r r != n i l {
debug . P r i n t S t a c k ( )
l o g . F a t a l ( e r r . E r r o r ( ) )
}
data , e r r := i o u t i l . ReadAl l ( f i l e )
i f e r r != n i l {
debug . P r i n t S t a c k ( )
l o g . F a t a l ( e r r . E r r o r ( ) )
}
r e t u rn s t r i n g ( data )
}
Security for Systems Engineering SS20 | Sichere Programmierung
Exception Handling – Wrapping Nightmares
19 / 57
func r e a d F i l e ( path s t r i n g ) s t r i n g {
f i l e , e r r := os . Open ( path )
s t r i p p e d := f i l e p a t h . Base ( path )
i f e r r != n i l {
l o g . Wi thF i e l d ( ” f i l e ” , s t r i p p e d ) . F a t a l ( ”Open f a i l e d . ” )
}
data , e r r := i o u t i l . ReadAl l ( f i l e )
i f e r r != n i l {
l o g . Wi thF i e l d ( ” f i l e ” , s t r i p p e d ) . F a t a l ( ”Read f a i l e d . ” )
r e t u rn ””
}
r e t u rn s t r i n g ( data )
}
Error enthalt Informationen zu Struktur des Filesystems und erlaubt u.A.
User Name Enumeration
Security for Systems Engineering SS20 | Sichere Programmierung
Exception Handling – Runtime- vs. Checked-Exception
20 / 57
■ Exceptions sind Teil von Schnittstellen/Services
■ Teil des Agreements zwischen Service-Nutzer und Anbieter
■ Exceptions immer so feingranular wie moglich angeben
■ Runtime-Exception nur in begrundeten Ausnahmefallen verwenden
(Vergleiche http://www.ntu.edu.sg/home/ehchua/programming/java/
j5a_exceptionassert.html)
Security for Systems Engineering SS20 | Sichere Programmierung
Exception Handling – Beispiel Runtime- vs.
Checked-Exception Bad Style
21 / 57
p u b l i c i n t e r f a c e FooSe r v i c e {
p u b l i c boo lean foo ( S t r i n g a rg ) ;
}
p u b l i c c l a s s FooSe r v i c e Imp l implements FooSe r v i c e {
p u b l i c boo lean foo ( S t r i n g a rg ) {
throws new Runt imeSe r v i c eExc ep t i on ( ) ;
}
}
p u b l i c c l a s s Co n t r o l l e r {
@Autowired p r i v a t e FooSe r v i c e f o o S e r v i c e ;
. . .
t r y {
f o o S e r v i c e . foo ( n u l l ) ;
} catch ( Run t imeSe r v i c eExc ep t i on e ) { . . . }
. . .
}
Security for Systems Engineering SS20 | Sichere Programmierung
Logging – Einfuhrung
22 / 57
■ Protokollieren von Benutzeraktionen
■ Prinzipiell alles loggen, aber zumindest
■ Erfolgreiche und fehlgeschlagene Anmeldeversuche
■ Authorization requests
■ Datenmanipulation (CRUD)
■ Session-Terminierung
■ Verwendung von Logging-Frameworks empfohlen (z.B. logback, . . . )
■ Wahl des Formats in Hinblick auf Anforderungen! (z.B.
Auswertbarkeit, Informationsgehalt, . . . )
■ Konsistenz des Formats von Eintragen und des Logfiles
Security for Systems Engineering SS20 | Sichere Programmierung
Logging – Konzept-Fragestellungen
23 / 57
■ Was wird geloggt? - Detailgrad des Logs, geloggte Events, . . .
■ Wo wird geloggt? - Speicherort der Logdateien,
Zugriffsbeschrankungen
■ Wie wird geloggt? - Große, Lebensdauer und Format von Logdateien,
Logging-Frameworks und Implementierung des Loggers
■ Warum wird geloggt? - Zielsetzung des Loggingvorganges,
thematische Aufteilung
Security for Systems Engineering SS20 | Sichere Programmierung
Logging – Problematik
24 / 57
■ Vertraulichkeit der Daten - Vertaulichkeit sensibler Informationen
muss gewahrleistet werden!
■ Integritat der Daten - Nachvollziehbarkeit bei Anderungen!
Anderungen nur durch Autorisierte!
■ Verbindlichkeit der Daten - Nichtabstreitbarkeit fur Ausloser des
Logeintrags!
■ Compliance der Eintrage - Oftmals mussen Eintrage bestimmte
Anforderungen an das Format/Informationsgehalt/. . . erfullen.
Security for Systems Engineering SS20 | Sichere Programmierung
Umgang mit sensibler Information – Einfuhrung
25 / 57
■ Viele Applikationen arbeiten mit sensiblen Daten
■ Daten meistens unverschlusselt
■ Vertraulichkeit und Integritat wird gefahrdet
■ Guidelines (z.B BSI IT-Grundschutz Kompendium[1]) :
■ Kein Hardcoding von sensiblen Informationen in der Applikation
■ Keine Speicherung uber Verwendungszeitpunkt hinaus
■ Wenn sensible Daten gespeichert werden mussen
→ zuerst verschlusseln (oder hashen)
■ Sicheres Entfernen von sensiblen Daten von HDD oder RAM
(Vergleiche [1] https://www.bsi.bund.de/DE/Themen/ITGrundschutz/
ITGrundschutzKompendium/itgrundschutzKompendium_node.html)
Security for Systems Engineering SS20 | Sichere Programmierung
Umgang mit sensibler Information – Beispiel Hashing Bad
Style
26 / 57
func getHashBad ( password s t r i n g ) [ ] byte {
h := sha1 .New( )
r e t u rn h . Sum ( [ ] byte ( password ) )
}
■ Welche Schwachen gibt es in dieser Losung?
(Vergleiche https://www.owasp.org/)
Security for Systems Engineering SS20 | Sichere Programmierung
Umgang mit sensibler Information – Beispiel Hashing
Erlauterung
27 / 57
■ Probleme
■ Verwendung eines unsicheren Hash-Verfahrens
■ Kein Salt-Wert
■ Zielsetzung des Hashings berucksichtigen
■ Bessere Hash-Verfahren:
■ Bcrypt: langsamen Hashes → Zeitaufwand fur Angreifer bei
Brute Force Angriffen
■ SHA-256/512: derzeit als Sicher eingestuftes Hash-Verfahren
(Vergleiche https://www.mindrot.org/projects/jBCrypt/
https://www.owasp.org/)
Security for Systems Engineering SS20 | Sichere Programmierung
Umgang mit sensibler Information – Beispiel Hashing Good
Style
28 / 57
func getHashGood ( password s t r i n g ) [ ] byte {
hash , e r r := bc r yp t . GenerateFromPassword ( [ ] byte ( password ) ,
b c r yp t . De f au l tCo s t )
i f e r r != n i l {
l o g . E r r o r ( ” F a i l e d to g en e r a t e password hash . ” )
}
r e t u rn hash
}
(Vergleiche https://www.owasp.org/)
Security for Systems Engineering SS20 | Sichere Programmierung
Umgang mit sensibler Information – Beispiel Harcoding Bad
Style (C++)
29 / 57
Client-seitiger Code zur Authentifizierung auf Remote Service:
/∗ Returns nonze ro i f a u t h e n t i c a t e d ∗/
i n t a u t h e n t i c a t e ( s t d : : s t r i n g password ) ;
i n t main ( ) {
i f ( ! a u t h e n t i c a t e ( ” s u p e r s e c r e t p a s swo r d ” ) ) {
p r i n t f ( ” Au t h e n t i c a t i o n e r r o r \n” ) ;
r e t u rn −1;
}
p r i n t f ( ” Au t h e n t i c a t i o n s u c c e s s f u l \n” ) ;
// . . . Work wi th system . . .
r e t u rn 0 ;
}
Security for Systems Engineering SS20 | Sichere Programmierung
Umgang mit sensibler Information – Beispiel Harcoding Good
Style (C++)
30 / 57
/∗ Returns nonze ro i f a u t h e n t i c a t e d ∗/
i n t a u t h e n t i c a t e ( s e c u r e s t r i n g password ) ;
s e c u r e s t r i n g getPasswordFromUser ( ) ;
i n t main ( ) {
s e c u r e s t r i n g password = getPasswordFromUser ( ) ;
i f ( ! a u t h e n t i c a t e ( password ) ) {
p r i n t f ( ” Au t h e n t i c a t i o n e r r o r \n” ) ;
r e t u rn −1;
}
password . purge ( ) ;
p r i n t f ( ” Au t h e n t i c a t i o n s u c c e s s f u l \n” ) ;
// . . . Work wi th system . . .
r e t u rn 0 ;
}
Security for Systems Engineering SS20 | Sichere Programmierung
Risiken bei Vererbung – Beispiel Java
31 / 57
■ Subklassen uberschreiben Code der Superklassen
■ Sicherheitsrelevanten Klassen schutzen, indem diese als final
markiert werden ⇒ Keine Vererbung moglich■ Klassen mit ausschließlich statischen Methoden sollten einen
privaten Konstruktor verwenden
■ Superklassen konnen Subklassen beeinflussen
■ java.security.Provider erbt von java.util.Hashtable
■ java.security.Provider uberschreibt Methoden und
verwendet SecurityManager
■ Ab JDK 1.2 neue Method in java.util.Hashtable, welche in
java.security.Provider nicht uberschrieben wurde
(Vergleiche http://www.oracle.com/technetwork/java/
seccodeguide-139067.html)
Security for Systems Engineering SS20 | Sichere Programmierung
Von der sicheren Programmierung zur sicheren
Programmauslieferung
32 / 57
■ Sicherheitsanforderungen, sicheres Design
■ Sichere Programmierung
■ Befolgung von Richtlinien, Guidelines
■ Verwendung von Standards und Best-Practice
■ Testing
■ Unit-Test, Komponententest, Systemtests, usw.
■ Sicherheitstests
■ Nachster Schritt → Auslieferung der Software
■ Weitere Maßnahmen sind zu treffen
Security for Systems Engineering SS20 | Sichere Programmierung
Programmauslieferung – Beispiele fur Ziele von Angreifern
33 / 57
■ Vertraulichkeit
■ Informationen sammeln (z.B. Passworter, Benutzernamen, URLs,
IPs)
■ Code analysieren (z.B. Authentifizierungsmethoden,
Lizenzuberprufungen)
■ Integritat
■ Code manipulieren
■ Eigenen (Schad)Code einbringen
■ Konfigurationen manipulieren
■ Authentizitat
■ Manipulierten Code verteilen, wobei der Name einer Firma
missbraucht wird
Security for Systems Engineering SS20 | Sichere Programmierung
Programmauslieferung – How NOT to do: APT-GET RCE
34 / 57
Incorrect sanitation of the 302 redirect field in HTTP
transport method of apt versions 1.4.8 and earlier can lead to
content injection by a MITM attacker, potentially leading to
remote code execution on the target machine.
■ CVE-2019-3462
■ Betraf Ubuntu, Debian & Linux Mint (APT-Package Manager)
■ Grundproblem war Package Download per HTTP mit Bug bei HTTP
Redirects
■ Durch HTTP Redirect war Content Injection moglich
■ Injection in Release.gpg -Response fuhrt zu Package Installation
(Vergleiche siehe https://nvd.nist.gov/vuln/detail/CVE-2019-3462 und
https://justi.cz/security/2019/01/22/apt-rce.html)
Security for Systems Engineering SS20 | Sichere Programmierung
Code Obfuscation – Beispiele fur Ziele von Reverse
Engineering
35 / 57
■ Kontrollfluss
■ Einprogrammierte Werte
■ Vorhandener Testcode
■ Verwendete Mechanismen (z.B. Prufen von Lizenzen oder
Authentifizierungsdaten)
■ Whitebox Angriffe
Security for Systems Engineering SS20 | Sichere Programmierung
Code Obfuscation – Einfuhrung
36 / 57
■ Lesbarkeit des Codes fur Menschen erschweren
■ Den Aufwand des Dekompilierens erhohen
■ Programme vor Reverse Engineering schutzen
Aber haufig auch durch Blackhats eingesetzt!
■ Analyse fur Forensiker erschweren
■ Verhindern einer automatisierten Detektion des Schadcodes
■ Verschleierung von Exploitcode
Security for Systems Engineering SS20 | Sichere Programmierung
Code Obfuscation – Layout/Name Obfuscation
37 / 57
■ Umbenennung von Bezeichnern (z.B. Variablen, Methoden, Klassen)
■ Loschen von Debug-Informationen (meist von Compiler eingefugt)
Vor- bzw. Nachteile:
■ Erschwert Lesbarkeit des Codes
■ Muhsames nachvollziehen der Funktionalitaten
■ Programmlogik & -fluss bleibt erhalten
Security for Systems Engineering SS20 | Sichere Programmierung
Code Obfuscation – Layout Obfuscation
38 / 57
(Vergleiche https://rjlipton.files.wordpress.com/2010/05/code.png)
Security for Systems Engineering SS20 | Sichere Programmierung
Code Obfuscation – Control Flow Obfuscation
39 / 57
■ Andern des Program-Control-Flusses (z.B. Neue (ungultige)
Code-Abschnitte durch Code Insertion)
■ Andern des Programmablaufes
Vor- bzw. Nachteile:
■ Erschwert Nachvollziehbarkeit der Programmlogik
■ Programme werden großer und langsamer
■ Programm kann beeinflusst werden (z.B. Fehler werden eingebaut)
Security for Systems Engineering SS20 | Sichere Programmierung
Code Obfuscation – Data Obfuscation
40 / 57
■ Andern der Vererbungsbeziehung
■ Array-Restrukturierung
■ Clone-Methoden (verschiedene Versionen von Methoden)
■ Aufspalten der Variablen
■ String-Manipulationen
Vor- bzw. Nachteile:
■ Erschwert sehr stark die Nachvollziehbarkeit des Codes
■ Programme werden großer und langsamer
Security for Systems Engineering SS20 | Sichere Programmierung
Code Obfuscation – Ausblick
41 / 57
Vorteile:
■ Relativ guter Schutz gegen Reverse Engineering
■ Einfach anzuwenden
Nachteile:
■ Beschrankt einsetzbar fur Bibliotheken und Frameworks
■ Sinnvoll nur bei einzelnen Klassen
■ Konfigurationen beachten
■ Sicherheit nicht garantiert
Security for Systems Engineering SS20 | Sichere Programmierung
Code Encryption – Einfuhrung
42 / 57
Ziele von Code Encryption
■ Zugriff auf Code einschranken
■ Code vor Manipulation schutzen
■ Dekompilieren verhindern
Einschrankungen
■ Aufbewahrung des Schlussels/Entschlusselungsalgorithmus
■ Debugging der Applikation
Security for Systems Engineering SS20 | Sichere Programmierung
Code Encryption – Ansatze
43 / 57
■ Binarcode manipulieren
■ Ausnutzen einer VM und dessen Klassenlademechanismus
■ Externe Applikation ubernimmt die Interpretation des Codes
■ Quellcode manipulieren
■ Einfuhrung von Objekten, welche bestimmte Teile der
Applikation nachladen (ahnlich wie externe Programme zur
Programmausfuhrung)
■ Bei Malware haufiger Einsatz von Stager/Dropper
Security for Systems Engineering SS20 | Sichere Programmierung
Code Encryption – Am Beispiel von Java VM
44 / 57
(Vergleiche http://www.hit.bme.hu/~buttyan/courses/BMEVIHI9367/
Java_security.ppt)
Security for Systems Engineering SS20 | Sichere Programmierung
Code Encryption – Ausblick
45 / 57
Vorteile:
■ Code vor Manipulation geschutzt
■ Dekompilieren nicht moglich
Nachteile:
■ Lediglich der Zugang zum Code wird erschwert
■ Keine Garantie, dass der Code sicher ist
■ Geschwindigkeitsverlust beim Programmstart
■ Kaum eingesetzt
Security for Systems Engineering SS20 | Sichere Programmierung
Code Signing – Motivation
46 / 57
■ Integritat der Applikation
■ Verhindern von Manipulationen
■ Authentizitat der Applikation
■ Eigentumer des Codes festlegen
■ Rechte Management, Policy (z.B. vertraute Java-Applets durfen auf
das Filesystem zugreifen)
Security for Systems Engineering SS20 | Sichere Programmierung
Code Signing – Anwendungsbeispiel Windows 10 VTL
47 / 57
Virtual Trust Levels (VLTs) - Grundlage virtueller
Sicherheitsmechanismen in Windows 10
(Vergleiche https://docs.microsoft.com/en-us/windows/desktop/
procthread/isolated-user-mode--ium--processes)
Security for Systems Engineering SS20 | Sichere Programmierung
Code Signing – How NOT to do
48 / 57
15.01.2019 – Microsoft Windows keeps the Authenticode
signature valid after appending any content to the end of
Windows Installer (.MSI) files signed by any software
developer. This behaviour can be exploited by attackers to
bypass some security solutions that rely on Microsoft Windows
code signing to decide if files are trusted.
. . .
Microsoft has decided that it will not be fixing this issue in
the current versions of Windows and agreed we are able to
blog about this case and our findings publicly.
(Vergleiche https://blog.virustotal.com/2019/01/
distribution-of-malicious-jar-appended.html)
Security for Systems Engineering SS20 | Sichere Programmierung
Code Signing – Ausblick
49 / 57
Vorteile:
■ Authentizitat der Applikation sichergestellt
■ Modifikationen der Applikation schnell und einfach feststellbar
■ Gangige Praxis
Nachteile:
■ Keine Garantie fur fehlerfreien Code
■ Kein Schutz vor Dekompilieren
■ Kein Schutz vor Modifikationen des Benutzers
Security for Systems Engineering SS20 | Sichere Programmierung
Encrypted Configuration – Einfuhrung
50 / 57
Angriffsziele
■ Informationen sammeln (z.B. Passworter, Benutzernamen, URLs)
■ Konfigurationen manipulieren (z.B. Policy, Plugins, konfigurierte
Klassen)
Motivation
■ Konfigurationen enthalten schutzenswerte Daten (z.B.
Datenbankanbindungen)
■ Konfiguration vor Modifikationen schutzen
Security for Systems Engineering SS20 | Sichere Programmierung
Encrypted Configuration – Beispiel Jasypt
51 / 57
■ Java Bibliothek:
http://www.jasypt.org/encrypting-configuration.html
■ Teilweise verschlusselte Properties
Erstellung des Property-Files:
> en c r y p t . sh i n pu t=po s t g r e s password=j a s y p t
−−−−ENVIRONMENT−−−−−−−−−−−−−−−−−
Runtime : Sun Mic rosys tems I n c . Java HotSpot (TM) C l i e n t VM 17.1−b03
−−−−ARGUMENTS−−−−−−−−−−−−−−−−−−−
i n pu t : p o s t g r e s
password : j a s y p t
−−−−OUTPUT−−−−−−−−−−−−−−−−−−−−−−
G6N718UuyPE5bHyWKyuLQSm02auQPUtm
Security for Systems Engineering SS20 | Sichere Programmierung
Encrypted Configuration – Beispiel Jasypt
52 / 57
Property-Datei:
da t a s ou r c e . d r i v e r=com . mysql . j db c . D r i v e r
d a t a s ou r c e . u r l=j dbc : mysql : // l o c a l h o s t / r e p o r t s d b
da t a s ou r c e . username=r e p o r t sU s e r
d a t a s ou r c e . password=ENC(G6N718UuyPE5bHyWKyuLQSm02auQPUtm)
Zugriff in Java:
StandardPBEStr ingEncrypto r e n c r y p t o r = new StandardPBEStr ingEncrypto r ( ) ;
e n c r y p t o r . se tPassword ( ” j a s y p t ” ) ;
P r o p e r t i e s p rops = new En c r y p t a b l e P r o p e r t i e s ( e n c r y p t o r ) ;
p rops . l o ad (new F i l e I n p u t S t r e am ( ”/path / to /my/ c o n f i g u r a t i o n . p r o p e r t i e s ” ) ) ;
S t r i n g datasourceUse rname = props . g e tP r op e r t y ( ” da t a s ou r c e . username” ) ;
S t r i n g da ta sou rcePas swo rd = props . g e tP r op e r t y ( ” da t a s ou r c e . password” ) ;
Security for Systems Engineering SS20 | Sichere Programmierung
Encrypted Configuration – Ausblick
53 / 57
■ Erschwert die Manipulation der Konfigurationsdateien
■ Zugriff auf Konfigurationsinhalt beschrankt
■ Wartung der Konfigurationsdateien aufwandiger (z.B. Neuer
Schlussel, Werte andern, . . . )
■ Kein Schutz vor Debugging
■ Aufbewahrung des Schlussels?
Security for Systems Engineering SS20 | Sichere Programmierung
Zusammenfassung
54 / 57
■ Sicherheit muss beim gesamten Softwareentwicklungsprozess
beachtet werden
■ Verwendung von Best-Practice, Standards, Richtlinien bei der
Implementierung
■ Weitere Schutzmechanismen nach Abschluss der Applikation
notwendig
■ Code Obfuscation gegen Reverse Engineering
■ Code Signing, um Programm Integritat sicher zustellen
■ Verschlusselte Konfigurationen zum Schutz vertraulicher Daten
Security for Systems Engineering SS20 | Sichere Programmierung
Tools
55 / 57
Decompiler:
■ JD – Java Decompiler (http://jd.benow.ca/)
■ JAD – Java Decompiler (https://www.varaneckas.com/jad)
■ JetBrains – .Net Decompile (https://www.jetbrains.com/
decompiler)
Obfuscator:
■ Proguard – Java Obfuscator (https://www.guardsquare.com/en/
proguard)
■ Eazfuscator – .Net Obfuscator (http://www.foss.kharkov.ua/
g1/projects/eazfuscator/dotnet/Default.aspx)
Security for Systems Engineering SS20 | Sichere Programmierung
Literatur/Quellen
56 / 57
■ https://www.securecoding.cert.org/
■ https://www.owasp.org/
■ Official (ISC)2 Guide to the CSSLP, Mano Paul, 2011
■ Software Security: Building Security In, McGraw, 2006
■ JStill: mostly static detection of obfuscated malicious JavaScript
code, Xu, 2013
■ Preserving the Exception Handling Design Rules in Software Product
Line Context: A Practical Approach, Junior, 2011
■ Defending against Cross-Site Scripting Attacks, Shar, 2012
■ An Automatic Mechanism for Sanitizing Malicious Injection, Lin,
2008
■ Slides basieren auf Vorversionen nicht genannter ESSE-KollegInnen
INSO – Industrial Software
Institut fur Information Systems Engineering | Fakultat fur Informatik | Technische Universitat Wien
Vielen Dank!
https://security.inso.tuwien.ac.at/