Internet Security and the Advantages of Different Models

Transcription

1 Internet security Fact of the week In 2000, RSA securities web site was defaced by crackers, in what could have been a serious embarrassment for the well known security company. The crackers did not crack RSA s systems, however, but performed a spoof by attacking a DNS server upstream of RSA s domain. This shows how critical the problem of dependency is in security, and that security is not just the concern of those who have secrets to keep. It is a problem for society at large, Chapter 13 Gollmann: Computer Security Chapter 10, 23 Bishop: Introduction to Computer Security Chapter 11, 26 Bishop: Computer Security: Art and Science The tools of Internet Security Internet security is what one hears about most often in relation to computers today, but it holds no special surprises. Rather, it is a place where all of the themes we have discussed so far meet and play a role. This week, we summarize some miscellaneous items, which you should read about on your own. Internet security is often associated with Web security. Web security is a classic example of security under changing assumptions. The Web was originally a system for downloading text and pictures, but, over time, it has been hacked into an interactive system full of poorly designed solutions. Slowly, it is evolving into a real technology. SSL/TLS The Secure Socket Layer (SSL, was originally introduced by Netscape communications in order to allow private web transactions over open lines. (HTTPS is SSL encoded HTTP). Version 3 of the protocol was extended with experiences and suggestions from other companies in the industry and was published as an Internet draft document standard. Transport Layer Security (TLS) is essentially an outgrowth of SSLv3, and it is intended that this will become a network industry standard. SSL and TLS use public/private key methods to establish communications, security capabilities, and establish a session key. The protocol then authenticates both parties and negotiates a cheaper encryption algorithm and message digest to sign the message. Thereafter the cheaper encryption scheme is used, (e.g. 3DES,IDEA,RC4 etc). 1

2 SSL is designed to be a drop-in replacement for standard socket communication, easily implemented, with minimal investment on the part of the programmer. Roughly speaking, one simple replaces some system calls with library functions from SSL and the encryption should be transparent. X.509 certificates!!!!!!!! SET - secure electronic transactions The Secure Electronic Transaction system was devised in response to the needs of VISA and MASTERCARD credit card companies in Several companies, including Microsoft, Netscape, IBM, RSA, Terisa and Verisgn contributed to the design. Whereas SSL/TLS is a system for generic stream transfer, SET is based on a specific transaction model, for payment of goods by credit card. The system is designed to ensure privacy, integrity and authenticity to all parties in a transaction (customer,merchant,bank). SET makes use of a trusted third party certificate organization, who keep a database of user certificates for verification, similar to the registration of SSL sites by Verisign. The SET model uses a system of dual signatures to maximize privacy. The merchant does not need to know a customer s credit card details; the bank does not need to know the details of the goods ordered from the merchant. Separate hashes are used for each part of the message. These signatures need to be combined, so that payment and goods-transaction are connected. However, they are combined in such a way that only the bank can verify its part of the signature and only the merchant can verify its part of the signature. VPNs and S/WAN The TCP/IP protocols were invented at a time when it was an unusual privilege to have access to the root/administrator account, or own one s own network connection. The security of network communication was based on the assumption that ordinary users would not have access to the network traffic. Today everyone has access. One of the problems with TCP/IP security is that passwords and other information are often sent in clear text (unencrypted) so that eavesdroppers could sniff the net and pick up the data. A secure virtual private network (VPN) is an encrypted link between hosts, which acts as a tunnel or armoured pipe between a remote location and a service provider. There are many technical solutions to this problem, most are based on RSA style encryption, like ssh. 2

3 IPSec Many problems in network communication would be easily solved if there were transport layer encryption of internet traffic. Spoofing would be impossible, because attackers would have access to cryptographic checksums of the packets (spoofing could be easily detected). Similarly sniffing the net for passwords, leaked by old protocols, would be impossible, since no plaintext data would be sent. IPSec is a security system developed for use with IPv6, but it can also be implemented for IPv4 (RFC1636). It offers encryption at the IP level. This means that common TCP attacks, such as sequence guessing or spoofing attacks cannot occur, since attackers could never see the contents of traveling packets. IPSec allows hosts to set security policies on routed packets. This includes access control lists for encryption, integrity checks and point-to-point private tunnels. This all sounds like the perfect solution to the problem, however IPSEc is not without problems. First of all, it is not fully implemented by network hardware and software today. This could take some time. Moreover, like any rule based system, IPSec is vulnerable to its own complexity. It has been shown that contradictory policies can lead to unusual side effects, either destroying connectivity, or opening traffic for the wrong parties. At the present time, it does not seem that IPSec can replace higher level encryption tunnels, due to the difficulties mentioned above. Some problems with IPSec policies Consider a scenario between two domains one of which has a firewall and one of which has a gateway supporting IPSec security policies. The users of H1 are concerned about the privacy of data, so they arrange for the traffic to be encrypted. Using IPSec policy rules, an encrypted tunnel is built between H1 and and the secure gateway SG2 in order to protect the traffic. However, the IPSec policy rules on the firewall are set by a different authority, and they can be specified so that encrypted packets can be denied access. If the firewall FW1 has such a rule, either intentionally or unintentionally, then all packets will be dropped and communication will be mysteriously impossible. 3

4 Suppose that H1 is still trying to encrypt traffic to SG2, with the same tunnel rule. Suppose the firewall FW1 now has the rules: Allow: source=h1, destination=h2 Deny: all others However, since the encryption tunnel changes the destination to be SG2 in the outer encapsulation header, the firewall will mistakenly drop all traffic from H1 to H2 that should be allowed. Even though the traffic has the correct source and destination addresses, the overlapping rules cause problems. In the following example, encryption plays a role in fixing a strong ordering of rules that can lead to unfortunate miscommunications. Consider two separate organization sites O1 and O2 (see figure above), each with their own IPSec gateways (SG1 and SG2). Suppose that the administrator, from department D1 in O1, who is in charge of SG1 decides that all traffic from D1 to site O2 should be encrypted by a tunnel from SG1 to SG3. In a different building, another administrator, who controls SG2 decides that traffic from site O1 to site O2 should be encrypted through a tunnel from SG2 to SG4. What happens now, when someone in organization O1 attempts to send a message to someone in organization O2? The traffic between the sites is now governed by two policies that do not agree, and either tunnel could be chosen. Part of the journey is unencrypted, either in the first organization, or in the second. If the administrator in D1 does not add a selector for traffic specifically to D2 (via SG4) that allows it to pass via SG2, 4

5 then it could take the upper tunnel and be unencrypted within the second organization (between SG3 and SG4). If the communication is between an employee of organization O1 ad the organization itself, this might be a breach of security. On the other hand, if the rules are adjusted so as to direct traffic to the lower tunnel for all traffic destined for site O2, then there would be two overlapping rules to SG4 (from SG1 and SG2) and the traffic could pass by either one of two routes. Suppose someone in department D1 now wishes to send data to a host outside of department D2. If the traffic takes the upper tunnel 1, there is no problem. However, if the traffic chooses the lower tunnel in the diagram, via a new tunnel between SG1 and SG2, then some strange effects can occur. With this configuration, traffic is encapsulated with a secure header from SG1 and then encapsulated by a new header from SG2 to send to SG4. When SG4 decrypts and removes the packaging, it finds that the destination is SG3, SG4 sends the traffic back to SG3 unencrypted, which finally the packet to its actual destination. SG1: (dest=h2)_{sg4}, send SG2 SG2: ((dest=h2)_{sg4})_{sg4}, send SG4 SG4: (dest=h2), send SG3 SG3: send destination Although the intention was to encrypt all the traffic, the traffic ends up passing from SG4 to SG3 unencrypted. The problem over overlapping rules can thus lead to security problems, unless a careful site-wide management assures the consistency of policy throughout. The alternative to using multiple encapsulation rules is use a point to point encryption, but this has its own problems. All points along a route must be trusted to deny access to eavesdroppers. This is not enforceable. DNSSec? Solving the problem of secure communication allows us to have private and verifiable conversations between remote parties, but it does not prevent the possibility that we might be tricked into talking to the wrong person! In DNS cache attacks, crackers have been able to plant incorrect IP addresses, diverting a conversation to a host which then impersonates the host at the intended address. The problem with DNS database lookup is that DNS is a trusted database, but it is trusted on very little evidence. Secure DNS (DNSSEC) attempts to cure this problem by using message digests and (public/provate key) digital signatures to verify the content of information. 5

6 Secure DNS attempts to guarantee the authenticity of the DNS records, to avoid the problem of spoofing. About DNSSec ( RFC 4033: DNS Security Introduction and Requirements ( RFC 4034: Resource Records for the DNS Security Extensions (http: // RFC 4035: Protocol Modifications for the DNS Security Extensions ( It does not attempt to provide privacy for lookups (after all, the database is public knowledge), only integrity. It is a design principle that all users should obtain the same information when making the same lookup, i.e. that spoofing should be impossible. The main problem with DNS has been twofold: The possibility of mining IP addresses from the domain (zone transfer) data Poisoning the cache with unauthorized and false data Changes have been proposed to fix these problems. Access control lists and transaction signing was introduced several years ago, to prevent unauthorized network queries from dumping the entire local DNS data from a server, in order to see the domain structure. TSIG (RFC 2845) is a new transaction attribute protects zone transfers and lookups, on private transactions. For instance, internally in an organization one may agree on a common password (shared secret) for verifying signatures. It cannot protect recursive lookups from the wider Internet however since that would require the shared secret to be broadly available (It uses a symmetric key - with shared secret). However, it only makes limited sense to restrict access to a public database. Each site has to make a decision as to whether its DNS data should be visible to the outside world or not. This is a dilemma and a matter for security policy. The advantage of TSIG is that it requires no incompatibility with existing name resolvers. A broader system of change was proposed to allow verification of data for any client-server pair. This is called the DNSSEC project. The project proposes radical changes to the design and functioning of DNS. It would mean changing resolvers on all hosts on the internet. DNSSEC cannot be compatible with the present DNS service. DNSSEC uses public, private key encryption in order to sign and verify data transfers, without the need of shared secrets. However, with public-private key methods, one must still 6

7 deal with the issue of trust. There is no final solution to this problem as yet. Moreover, the computational overhead for computing digital signatures on DNS domains (e.g..com) is huge. In recent tests, it was found that.com (a large zone) could be signed within days, so the problem is perhaps not insurmountable. The DNS service is undergoing radical changes. Lookup of IPV6 addresses presents a new set of problems for name servers. There is the question of whether DHCP should interface with DNS. This was originally a Microsoft idea which, for IPv4 was a difficult solution to an easy problem, but with IPv6, where address allocation is mandatorily auto-detected, it becomes a real issue to deal with. DNS has been based on UDP (unreliable) transfers. However, packet sizes are getting too large to rely on UDP. The change to a TCP based name service would have significant performance and protocol implications. DNS is probably the largest distributed database in existence. The problem of implementing a secure service, with updates and distribution all around the world, is a formidable one and the DNSSEC system is still being tested. To date, there is genuine doubt as to whether DNSSEC will ever be used. The worst problems with cache poisoning and data-mining have been solved using TSIG and access control lists. The additional security implied by DNSSEC might well prove to be just too expensive, and too difficult to administrate in practice. DHCP DHCP is Dynamic Host Configuration Protocol. It is used to control vital networking parameters of hosts with the help of a server. DHCP is backward compatible with BOOTP. For more information see RFC 2131 (old RFC 1541) and other. The most common use for DHCP is to assign IP addressed dynamically at startup. This works by a simple broadcast mechanism. The main problem with DHCP is that, in today s open, ubiquitous networking environments, anyone can walk into a building and get a trusted IP address from a server. Some modifications to DHCP have been made (e.g. NetReg) for registering ethernet addresses in order to provide access control to DHCP services. It should be noted, however, that any user can guess a free IP address and set it manually, thereby gaining access to the internet. The lesson here is that any connection to the network should be treated as untrusted until it can prove itself otherwise, e.g. with physical security. Secure mail and S/MIME Several mail transfer agents (MTA) such as sendmail v8.11 now support application level, point to point, encryption to prevent eavesdropping of 7

8 mail: this is called START TLS and AUTH SMTP ( org/rfcs/rfc2487.html) in which the entire SMTP session is encrypted. The problem with the SMTP protocol, as implemented on many systems, is that it cannot handle non-ascii data. This makes encryption or transmission of multi-media data files difficult. This is the reason for MIME (multi-purpose internet mail extension) attachments, which re-encode data in ASCII symbols (like Unix uuencode/uudecode). Encryption systems for must therefore convert the data into an ASCII printable format. content can be encrypted manually with PGP. A secure version of MIME (for transport of multimedia extensions), called S/MIME allows encryption and use of digital signatures. SNMP services The Simple Network Management Protocol was designed as a way of controlling and managing all kinds of devices, from a central location, remotely by network. Today, most computers, printers and network hardware can be monitored and managed in a limited way by SNMP. Like many network control schemes, SNMP places functionality before security. SNMP 2 has a default password of public on all devices and was notorious for providing essential information to crackers trying to break into systems. SNMP 3 goes some way to improving security, but still has the basic design flaws of a control management system. Mobile/Wireless internet services LANs based on the IEEE b Ethernet, or wireless standard are now becoming popular. Such wireless LANs are a perfect example of placing convenience before security. By its very nature, wireless radiation is nonspecific and highly parallel and there fore a receiver can do little to shield itself from intrusive transmissions. Depending on the position of the wireless antenna, it s possible to gain access to wireless LANs from about 100 meters (line of sight), through glass or walls. The b standard calls for products to have a shared password for all devices, called the Server Set ID. Wireless LAN products ship with default passwords that have become commonly known. Cisco s password is Tsunami, 3Com s is 101, for instance. Wireless LANs can use encryption, but the b standard s encryption standard, called Wired Equivalent Privacy, has a default setting for no encryption. Two other modes include 40-bit breakable encryption and the stronger 128-bit. This might not be a problem is users use a tool like secure shell, or a VPN in addition. The management interface to wireless LANs uses SNMP, also has all the vulnerabilities of SNMP associated with it, because it s not that difficult to 8

9 capture the default community string to read the configuration of all the devices on a wireless network. Like wireline networks, wireless LANS can be jammed by denial-ofservice attacks. It is extremely easy, because 2.4 GHz is an unlicensed frequency. It can be jammed by many other types of devices using that frequency or other wireless-enabled laptops. One way to add security to wireless LANs is to use DHCP services which require the registration of ethernet addresses (like NetReg). In addition to b, there is WAP, an early attempt to provide web services to mobile phones. WAP uses point to point encryption to protect content, but usually has to pass through several gateways where the signals could be tapped. WAP is now more or less dead. Covert channels for attacks It seemed for a time that the best way to avoid computer viruses and worms was simply to block all attachments containing Windows executables, using a mailfilter or firewall. Alas, this kind of simplistic thinking is responsible for many security blunders. For example, the arrival of Webmail provided a covert channel for viruses to spread, independently of filters. In general, border control is always an ineffective solution. Firewalls protect networks only from junk traffic and the inexperienced. Persistent crackers are ingenious at exploiting any path through a fault tree. 9