CNS Lecture 13

In the news CNS Lecture 13 Microsoft workstation server buffer overflow Microsoft XML core services remote code execution Network defenses Microsoft agent buffer overflow IPsec WinZip remote code execution Virtual Private Networks (VPNs) Wireless security

Kerberos Trusted systems Secure OS

CNS Lecture 13 - 2

Network security You are here …

Attacks & Defenses Cryptography Applied crypto VULNERABILITIES COUNTERMEASURES • denial of service • disable denial of service disable • Risk assessment •Random numbers •SSH – ICMP smurf, redirects, unreachable • configure properly – SYN flooding • xinetdxinetd,, tcpwrappers • Viruses – frag, teardrop – filters (allow, deny) •Hash functions •PGP • • Unix security impersonationimpersonation – audit and alarm – host rename (LAN) • filtering portmap MD5, SHA,RIPEMD • • S/Mime – DNS • application filtering ((securelibsecurelibsecurelib)))) authentication – source routing • patches • Network security •Classical + stego •SSL • Session capture/modification • scanners ((NessusNessusNessus,, ISS) – TCP seq number guessing • Firewalls,vpn,IPsec,IDS firewalls •Number theory •Kerberos – TCP hijacking • intusionintusion detection & response • Forensics – sniffing • encryption, virtual private networks ((VPNsVPNsVPNs)))) • • • Server/application attacks Symmetric key IPsec – application flooding (ftp,mail,echo) – buffer overflows DES, RijndaelRijndael,, RC5 •Crypto APIs – Software bugs •Public key •Secure coding

RSA, DSA, DD----H,ECCH,ECC CNS Lecture 13 - 3 CNS Lecture 13 - 4

Where to encrypt? Internet protocol (IP) link layer •encrypting modem, NIC (wireless) •transparent,fast Is IP secure? •suitable for private net •protects only one link (pt-to-pt) •info may be exposed in OS • integrity ------checksums? network/transport layer •swIPe, IPv6(IPsec) • can you trust the source address? •transparent • privacy? •selectable (policy) •appl./host/net keying • IP security option (RFC 760) •works over public net – •virtual private network (VPN) military security model: subject/object labels •system layer: encrypting file systems (EFS/CFS) –label each IP datagram (secret, top secret, unclassified) application layer –IP stack and routers enforce access controls •end-to-end over public net •custom applications (PGP, ssh, ssl) –only effective in very controlled environment •intrusive, but flexible •API for application development

CNS Lecture 13 - 5 CNS Lecture 13 - 6

1 IP header IP security option RFC 760 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 This option provides a way for DoD hosts to send security and TCC (closed user groups) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameters through networks whose transport leader does not contain fields for this information . |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +------+------+------+------+ | Identification |Flags| Fragment Offset | |00000010|00000100|000000SS | TCC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +------+------+------+------+ Type=2 Length=4 | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security: 2 bits | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Specifies one of 4 levels of security | Destination Address | 11-top secret +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10-secret | OPTIONAL Options | Padding | 01-confidential 00-unclassified +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transmission Control Code: 8 bits IPv4 Header Format Provides a means to compartmentalize traffic and define controlled communities of interest Protocols: 1 ICMP 6 TCP 17 UDP 50 ESP 51 AH among subscribers.

But the IP header is easliy forged!

CNS Lecture 13 - 7 CNS Lecture 13 - 8

TCP keyed-MD5 option IPsec – new IP security headers

• RFC 2385 (BGP, LDP, MSDP) • RFC's for IPsec (v4 and v6) IETF IPsec RFC’s –Authenticate routing protocols • specifies implementation RFC2406 ESP • Include a keyedkeyed----MD5MD5 checksum in TCP option field • authenticated packets RFC2402 AH –Each TCP segment carries keyed checksum –prevents spoofed source addresses RFC2104 HMAC –Implemented in kernel • encrypted packets (transport or tunnel) RFC2412 Oakley –prevents sniffing • Limited deployment: Cisco/Juniper routers, FreeBSD/FreeBSD/OpeOpenBSDnBSD RFC2408 ISAKMP • does not specify policy • setsockoptsetsockopt()() to enable and set key TCP_MD5SIG RFC2409 IKE • now includes key management • Probably better to use HMAC as part of “““application“application packetpacket””””or RFC3715 IPsec and NAT • could use on a host use secure transport (SSL, IPsecIPsec)))) • could use on a router (tunnels)

CNS Lecture 13 - 9 CNS Lecture 13 - 10

IPsec IPsec services

• IPIP protos 50 and 51 for IPv4 • Access control • authenticated (51) and/or • Connectionless integrity encrypted (50) datagrams • Data origin authentication • system manager sets "policy" • Rejection of replayed packets • no changes to application (or • Confidentiality (encryption) optional) • key management (IKE) • can tunnel IP datagrams(VPN) can tunnel IP datagrams (VPN) Encryption without authentication is useless • implementationsimplementations availableavailable • US export controls limiting

CNS Lecture 13 - 11 CNS Lecture 13 - 12

2 IPsec protocol Security Association (SA)

• Establish a security association in each direction • sender/receiver security info –negotiate parameters/algorithms • SA for each direction –establish a secret (session key) –authenticate • maintained by kernel –not unlike ssh/ssl • identify by SPI (handle) and destination • keyed hashes (md5/sha/tiger) HMAC • specifies • public keys (RSA/DSA) or prepre----sharedshared secret – • block encryption encryption key, IV, algorithm (DES, 3DES,CAST, Blowfish,AES) –AES/DES/3DES/blowfish/CAST/IDEA/RC5 –authentication algorithm (MD5, SHA) • DiffieDiffie----HellmanHellman (mod p or ECC) –key lifetimes • tunnel and transport mode –SA lifetime • Requires modifications to OS!OS ! Requires modifications to OS !! –security labels

CNS Lecture 13 - 13 CNS Lecture 13 - 14

SA authentication

/* Security association data for IP Security */ struct key_secassoc { • negotiate u_int8 len; /* Length of the data (for radix) */ u_int8 type; /* Type of association */ • MD5/SHA HMAC (keyed) u_int8 state; /* State of the association */ u_int8 label; /* Sensitivity label (unused) */ • calculated over nonnon----changingchanging fields of IP packet u_int32 spi; /* SPI */ u_int8 keylen; /* Key length */ –headers (IP and TCP/ UDP) and user data u_int8 ivlen; /* Initialization vector length */ u_int8 algorithm; /* Algorithm switch index */ –NAT causes problems (IP source address changes) u_int8 lifetype; /* Type of lifetime */ caddr_t iv; /* Initialization vector */ dilemma: using source IP address as security token, but hosts have caddr_t key; /* Key */ multiple and changing IP addresses today u_int32 lifetime1; /* Lifetime value 1 */ u_int32 lifetime2; /* Lifetime value 2 */ • IP proto 51 RFC 2402 AH packet SOCKADDR *src; /* Source host address */ SOCKADDR *dst; /* Destination host address */ SOCKADDR *from; /* Originator of association */ u_int32 tp_len; /* Transform private data: length */ void *tp_data; /* Transform private data: data */ };

CNS Lecture 13 - 15 CNS Lecture 13 - 16

AH header Transport and tunnel modes

+------+------+------+ | IPv4 Header | Auth Header | Upper Protocol (e.g. TCP, UDP)| +------+------+------+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | Next header: e.g. TCP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SPI – index into SA table | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tunnel mode has additional header that | | Sequence # -- prevent replay can specify different target (e.g. firewall or VPN) + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication -- HMAC

CNS Lecture 13 - 17 CNS Lecture 13 - 18

3 IPsec encryption ESP header

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Auth. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Coverage | Sequence Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Coverage | | Padding (0-255 bytes) | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication Data (variable) | | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

CNS Lecture 13 - 19 CNS Lecture 13 - 20

ESP transport and tunnel modes IPsec processing

• use SPI from packet to look up SA • authenticate with info from SA • decrypt with info from SA • transport mode protects payload (host based) • tunnel mode protects entire packet –thwart some traffic analysis –used by VPNs (router/firewall)

CNS Lecture 13 - 21 CNS Lecture 13 - 22

Tunnel options IPsec implementations

• many OS vendors have implementations • also shrinkshrink----wrappedwrapped VPN solutions • export is problem • NAT may be a problem (a) End systems • freeware OS patches • (b) Routers/VPN policy: all (transparent to applications) or application request • block connect() tiltiltilSA established (c)(c)(c)a + b (d) VPN + NRL's API (standard ?)

after socket()

setsockopt(fd, SOL_SOCKET, SO_SECURITY_AUTHENTICATION, &auth, len = sizeof(int))

setsockopt(fd, SOL_SOCKET, SO_SECURITY_ENCRYPTION_TRANSPORT, &esptrans, len = sizeof(int)) setsockopt(fd, SOL_SOCKET, SO_SECURITY_ENCRYPTION_NETWORK, &esptrans, len = sizeof(int)) CNS Lecture 13 - 23 CNS Lecture 13 - 24

4 IPsec key management IKE

Oakley RFC2412 Internet Key Exchange (IKE) • key exchange protocol • manual keying or automatic key establishment –speed vs more secure • proposals (SKIP, ISAKMP, PhoturisPhoturis)))) –id vs anonymity – • SKIP new vs re-key • DiffieDiffie----HellmanHellman with authentication (5 groups: 3 mod exp, 2 ECC) – light-weight authenticate with signature, or public key encryption, or prepre----sharedshared secret –in-band • cookies to thwart DoS ------MD5(IP srcsrcsrc,src , IP dstdst,, ports, mysecret ))) –Diffie-Hellman (signed public keys) • nonces to thwart replay (pseudo(pseudo----randomrandom number) • IKE (ISAKMP/Oakley) RFC2409 • Simple encoding of BIG integers (32(32----bit length, and n 3232----bitbit words, MSWF) • provides perfect forward secrecy(PFS) – provides perfect forward secrecy (PFS) out-of band, daemon (UDP port 500) –compromise of a single key will permit access to only –negotiate (Oakley) –data protected by a single key –Diffie-Hellman, public keys – key used to protect transmission of data MUST NOT be used to derive any additional keys

CNS Lecture 13 - 25 CNS Lecture 13 - 26

Aggressive Oakley key exchange IKE – ISAKMP RFC 2408

• protocols and packet formats to establish, modfiymodfiy,, and delete security associations –application on Alice wants to communicate with application on Bob, kernel policy says an SA is needed, Alice's ISAKMP daemon is notified to get an SA with Bob –Negotiate algorithms, key sizes, type of association • phase I ------two ISAKMP peers (daemons) establish a security association (SA) • phase II ------negotiate and establish SA for requesting applicationapplication (((IPsec(IPsecIPsec)))) • packet formats are chain of payloads The DD----HH calculation is CPUCPU----intensive.intensive.intensive. TheThe cookiescookies provideprovide antianti-anti---clogging,clogging, so Mallory • IKE is Oakley plus ISAKMP cancancan’can ’’’tt send random D-D ---HH values and make Bob do DD----HH calculations. Above, I does DD---- H after step 2, R does DD----HH after final step.

CNS Lecture 13 - 27 CNS Lecture 13 - 28

ISAKMP formats ISAKMP payloads

CNS Lecture 13 - 29 CNS Lecture 13 - 30

5 ISAKMP exchanges The IPsec dance on the wire (tcpdump) •VPN client requesting secure tunnel (w/ shared secret) •IKEIKE onon UDPUDP portport 500500 •Encrypted IPsecIPsec,IPsec , IP proto 50

06:52:00.852251 205.138.57.223.1147 > 192.31.96.188.500: udp 300 06:52:02.791434 192.31.96.188.500 > 205.138.57.223.1147: udp 244 06:52:02.791513 192.31.96.188.500 > 205.138.57.223.1147: udp 244 06:52:05.081347 205.138.57.223.1147 > 192.31.96.188.500: udp 48 06:52:05.083159 192.31.96.188.500 > 205.138.57.223.1147: udp 404 06:52:05.083250 192.31.96.188.500 > 205.138.57.223.1147: udp 404 06:52:05.226289 205.138.57.223.1147 > 192.31.96.188.500: udp 180 06:52:05.237861 192.31.96.188.500 > 205.138.57.223.1147: udp 164 06:52:05.237941 192.31.96.188.500 > 205.138.57.223.1147: udp 164 06:53:40.553207 205.138.57.223 > 192.31.96.188: ip-proto-50 100 06:53:40.555380 192.31.96.188 > 205.138.57.223: ip-proto-50 84 (DF) 06:53:40.555452 192.31.96.188 > 205.138.57.223: ip-proto-50 84 (DF) 06:53:40.648533 205.138.57.223 > 192.31.96.188: ip-proto-50 76 06:53:40.679228 205.138.57.223 > 192.31.96.188: ip-proto-50 148 06:53:40.713540 192.31.96.188 > 205.138.57.223: ip-proto-50 76 (DF) 06:53:40.713605 192.31.96.188 > 205.138.57.223: ip-proto-50 76 (DF)

CNS Lecture 13 - 31 CNS Lecture 13 - 32

Virtual Private Networks VPNs

• Tunneling traffic over the Internet Components Criteria – Initially adhoc solutions (PPTP) – Most now based on IPsec and may be • encrypting boxes/software • platforms, interoperability interoperable – VPN enterprise routers • proprietary or open ((IPsecIPsecIPsec)IPsec ))) • Alternative: leased lines (plus – VPN client software • ease of use encryption) or remote dialdial----inininin • maybe VPN server hardware encryption • strength of security • construct encrypted tunnels over the • total isolation from public net, • performance (server bottleneck?) InternetInternet or firewalls too • mobile user support • routerrouter----tunnelstunnels and standalone clients • key server • ease of management (key mgt) (roaming) • network address translation (NAT) • use for internal privacy too What about security of remote client? – Both client and host NAT support • clients for linuxlinux,linux , macmac,, win* home machine compromised and now its • Scalability (active sessions) tunneled in • no changes to applications • exportable youyouyou’you ’’’veve bypassed enterprise IDS and • Cost (free clients?) • network address translation(NAT) firewall – need another IDS for VPN makes client appear like its on local net

CNS Lecture 13 - 33 CNS Lecture 13 - 34

C:\WINNT\system32>tracert thistle.csm.ornl.gov Tracing route to thistle.csm.ornl.gov [160.91.212.74] over a maximum of 30 hops: 1 10 ms 20 ms 10 ms 10.118.32.1 VPN example – remote user VPN example 2 10 ms 20 ms 20 ms 172.30.34.17 3 10 ms 20 ms 10 ms 172.30.34.58 4 10 ms 10 ms 21 ms 68.47.160.50 5 10 ms 20 ms 20 ms 12.118.120.101 6 10 ms 31 ms 20 ms tbr2-p013901.attga.ip.att.net [12.123.21.142] Before 7 30 ms 40 ms 40 ms 12.122.10.138 • Client connects to Internet 8 40 ms 40 ms 50 ms tbr2-cl7.cgcil.ip.att.net [12.122.10.45] 9 40 ms 40 ms 50 ms gbr2-p40.cgcil.ip.att.net [12.122.11.54] After 10 40 ms 40 ms 40 ms gr1-p3110.cgcil.ip.att.net [12.123.5.5] • Click on VPN icon 11 40 ms 41 ms 50 ms aads-att.es.net [198.124.216.21] 12 40 ms 40 ms 40 ms chicr1-ge0-chirt1.es.net [134.55.209.189] • Login 13 90 ms 70 ms 60 ms aoacr1-oc192-chicr1.es.net [134.55.209.58] 14 70 ms 80 ms 70 ms dccr1-oc48-aoacr1.es.net [134.55.209.62] • 15 80 ms 81 ms 80 ms atlcr1-oc48-dccr1.es.net [134.55.209.66] Laptop appears as a new IP address 16 90 ms 80 ms 91 ms ornl-atlcr1.es.net [134.55.208.62] on enterprise network 17 100 ms 90 ms 90 ms orgwy.ornl.gov [192.31.96.225] C:\WINNT\system32>tracert thistle.csm.ornl.gov Tracing route –Can access internal file shares to thistle.csm.ornl.gov [160.91.212.74] over a maximum of 30 – hops: Access internal-only web services 1 120 ms 90 ms 100 ms ornlvpn.ens.ornl.gov [192.31.96.190] etc. •Connection is made to enterprise 2 * * * Request timed out. –No changes to applications VPN server, e.g. port 443 3 100 ms 90 ms 90 ms swgecsb-1.ens.ornl.gov [160.91.0.2] •IPsec SA established (encrypted 4 91 ms 90 ms 90 ms thistle.csm.ornl.gov [160.91.212.74] tunnel) •User logs in •Routing tables on client adjusted enterprise traffic goes thru the tunnel

CNS Lecture 13 - 35 CNS Lecture 13 - 36

6 VPN establishment on the wire (ethereal) OpenVPN openvpn.net

• Open source solution to VPN (windows/(windows/linuxlinuxlinux/*/*/*/*bsdbsdbsdbsd)))) • Authenticate with shared secret or public key ((opensopensslopenssl)sl ))) • Tunnel IP or ether frames over UDP or TCP • Operates as useruser----spacespace daemon (doesn(doesn’’’’tt use IPsecIPsec,, no OS modsmods)))) • Establishing a tunnel (a little routing/device trickery) –Client connects to server daemon and authenticates –New subnet addresses (temp) negotiated for tunnel endpoints –Tunnel provides secure (encrypted/authenticated) path –Client/server can use tunnel for NFS/rlogin/print etc.( rlogin 10.0.0.3 )

private IP addresses 10.0.0.0 136.14.201.5 104.16.22.6 server internetinternet client 172.16.0.0 192.168.0.0 10.0.0.3 10.0.0.4 CNS Lecture 13 - 37 CNS Lecture 13 - 38

OpenVPN vs IPsec VPNs PPTP

• IPsecIPsec VPNs • OpenVPN • MicrosoftMicrosoft’’’’ss PointPoint----totototo----PointPoint Tunneling Protocol for VPN ((’’’’94)94) –Complex (SA’s, IKE) –/+ Can attach from any host –Windows 95, 98, NT (Nice Try) –Kernel support or mods to IP + operates at user level • DonDon’’’’tt need no standards or industry review! Invented ththeireir own: –Costly +based on SSL –Authentication protocol (broken) –Early problems with NAT - doesn’t scale –Hash function (weak) + enterprise implementations –Key generation algorithm higher performance –Used a known encryption algorithm, but effective key length reduced scales by user-chosen ASCII passwords SecurID –Plus other implementation bugs • The implementation was badly flawed, some later patches Both provide prepre----sharedshared key or PKI authentication. Both suffer from allowing a foreign host/net into the “““inside“insideinside”inside ””” IPsec uses standard crypto and widely reviewed … probably need IDS/firewalls at VPN border

CNS Lecture 13 - 39 CNS Lecture 13 - 40

wireless Wireless security

•wireless devices: VCR remote, PDA, cell phone, wirelessless etherether

•wireless threats sniffing content user location traffic analysis becoming a node (new/impersonate) becoming a base station replay/inject •wireless defenses jammingjamming ((DoS( DoSDoS)))) spread spectrum authentication encryption at linklink levellevel (LFSR, ECC, RC4) access control list (allowable MAC addresses) •cell phones • wireless protocols: WPA, 802.11i/WEP, GSM, •pdapdapda’pda ’’’ssss CDPD, bluetooth (weak security?), WiMAX •Use IPsecIPsec or application security (ssh/ssl( ssh/sslssh/ssl)) •sensor nets (industrial, military) for endendend-end ---totototo----endend security •IEEEIEEE 802.11802.11 802.15802.15 (WPAN),(WPAN), 802.16802.16 ((WiMAX( WiMAXWiMAX))))

CNS Lecture 13 - 41 CNS Lecture 13 - 42

7 Wireless ethernet security (802.11i) Cellular security

• Wired equivalent privacy (WEP) has some known flaws GSM (invented their cypto ))) –Short IV, CRC, no key mgt. • compress, encrypt • • WPA ((WiFiWiFi protected access) subscriber id module (SIM) provides authentication • challenge/response (A3) –Builds on WEP • A8 generates A5 key • Still uses RC4 • encryption (A5) (broken?) • temporal key integrity protocol TKIP –A5 is stream cipher (3 LFSRs) (2 40 ) – Longer IV (48 instead of 24 bits) A5/2 only 2 161616 –Better message authentication ( • most cell phone security is weak –Key hierarchy instead of single master key –Key refresh/update protocol Link layer encryption applies only between cell tower and your cellc ell –Support for Extensible Authentication Protocols (EAP) phone, landline transmission is NOT encrypted

CNS Lecture 13 - 43 CNS Lecture 13 - 44

Network security kerberos

• trusted, thirdthird----partyparty authentication service • based on secret key, single login/login/signonsignon VULNERABILITIES COUNTERMEASURES • part of MIT's project Athena (public domain), '85 • denial of service • disable • – ICMP smurf, redirects, unreachable • configure properly components: library, data base, authentication daemon, ticketticket----grantinggranting – SYN flooding • xinetdxinetd,, tcpwrappers service, applications – frag, teardrop – filters (allow, deny) • uses authenticators (for users and servers) and tickets • impersonationimpersonation – audit and alarm • provides: – host rename (LAN) • filtering portmap – authenticated messages – DNS • application filtering ((securelibsecurelibsecurelib)))) – safe messages (encrypted checksum) – source routing • patches patches – fully encrypted messages (encrypted telnet) • Session capture • scanners ((NessusNessusNessus,, ISS) – TCP seq number guessing • firewalls – Single sign-on – TCP hijacking • intusionintusion detection & response • needs network time • Server/application attacks • Encryption • uses symmetric encryption (DES) – application flooding (ftp,mail,echo) – Link layer (WEP) • applications must be ""kerberizedkerberizedkerberized““““(security “““added“added onon””””)))) – buffer overflows – Transport layer (IPsec) – Software bugs • virtual private networks (VPNs) • does not trust hosts – Improper configuration – Application layer (ssl, ssh, pgp) • available for most UNIX's, DCE, ONC RPC, AFS/DFS, Windowsindows 2000/X2000/XP2000/X PPP – Just daemons, data files, and applications on top of the OS

CNS Lecture 13 - 45 CNS Lecture 13 - 46

Setting up kerberos Kerberos components

• get source from MIT ((cygnuscygnuscygnus)))) • Key Distribution Center • designate secure authentication server machine (KDC) –Hardened host – maybe slave authentication servers for redundancy – • build applications (r(r----utilities,utilities, login, ftp, pop, klogin,kinitklogin,kinit,, klistklist,, kadminkadmin)))) Data base of user and server keys encrypted with master secret – PAM (plugable authentication modules) may make it easier –Performs Authentication Service (AS) • register principals (user, servers) –Performs Ticket Granting Service (TGS) • data base (principal/password) is encrypted with master key –Alternate/secondary KDC’s • installinstall eacheach server'sserver's keykey onon serverserver • /etc/servtab – prevents host/IP impersonation Servers • clientclient----onlyonly easy, (PC/MAC versions, linuxlinux)linux ))) –Server software (print spooler, login, ftp) on various machines must – Can’t do RSA-ssh ‘cause host needs your password to do kinit be registered and have server keys securely stored on the machine – Now there is a kerberized ssh • Users – also a public-key version of Kerberos login, also smart card support –Account and Kerberos password

CNS Lecture 13 - 47 CNS Lecture 13 - 48

8 kerberos Kerberos exchanges

goals

• authentication of client to server • optional authentication of server to client • secure exchange of random session keykeykey

• Avoids plainplain----texttext passwords, permits singlesingle----signonsignon • NeedhamNeedham----SchroederSchroeder authentication Ticket Authentication Service (AS) Authenticator Ticket Granting Service (TGS) IP address (AD) Client (C) Time stamp (TS) Server (V) lifetime

Key (K) Kctgs and Kcv are random

CNS Lecture 13 - 49 CNS Lecture 13 - 50

Authentication protocols Kerberos credentials

• See lecture 3, need confidentiality and timeliness authenticator ticket • Authenticators: shared secret and/or public keys name/instance/realm of the client server • Worry about replay attacks timestamp client –Mallory copies a message and replays it later client workstation address • client workstation address –Replay a time-stamped message within the time “window” used only once timestamp –Suppress original message, send it later • generated each time client wants lifetimelifetime session key –Reflect message back to sender to use a service •encrypted with server's key • Replay defenses: • encrypted with server's session – •generated by TGS sequence numbers (bookkeeping problem) keykeykey –timestamp (hard to keep distributed clocks sync’d, NTP) •good for a single client and – challenge/response (nonce) (hard for connectionless transactions) • inhibits replay server • Kerberos (Needham/Schroeder) uses timestamps • shows that the sender of the •TGSTGS’’’’ssssvoucher for the ticket is the same party to identity of the requestor of whom the ticket was issued the service

CNS Lecture 13 - 51 CNS Lecture 13 - 52

Kerberos session kerberizing

• you can add Kerberos calls to your own client/servers • user logs in, kerberized loginlogin sendssends > toto KKerberosKerberos AS • Kerberos AS generates random session key (SK) and replies • need Kerberos data base, authenticator, ticketticket----grantinggranting server,

{< SK {TGS} , {client name,WS addraddr,, TGSTGS----name,name, SK {TGS} }K}K}K {TGS} >}>}>}K>} KKKccc and administrative programs • On client, user's password KKK isis usedused toto decryptdecrypt messagemessage ccc • can use kloginklogin,, but better if you have kerberized BSD utilities • To get a ticket for another service, client sends a messagemessage toto TTGS,T GS, with authenticator (encrypted with SK {TGS} ), the sealed TGS ticket, and the server name • Kerberos calls added to login, rr----utilities,utilities, NFS • TGS generates a random session key SKSKSK and replies with {server{server}}}} • “““rlogin“rlogin ---x-x “““sets up encrypted session, every packet is encrypted {< SK {server} , {client name,WS addr,severaddr,sever,, SK {server} } {server} }all encrypted with SK {TGS} • the client can send a request to the server consistinging ofof thethe seserver'sse rver's encrypted ticket, • Kerberos API (later) and an authenticator encrypted with SK {server} • the server can decode the ticket and get the session key SK {server} and decode and verify the client (check for replay)

• server adds 1 to timestamp and sends to client encrypted with SK {server} (mutual authentication)

CNS Lecture 13 - 53 CNS Lecture 13 - 54

9 Kerberos v4 SERVICES Kerberos v5 kerberos 88/udp kdc # Kerberos authentication--udp kerberos 88/tcp kdc • support of DCE # Kerberos authentication--tcp • more functionality • typical client/server application klogin 543/tcp # Kerberos authenticated rlogin • new encodings • kshell 544/tcp cmd – librarylibrary requests,requests, justjust UDPUDP packetspackets # and remote shell ASN.1 data representation (v4: bytebyte----orderorder bit) • Kerberos servers listening on wellwell----knownknown kerberos-adm 749/tcp – address encoding (v4: IPv4 only) # Kerberos 5 admin/changepw – stronger random numbers (yarrow with /dev/random) ports (88) kerberos-adm 749/udp stronger random numbers (yarrow with /dev/random) # Kerberos 5 admin/changepw – AS and TGS exchanges include a nonce instead of timestamp • encryption: modified DES CBC kerberos-sec 750/udp – # Kerberos authentication--udp selectable encryption/MAC –PCBC has weaknesses kerberos-sec 750/tcp • MAC: DES of md5/md4/DESmd5/md4/DES----CBCCBC # Kerberos authentication--tcp • encryption+MAC:encryption +MAC: DES + md4/md5/crcmd4/md5/ crc • MAC: Juneman checksum on (key, msgmsg)))) kerberos_master 751/udp encryption +MAC: DES + md4/md5/ crccrc # Kerberos authentication • principal names multicomponent • kerberos_master 751/tcp Random numbers (session keys) – v4 was name/instance/realm (40 max) srandom(time.tv_usec ^ time.tv_sec ^ # Kerberos authentication getpid() ^ gethostid() ^ counter++ ) krb5_prop 754/tcp – v5 name/realm # Kerberos slave propagation • key = random() kpop 1109/tcp new ticket flags (delegation) and longer lifetimes # Pop with Kerberos • v5 will handle v4 requests eklogin 2105/tcp • # Kerberos encrypted rlogin More recently: krb524 4444/tcp – public key for initial authentication ((DoDDoD using smart card to hold public key, need PIN) # Kerberos 5 to 4 ticket xlator – oneoneone-one ---timetime password support, kerberized sshsshssh – Kerberos v5 RFC1510

CNS Lecture 13 - 55 CNS Lecture 13 - 56

kerberos v5 random numbers v5 tickets

• KDC generates random session keys • yarrow using /dev/random and packet interarrivalinterarrival times for random input • proxiable TGT ------can be used to request tickets for a different netnet – Initial seed from master key (and other realm keys if available) address (Alice can let Bob use her printer) • yarrow keeps a fast and slow pool of random bits mixed with SHASHA----1111 – Reseed and new key as entropy grows from random inputs • forwardable TGT ------can be presented to a remote TGS • lifetimes –longer lifetimes (v4: 21 hrs) (v5: start/end) –renewable (by KDC) • Output bits are generated from 3DES using a key from the fast popoolololol –postdated (good a week from now for 2 hrs, KDC clears INVALID flag)

• Wipes memory and saves pool to file on exit

CNS Lecture 13 - 57 CNS Lecture 13 - 58

Kerberos cross-realm authentication Why not Kerberos?

• every network service must be modified • Kerberos server must be physically secure with hardened OS • export restrictions • offoffoff-off ---linelineline passwordpassword attackattack onon messagemessage fromfrom KDCKDC toto clientclient • ifif passwordpassword isis disclosed,disclosed, eavesdroppereavesdropper cancan decryptdecrypt other tickets and spoof servers and users • (need kerberoskerberos----ableable client)

Still, better than anything else. • also used in DCE and Windows XP • part of DoD singlesingle- ---signonsignonsignon/common/common access card public key (on smart card) login to kerberos

CNS Lecture 13 - 59 CNS Lecture 13 - 60

10 Other variations Secure operating systems

SESAME • design issues –hardware features • European project – • based on Kerberos OS features • uses public key –design principles –ticket encrypted with user's public key • Examples –AS stores only public keys, not as vulnerable –Multics, TMACH, SELinux, OpenBSD • evaluation methods CORBA ------technology for distributed applications –Orange book, common criteria, FIPS

• set of specs • Why secure applications are not enough. NSA ------really need • object request broker (ORB) secure OS (required reading) • security spec released '95 • authentication, access control, audit, message protection

CNS Lecture 13 - 61 CNS Lecture 13 - 62

features for security Trusted platform module (TPM)

• WindowWindow’’’’ss Vista, Linux?, coming to MAC OS Hardware OS • Attached processor for storing keys, doing crypto, RNG • privileged state •user authentication • Tamper resistant •memory protection • privileged instructions • Authenticate user/system (digital rights) •file/device protection • • memory protection (RO,NX) •permit sharing but not hogging Secure startup, trusted OS query, disk encryption (stolen laptop) • timer interrupt •provide integrity and consistency laptop) • system call (trap/SVC) •scheduling • Code signing • hardware RNG ? •interprocess communication • Trusted computing group “““standard“standardstandard”””” • TPM? • Number of vendors making TPMs

CNS Lecture 13 - 63 CNS Lecture 13 - 64

Secure OS design Access control

• design security in from the beginning • access matrix (subjects/objects/access) • (subjects/objects/access) define access rules for subjects/objects and allowable info flows • by objects: access control list (ACL), (security policy) who can do what to this object, UNIX file • Label objects (top secret, secret, unclassified, readad----only)only) permissions • by subjects: capability tickets ------what -- what • leastleast privilegeprivilege (fine(fine grained)grained) this subject/user has access to • small kernel (TCB) • maintained by OS • separation (temporal, logical, cryptographic), layers or compartmentscompart ments • rolerole----basedbased access control (RBAC) – • complete mediation ------every access checked Each process/user has a “role” • Doctor/nurse/administrator –Mandatory access control (MAC) – A user may have several roles • default is deny – Config files specify to which domains • ease of use a role has access – Can associate a role with a “method” • apply software engineering principles – Easy to change privileges of a role – Principal of least privilege

CNS Lecture 13 - 65 CNS Lecture 13 - 66

11 TCB Secure OS’s

Trusted Computing Base • Multics • reference monitor • Scomp • implements/enforcesimplements/enforces securitysecurity • KSOS (3(3----layer,layer, PDPPDP----11)11)11)11) • authentication and access control • kernelized VM/370 –No read-up or write-down –Labeled objects, user clearance • secure UNIX/Linux –“need to know” role-based –UCLA Secure UNIX • tamper resistant –TMACH/DTOS • can't be bypassed –CMWs, NetTop • small/simple, correctly implemented –bastille Linux, NSA secure Linux (SELinux), Grsecurity • verifiable ? • OpenBSD

CNS Lecture 13 - 67 CNS Lecture 13 - 68

multics UCLA secure UNIX (1979)

• B2 multilevel secure OS (mid 60's) • three layers • multilayered (rings) • user/supervisor/kernel (PDP(PDP----11)11)11)11) • extension of 2 layer systems • small secure kernel • upper rings implemented in software (processor: GE645) • kernel interface layer • kernel, ring 0 • application layer • "traps" for requesting ring services (gate) • all security functions in one place • uses capabilities • capability list maintained by kernel • segmented address space • • design review (PL/I) objects: processes, pages, devices • need more hardware assist (ring(ring----crossing)crossing)

CNS Lecture 13 - 69 CNS Lecture 13 - 70

TMACH TMACH security

Trusted MACH TMACH goals • labeledlabeled objectsobjects (military(military model)model) • based on CMU's MACH kernel • B3 security ------data integrity • user clearance • with OSF UNIX personality • portable to many platforms • mandatory access control • • sponsored by DARPA and TIS • competitive performance access mediated by reference monitor • auditing • available for 486/586 • extensible • ACL's • UNIX personality • trusted path for user authentication • subdivided privileges (least privilege) • task communication (ports) TMACH architecture • covert channel analysis kernel, small, secure • trusted startup and recovery •layering, modularity, abstraction, data hiding • security model (Bell and LaPadulaLaPadula)))) •TCB servers, multimulti----levellevel secure servers •nonnonnon-non ---TCBTCB code, the OS user interface

CNS Lecture 13 - 71 CNS Lecture 13 - 72

12 Secure Linux Securing the Linux kernel

• NSANSA’’’’ssssSecuritySecurity- ---EnhancedEnhanced linuxlinux • Need lots of “““hooks“hookshooks””””in kernel source to check permissions –Mandatory access control (type-enforcement and RBAC) – … –Separation of information based on confidentiality and integrity File open/read/write, process create, sockets, –Based on Linux Security Modules (LSM) –LSM model (modules) SELinux –Latest RedHat/Fedora has SELinux option, file ACL’s, firewalling –Grsecurity others require kernel patches • Hardened linuxlinux –Bastille linux (scripts to harden configuration) • NonNon----trivialtrivial configuration files to establish “““policy“policypolicy”””” –Trustix • Grsecurity has a learning mode to establish what privilegesprivileges a –Engarde Secure Linux process needs –Openwall Linux (Owl) –RSBAC • User roles can be restricted –Grsecurity –You can only read mail (can’t compile) • Support for TPM –Different administrative privileges • Use for bastion hosts and “““external“external serversservers””””(http, dnsdnsdns,dns , login)

CNS Lecture 13 - 73 CNS Lecture 13 - 74

Example ACL Hardening linux

Printer daemon ACL ((GrsecurityGrsecurityGrsecurity)))) Subject /usr/sbin/cupsd o { • Disable net services • Firewall enabled / h • Reduce setuid programs • Enable NTP /etc/cups/certs • Active password mgt/renewal • Enable port scan detector /etc/cubs/certs/0 wcd • Default mask • IncorporateIncorporate StackGuard/PaX /etc/group r • Limit root login locations • Support nono----execexec data areas (MMU) -CAP_ALL +CAP_CHOWN +CAP_DAC_OVERRIDE • Set BIOS password • Auto patch/update bind disabled • Get rid of rr----utilitiesutilities • Immutable/appendImmutable/append filesfiles ((chattr( chattrchattr)))) connect disabled • Login banners • Encrypted file systems } • Remote syslog • SELinux or Grsecurity • More detailed event logging • Configure services to have certain capabilities and access rightrightssss • UserUser----specificspecific //tmptmp areas … read the books • Configure users to be part of certain groups/roles • Principle of least privilege – even if you buffer overflow cupsd …

CNS Lecture 13 - 75 CNS Lecture 13 - 76

OpenBSD Security validation (assurance)

• Most secure of the open source UNIX demonstrate the security of an OS or application or crypto devicdeviceeee • Developed in Canada, so crypto software included –Kerberos v5 • verification –IPsec • penetration analysis –openssh/openssl –test security services –Support for crypto hardware –try to bypass security • ImmutableImmutable andand appendappend-append ---onlyonly files, no writing to /dev//dev/memmem /dev//dev/kmem kmem –tiger team • Actively audit source code lookinglooking forfor vulnerabilitiesvulnerabilitiesvulnerabilities asas wellwell asas timelytimely –demonstrate presence of errors, not absence patches for bugs discovered by “““others“othersothers”””” • informalinformal validationvalidation • Default installation – nonnonnon-non ---esentialesential services disabled –requirements checking • PRNG (/dev/(/dev/srandomsrandomsrandom)) (/dev/random is for hardware RNG) –design and code reviews –module and system testing –certification (Orange Book or itsec or Common Criteria)

CNS Lecture 13 - 77 CNS Lecture 13 - 78

13 DoD certification (historical) Orange book ratings

• D ------minimal (D for DOS) Requirements for a secure OS ORANGE BOOK • C1 ------discretionary • security policy DoD Trusted Computer System Evaluation • C2 ------controlled access • authentication Criteria ('85) • B1 ------labeled labeled • • •hierarchy of requirements B2 ------structured labeling of objects and subjects (D,C1,C2,B1,B2,B3,A1) • B3 ------security domains • accountability (audit logs) •list of security features • A1 ------verified •strength of OS design • assurance (enforce/evaluate) •limit data access (privacy) • Might be able to add features to an OS to qualify for C1C1----B1B1B1B1 • tamper resistant •control data flow •certification service • B2 requires security part of OS design. • documentation •objective assessment B2 requires security part of OS design. • B3/A1 provable model of security

CNS Lecture 13 - 79 CNS Lecture 13 - 80

Ratings Ratings

B1 – labeledlabeled B2 ------structured protection C1 ------discretionary access C2 ------controlled access

•single user access controls • mandatory access controls • test and review of design • memory protection (user vsvsvsOS) (privacy) • principle of least privilege (ACL) principle of least privilege • object access control • labeledlabeled objectsobjects (incl.(incl. devices)devices) • trusted path (user/(user/ttyttyttytty/OS)/OS) •audit logs (tamper • (owner/group/world) labellabel printerprinter outputoutput (mutual authentication) resistant) • prevent readread----upup and writewrite----downdown • security kernel (TCB) • user authentication (password) •object reuse, protect (Bell(Bell----LaPudulaLaPudulaLaPudula)))) • programs must report security level • discretionary access controls memory, files, swap • analysis and testing of design and changes source code •e.g, MVS/ACF2, VMS, DEC • covert channels identified and • penetration testing e.g, MVS/ACF2, VMS, DEC • informalinformal modelmodel ofof securitysecurity policypolicy e.g.,e.g., bandwidth estimated, e.g., Multics • e.g., MVS with RACF UNIX CMW's (compartmentalized mode workstation)

CNS Lecture 13 - 81 CNS Lecture 13 - 82

Covert channels ratings

• ways to reveal info to lower level B3 ------security domains A1 ------formal verification • lowlowlow-low ---bandwidthbandwidth • stronger design • formal, provable security model • difficult to eliminate • ACL supports user denial • toptop----levellevellevel specificationspecification • use memory/file or timing • ACL supports read/write (integrity) • demonstrate spec follows model • existence of a file (bit 0 or 1) • full access control • implementationimplementation consistentconsistent withwith specspec • mode of a file (0 or 1) • active audits (alerts) • formal analysis of covert channels, • e.g., Scomp • high CPU load (0 or 1) penetration resistant • secure startup and crash, e.g., • process name (0 or 1) TMACH (applied for B3) • network connection (0 or 1)

CNS Lecture 13 - 83 CNS Lecture 13 - 84

14 Orange book shortcomings UK’s itsec

• miss one feature, lose rating UK software certification ((’’’’91),91), fastfast----tracktrack assessment, list of certified products • local software invalidate ? Assurance levels ::: • OS patches invalidate ? • E0 – no assurance • mandatory access controls cumbersome • E1 – informal architecture design, some testing, secure dn. • writewrite----upup would allow virus • E2 – penetration tested, audit trail • E3 – source code/drawings, acceptance procedure, rere----testtest NT got a C2 rating (’96) • E4 – formal security model, configuration control BUT epoxy-shut floppy • E5 – independent configuration control no network • E6 – formal architecture description and correlation with design Compaq 386 and testing

CNS Lecture 13 - 85 CNS Lecture 13 - 86

Common Criteria (ISO 15408 ’99) CC functions requirements

Combine US and EU criteria Functional requirementsrequirements:: desired security behavior Assurance requirementsrequirements:: assure claimed security measuresmeasures are effective Assurance levels • EAL1 – functionally tested • EAL2 – structurally tested • EAL3 – methodically tested and check • EAL4 – methodically designed, tested, and reviewed • EAL5 – semisemi----formallyformally designed and test • EAL6 – semisemi----formallyformally verified design and tested • EAL7 – formally verified design and tested

CUPERTINO, Calif. - May 21, 2002 - Symantec Corp. (NASDAQ: SYMC), the world leader in Internet security, today announced that Symantec Enterprise Firewall 7.0 has been awarded Common Criteria Evaluation Assurance Level 4 (EAL4) certification. This prestigious certification assures customers that Symantec Enterprise Firewall has gone through a long and rigorous testing process and conforms to standards sanctioned by the International Standards Organization. TOE – target of evaluation

CNS Lecture 13 - 87 CNS Lecture 13 - 88

CC assurance requirements FIPS 140-1

Crypto module security (hardware, e.g. encryptorsencryptors,, crypto cards) • Level 1 – uses FIPS approved algorithms • Level 2 – tampertamper----evidentevident seals, rolerole----basedbased authentication (C2) • Level 3 – selfself----destructdestruct (zero(zero’’’’ss itself) if tampered with, identity based authentication (B1) • Level 4 – sophisticated tamper detection and zerozero’’’’inginginging,, resist environmental attacks (stir fry), (B2)

The problem of establishing that a program, application, or OS meets any particular security requirement is known to be fundamentally unsolvable!

CNS Lecture 13 - 89 CNS Lecture 13 - 90

15 Next time …

Lectures 1. Risk, viruses Writing secure code 2. UNIX vulnerabilities Crypto API’s 3. Authentication & hashing 4. Random #s classical crypto Secure applications 5. Block ciphers DES, RC5 6. AES, stream ciphers RC4, LFSR 7. MIDTERM 8. Public key crypto RSA, D-H 9. ECC, PKCS, ssh/pgp 10. PKI, SSL 11. Network vulnerabilities 12. Network defenses, IDS, firewalls 13. IPsec, VPN, Kerberos, secure OS 14. Secure coding, crypto APIs 15. review

CS594 project due: December 1

CNS Lecture 13 - 91