Wh What t abou out t th the e sof oftw twar are? e? How - PowerPoint PPT Presentation

Wh What t abou out t th the e sof oftw twar are? e? How many security vulnerabilities are there in the software implementing all this smart grid functionality and the underlying protocols? Erik Poll Radboud University Nijmegen

Moti tivati tion on Security can go wrong on many levels • human factor • organisational issues • authentication solutions • communication protocols • security protocols • cryptography • software • incl. the software implementing the 4 aspects above • hardware • ... Erik Poll Radboud University Nijmegen 2

Moti tivati tion on Security can go wrong on many levels • hu huma man n fac actor tor • organisational issues • authentication solutions • communication protocols • security protocols cryptography • • so softwar are e • incl. the software implementing the 4 aspects above • hardware • ... Erik Poll Radboud University Nijmegen 3

So Softw twar are e (i (in)securi )security ty Software is major source of security problems Software is not the Achilles’ heel of ICT security, but the Achilles’ body Any piece of software that an attacker can provide malicious input to is a risk Regrettable tendency to see this as unavoidable fact of life, with as ‘solutions’ 1. regularly patch the software 2. prevent the bad guys from getting access • air gaps, separate physical networks, secure communication tunnels (eg TLS or IPSEC) but: won’t any reasonably compentent attacker be able to get inside these TLS tunnels? Erik Poll Radboud University Nijmegen 4

La LangSec ngSec (La Langua nguage-theor theoretic etic securit curity) y) Instructive insights into root causes, and bad vs good practices, when it comes to software security. Starting point: note the common pattern in attacks on software incl. buffer overflows, format string attacks, integer overflow, OS command injection, path traversal attacks, SQL injection, HTML injection, XSS, CSRF, database command injection, database function injection, PHP file name injection, LDAP injection, ShellShock, HeartBleed, FREAK, ... 1. attacker crafts some malicious input 2. software goes off the rails processing this, unintentionally providing the attacker weird functionality Like social engineering or hypnosis as attack vector on humans? Erik Poll Radboud University Nijmegen 5

Moral al: : Pr Proce cess ssing ng input put is d s dan anger erous us! Processing involves 1) parsing/lexing 2) interpreting/executing Eg interpreting a string as filename, URL, or email address This relies on some language/format/protocol 1) relies on syntax 2) on semantics Insecure processing of inputs exposes strange functionality that the attacker can abuse & possibly even program. Erik Poll Radboud University Nijmegen 6

Fal allac acy y of clas assi sica cal input put val alidation? tion? Classical input validation: filter or encode harmful characters or, slightly better: only let through harmless characters But: 1. Which characters are harmful (or required!) depends on the language or format. You need context to decide which characters are dangerous. 2. Not only presence of funny characters can cause problems, but als the absence of other characters, or input fields that are too long or too short, ... The proper solution: parse the entire input before any processing Erik Poll Radboud University Nijmegen 7

Tower er of Babel el The Web involves many ny and comple mplex languages & formats HTTP(S), HTML, CSS, javascript, Flash, cookies & FSOs, Ajax & XML, ActiveX, jpeg, mpeg, mp4, png, gif, SilverLight, URLs/URIs, X509 certificates, email addresses, TCP/IP (IPv4 or IPv6), file names, directories, OS commands, SQL, LDAP, JSP, PHP, ASCII, Unicode, UTF-8, ... Erik Poll Radboud University Nijmegen 8

Sam ample e problems lems • Exploits with zero-width fields in JPEG images • Code Red worm exploiting incorrect treatment of ASCII and Unicode chararacters • Different browsers interpreting X509 certificates with multiple Common Names differently • ANS.1 attacks in X509 certificates null terminator in ANS.1 BER encoded string in an X509 Common Name • PKCS#10-tunneled SQL injection SQL command inside a BMPString , UTF8String or UniversalString used as PKCS#10 Subject Name • .... Erik Poll Radboud University Nijmegen 9

Lan angS gSec ec an anti ti- patterns (don’ts) 1. Complex input languages (aka formats, protocols) • length fields in data packets are notorious source of problems 2. Unclearly defined input languages 3. Hand-written parser code which • mixes parsing & interpretation • incrementally parses parts of input, in a piecemeal fashion Aka a shotgun parser All this results in • lots of chances for an attacker to trigger weird behaviour • possibly using parser differentials , ie. differences between implementation of the same language Erik Poll Radboud University Nijmegen 10

LangSec best practices (do’s) 1. precisely & clearly defined input languages, Eg with regular expression or EBNF grammar 2. keep the input language as simple as possible So that ideally equivalence of parsers is decidable. So that you give minimal processing power to attacker. 3. generate parsers 4. complete parsing before processing working with parsed information, not still-to-be-parsed byte sequences or strings 5. for legacy software: put a generated parser in front, to ensure correct & complete parsing before processing? • effectively a language-specific firewall/IPS/IDS 6. use understanding of language for testing, esp. fuzzing Erik Poll Radboud University Nijmegen 11

Erik Poll Radboud University Nijmegen 12

So Some exa xamples mples Payments, GSM, DNP3, TLS

Uninte ntentional ntional ca case se st study: y: co contact tactles ess paymen ents ts • Correctly formatted RFID traffic can crash contactless payment terminals [MSc thesis Jordi van Breekel, 2014] • dual-contact bank cards of two banks misconfigured to accept certain commands over the contactless interface that meant for the contact interface only 14

Case se study: udy: GS GSM GSM is a extremely rich & complicated protocol 15

SMS SM S me messa ssage e fie ields lds Field size Message Type Indicator 2 bit Reject Duplicates 1 bit Validity Period Format 2 bit User Data Header Indicator 1 bit Reply Path 1 bit Message Reference integer Destination Address 2-12 byte Protocol Identifier 1 byte Data Coding Scheme (CDS) 1 byte Validity Period 1 byte/7 bytes User Data Length (UDL) integer User Data depends on CDS and UDL 16

Let’s fuzz! i.e. sending randomly generated, malformed GSM traffic to phones (using a USRP with OpenBTS software) weird traffic [Mulliner et al, SMS of Death ] [Fabian van den Broek, Brinio Hond, Arturo Cedillo Torres , Security Testing of GSM Implementations , Essos 2014] 17

Ca Case se st study: y: GSM SM protoc tocol ol fuzz zzing ng Weird functionality in GSM standard and phones 18

Ca Case se st study: y: GSM SM protoc tocol ol fuzz zzing ng Weird functionality in GSM standard and phones • eg possibility to send faxes (!?) you have a fax! Only way to get rid if this icon; reboot the phone 19

Ca Case se st study: y: GSM SM protoc tocol ol fuzz zzing ng Malformed SMS text messages showing raw memory contents, rather than content of the text message name of Mobile Soccer game shows up inside text message 20

Case Ca se st study: y: GSM SM protoc tocol ol fuzz zzing ng • Lots of success to DoS phones: phones crash, disconnect from the network, or stop accepting calls • Requiring reboot or battery removal to restart, to accept calls again, or to remove weird icons • After reboot, the network would redeliver the SMS if no acknowledgement was sent before crashing, re-crashing phone But: not all our SMS messages could be sent over real network • Surprisingly little correlation between problems and phone brands & firmware versions • how many implementation of the GSM stack does Nokia have? • The scary part: what would happen if we fuzz base stations? (For the Alliander folks here: is CDMA any better?) 21

Ca Case se st study: y: DN DNP3 P3 Robus project by Adam Crain and Christ Sistrunk • wrote a dedicated fuzzer for DNP3 SA • extension of DNP3 with Secure Authentication • revealed > 30 vulnerabilities in products of over a dozen of vendors More info at automatak.com/robus or langsec.org/dnp3 22

Ca Case se st study: y: TLS Many protocols have state • messages are expected to arrive in a particular order • implementations have to keep track of this • by implementing a protocol state machine As well as fuzzing with strange messages we can now also try strange sequences of messages • ie fuzzing the order rather than the content of messages, in different orders than the ‘happy flow’ Using state machine learning we can even automatically infer the protocol state machine by black box testing 23

TLS.. ... accor ording ding to NSS SS implementa lementation tion Comforting to see it is so simple! 24

TLS.. ... accor ording ding to Gn GnuTL TLS 25

TLS.. ... accor ording ding to Op OpenS enSSL SL 26

TLS.. ... accor ording ding to Java a Se Secur ure e So Socket et Ex Exensi sion on 27