Network defences

9. Network defences

Objectives

• To look at some network security measures, focusing in particular on those that are deployed in the Internet and Transport layers
• To discuss some well-known recent vulnerabilities, sin these security measures
• There are measures but by no means they are perfect

Network Security Measures

• Two approaches
  • Block malicious traffic from entering local network - Try to look at traffic as an entry level network and decide whether or not to accept it
  • We allow the traffic to come in, but we protect the legitimate traffic from tampering and information disclosure threats
• Relevant technologies
  • Firewalls
  • TLS- lot more coz its more significant
  • IPsec- brief – alternative and one layer down from TLS

Firewalls

• Traditional idea is that it provides a single choke point for traffic entering or leaving the local network.
  • In this choke point, you can implement some decision making based on some sort of policy
• To block incoming connections other than everything that is necessary to support the services from outside your network.
  • Web server- usually runs on port 80, and you wanna leave this open. And this is why firewalls do nothing for web services!! Coz it has to be open and attackers target this open port to get in.
• Packet filtering – smarter – rather than just blocking, it scans the actual content of the packet – if part of the content seems like it matches the malware, it blocks.
• Circuit level gateway – when TCP connection is attempted – it blocks or let it access. Rather than blocking based on IP address, you look at the host to see whether or not to block.
• Thing we assume is that the firewall itself which is a piece of software running on dedicated hardware – immune to penetration itself.
  • If you break into the firewall, anything is useless

In reality

• For network setup, its hard to have one entry point due to massive connectivity loopholes exist.
• Other thing that happened is that- personal firewall that runs as a part of the OS. Before, we had to have a central firewall. But if individual machines are blocking incoming connections, there’s less requirement for a central firewall.
• Firewalls can’t do everything - limitation
  • No protection from internal threats -it focuses on the outside of the network but is no protection to having privileged access to local network, untrustworthy contractors coming in and etc
  • Can’t block all traffic – if ur running an external webs server you need to keep some server open – port 80 open
  • Firewalls are a software, which has vulnerabilities which can be exploited and was exploited – 2016 Cisco and see Bellovin’s book
• Firewall is no longer a place to spend money

Transport Layer Security (TLS)

• Secure Socket Layer (SSL) \&TLS relationship is that SSL is older that TLS replaces. SSL is deprecated in 2015 not meant to use it. TLS is much more modern implementation.
• Not the same as SSH – diff protocols
• Key tech in web technology – how do we know TLS is used?
  • A: when you see the first part of the URL is https – then its TLS. And this is now the norm.
  • Browsers now warn you with the use of http -50% of top 1 million websites are using https
• Two implementations
  • As part of underlying protocol suite - that sits on top of http, TCP/IP – to add in security features that is absent in those protocols
  • Embedded in specific packages
• Key role in web security!!

TLS in the Protocol Stack

• 
  • IP – it handles the routing of packets
  • TCP – provides byte stream connection
  • http – web protocol
  • TLS – suite of protocol that sits in the middle – the name is misleading and its actually above TCP
  • Several protocols, but we are actually about handshaking TLS and record protocol

TLS Handshake Protocol

• Similar with handshaking between client and server
• But is a web client and web server – but is more complicated than a 3-way handshake coz we gotta do cryptography
• Stages – we are talking in terms of high level, but gotta know how COMPLEX it is – TLS 1.2

  • Side arrow – represents compulsory msgs, Dash arrow – optional msgs

  • Phase 1 – establishing the security capabilities.
    • Client_hello: Client initializes and sends info to server that need to identify the client capabilities.
      • Sends TLS version, nonce (Timestamp + random number), which ciphers and hash functions (ciper suites) it supports and the data compression methods
    • Server_hello: Server responds with server hello
      • Send back a nonce, cipher suite and compression method that it chose from the list client provided.
      • Cipher suite combines cipher and hash function and is specified in decreasing order of preference
      • Can have session id – to shorten the negotiation process by providing previous setup. And refer to the session id to remember what they want
  • Phase 2 – involves certificate
    • Certificate: Server need to send its public key to clients – bc client can use RSA to encrypt stuff to send to server – is a symmetric cipher key which is a session key
      • Before we do all this, we need the public key to be sent in a secure way!! do it by wrapping with certificate and have a trusted third-party to verify and sign for it.
    • Server key exchange: optional – there’s a temporary public key that can be used. Service has RSA signature only key – then server has to create temp RSA key to use this to send public key to the client.
    • Certificate_ request: –server can request from client as well. Trust relationship can be applied to the other way around
    • Server_hello_done: must!! To show that its completed
  • Phase 3 – client has to talk back to the sever.
    • Certificate: Server may have asked for the certificate and client responds with it
    • Client_key_exchange: where we have to negotiate the session key to use for encryption
      • For the session key - Client sends a 48bit value of pre-master secret – server use this value plus 2 nonce form phase 1 to compute shared symmetric key. This premaster secret is supplied in key exchange method, and encrypted using servers public key!!
      • Public key cryptography is only used to exchange session key –for secure exchange
        • RSA isn’t used coz its too slow
      • Session key is random and never reused, and only valid for this session, even if the attacker captures it, it won’t be valid anymore
    • Client_key_verify: additional signature with all preceding handshake messages. Servers way of authenticating that client msg hasn’t been tampered
  • Phase 4
    • Change cipher spec basically, client telling the server that we’ve negotiated everything, and this point on it encrypted using session key and authenticated in HMAC when security essentially starts. Previous was just setting it up
    • Finished client telling server its done.
    • Change_cipher spec & finished Server has to ack this and say that its finished as well
• Compared to TCP’s 3-way handshake – so much more complex!!
  • Q: BUT is complexity a good thing from security standpoint?
    • A: meaning more points of failure
      • This is theoretical and this has to be implemented in the software. If sth goes wrong can have security consequences. All necessary to secure traffic but is complex so there’s more risk/ failure
    • Also, overhead – TCP is already is an overhead. But this adds way more too it.
  • That’s why session id and other shortcut mechanisms are important!!

TLS Records

• Client and server agreed on authentication and negotiated
• 

1. Application data is broken up into pieces (fragments) less than 16k
2. And optional compression – using compression algo that’s been agreed
3. Compressed data can be authenticated using HMAC ­ - using exchanged shared secret, its possible for HMAC to be computed and verified
4. We encrypt! Using the symmetric cipher that’s been agreed and we add the TLS record header
5. Whole thing is packaged as a TCP segment and rest of the network protocols operates the normal way.

Problems

• Its complex – complexity means possibility of going wrong.
  • E.g. Talked about SSL – first implementation in browser Netscape – due to poor use of randomness you could predict what the session key was, and decrypt traffic
  • Android apps, apple’s ios bug, heartbleed, and DROWN
  • DROWN
    • Serious vulnerability that affects HTTPS and other services that rely on SSL and TLS
    • Allows attackers to break the encryption and read or steal sensitive communications.

Android App Problems

• In 2012, 1000/ 13000 apps from the app store serious flaws in the use of SSL/ TLS
• Problem was android api was too easy to use protocol incorrectly
  • Automatically trusting all certs without testing
  • Accept certificates regardless of hostname – too easy to just not check that
• What happened was it was using secure protocol in an insecure way

Apple’s iOS Bug

• Chunk of the source code – relates to computing a SHA 1 hash.
• Issue was how goto statement was being used – is a jump to a labelled chunk
• Idea is we are feeding SHA 1 and update value for hash and feeding more stuff, updating again.
• And finalising the update – we call update couple of times, and thers output has value.
  • Take return values in err and compare to 0. 0 means fine and non 0 indicates other.
  • Capturing the return value and compare with zero – if not 0 we goto fail.
• Copy and paste error – second goto will ALWAYS be called no matter what!! Since it goes to fail, the finalisation will never complete.

Heartbleed (CVE-2014-0160)

• CVE indicator – Common Vulnerability Exposure
• (CVE-2014-0160) - 160 of labelled vulnerable in 2014 –serious vulnerability discovered in openSSL
• Notable thing about this is:
  • Bug’s appearance can be traced back to March 2012 – 2 years in between and therefore the potential of 2 years of exploitation
    • Information disclosure - 64kb of server memory could be leaked – that 64kb can include private information such as secret keys
  • And another is the sheer scale of it– 2/3 of website was vulnerable to it wtf

IPsec

• Similar benefits to TLS but one layer down in the protocol stack, and this makes it more transparent to users and applications
• If you have security happening at that level, there no need for distinct secure variants of existing protocols. (http& https)
  • If we can rely on IPsec working anywhere, then we won’t ever need https.
• If you implement it in firewall or router, there’s no need to change any software
• One of the technologies used in VPNs

Elements of IPsec

• How we can choose diff sec levels at this layer
• 2 basic protocol extensions
  • AH -Authentication Header
  • ESP – Encapsulating Security Payload
    • Encryption only
    • Both encryption + authentication
• 2 modes of operation
  • Transport mode: protects upper layer protocols encapsulated within an ip packet.
  • Tunnel mode: protects entire packet
  • Difference is to do with whether you protect just the content of the IP packet or the entire packet
• If we were to map this out, 6 diff configurations

Transport & Tunnel modes

	Transport mode	Tunnel mode
AH	Authenticates IP payload + selected portions of header	Authenticates entire inner packet + selected part of outer IP header (there’s 2 header)
ESP	Encrypts IP payload	Encrypts inner packet
ESP+ auth	Encrypts IP payload; authenticates payload, but not IP header	Encrypts and authenticates inner packet.

Applying AH - Authentication only bit

• What we need to do here is the authenticity and integrity check
• Before AH- assuming TCP traffic but its wrapped in the IP header
• Transport mode – we stick AH in between original IP and TCP header. IP remains visible to all software used to booting of a packet.
  • Idea is to prevent tampering the contents of the packet
  • Not necessarily authenticating everything – there are mutable fields – coz its gonna change
• Tunnel mode – doing authentication over entire inner packet
  • We do AH of everything and sticking a new IP header in front of that!! New packet has authentication mechanism built into it to detect tampering.
  • We see the original IP header and a new IP header
• Difference here that with tunnel mode, although inner packet contains original source and des address, the new IP header could have diff info
  • It could contain IP addresses of the firewall and you unwrap the packet and route it to the final destination using the inner IP header. Since the address is verified, we won’t have the problem of spoofing
• Authentication only, and no encryption!! But can be done.

Applying ESP

• Original packet- this time we are encrypting it.
• Transport mode – original TCP content (purple) is encrypted and authenticated for that part of the packet, and put original header in the front.
• Tunnel mode – the whooole IP packet is encrypted, and now we have confidentiality, integrity, and authenticity check possible of the entirety of the packet, plus the new IP header.
  • Now diff is you can’t see the destination for a packet. All they can see is the destination of the outside header. Hence, they can’t decrypt it. Don’t see the real source and dest addresses which has some advantages.

Summary

• Discussed the diminishing value of traditional firewalls
• Explored how TLS provides guarantees of confidentiality, integrity and authenticity (that standard protocols couldn’t)
• Investigated some of the recent problems discovered in TLS implementations
• Considered how IPsec provides similar benefits to TLS, but in the Internet layer