For many people and most organizations Internet has become part of daily operations. The Internet has a bad reputation when it comes to security and is considered to be an insecure medium. This is inherent to the public nature of the Internet. All of the attackers mentioned in the Attacks chapter are ‘online’, and discovered the Internet is a very suitable infrastructure for remote network attacks.
Internet / Intranet / Extranet
The technology of interconnecting web clients and servers, HTTP, and HTML, is also suitable for use in networks with a less public nature than the Internet. The first use is an Intranet, which is a small private piece of ‘Internet’ that is accessible only to users within the organization. It is a very suitable medium to keep employees up to date with information about both the organization and its systems. Typical examples of information you can find on an Intranet are employee directories, emergency evacuation procedures, internal job vacancies, employee of the month articles, and other more, and less, useful information. Additionally, the Intranet can be used to keep employees informed about security related information, such as virus alerts, incident response policies, and acceptable use policies.
In its most basic form, an Intranet is a web server running a website or web application and is accessible only to users with a web browser in the company’s LAN or WAN. The more advanced implementations of an Intranet often use separate servers for backend operations, such as database servers. Protecting the servers that make up the Intranet is no different from protecting the rest of the internal network; they should not be accessible to anyone outside the company. Authentication of Intranet users should preferably occur automatically by using a single sign-on system. This means that the same user credentials used to access the file servers, email, and shared printers, should be used to authenticate the user. A typical example of this is a Microsoft Windows domain with IIS as the web server.
An Extranet is similar to an Intranet, but is accessible by two or more parties. When two companies/partners need to communicate and collaborate a lot, they may benefit from connecting their networks together. Instead of creating a direct connection, which would be objectionable from a security perspective, they create a network that is accessible from both companies’ networks. Firewalls at the entrance points ensure the extranet serves as a buffer between the two companies, and prevent direct access between their networks while allowing them to collaborate and share information in a secure manner. The companies can create this network themselves, but can also introduce a third party to host and manage the extranet.
Secure Sockets Layer (SSL) is a protocol developed by Netscape to allow for secure HTTP communication. Now at version 3.0, SSL has come a long way since its introduction. It is still used primarily in combination with HTTP but it can be used for other application layer Internet protocols as well. It employs symmetric encryption to secure a session between a client and a server, and asymmetric encryption to authenticate the server to the client. Optionally, the server can require the client to authenticate itself. The server is typically a web server as the most common use of SSL is HTTPS (Hypertext Transfer Protocol over Secure Sockets Layer), which is discussed later on in this chapter.
Secure Sockets Layer (SSL)
As with many protocols, SSL employs several sub-protocols to perform tasks such as key exchange, negotiating encryption schemes, and performing the actual data encryption. These protocols operate between the Application and Transport layer of the OSI model. The SSL handshake protocol is in charge of the authentication and key exchange process. As its name implies, it uses a handshake process to establish a secure connection. Although you do not need to memorize this entire process for the Security+ exam, it is a good example of how different types of cryptography work in conjunction to provide authentication, confidentiality, and data integrity.
- A client requests a secure session with a server by connecting to port 443 and sending along session information such as the SSL version and a list of supported encryption algorithms and key sizes.
- The server replies with its public key certificate and session information such as the SSL version and a list of supported encryption algorithms and key sizes. Optionally, the server can include a request for the client to authenticate itself to the server.
- If the Certification Authority (CA) that signed and issued the server’s certificate is listed in the client’s list of trusted CAs, the client authenticates the server by verifying the certificate at the CA. If the CA is trusted, and the certificate is valid, the client will trust the server.
- The client generates a pre-master secret and encrypts it using an asymmetric algorithm and the public key from the server’s certificate, and sends it back to the server. Optionally, if the server requested the client to authenticate itself to the server, it will include its own certificate in the reply to the server.
- If the server requested the client to authenticate itself, the server will verify the client certificate at the CA that signed and issued it. If the client can be successfully authenticated, or the server did not require client authentication, the server uses its own private key to decrypt the pre-master secret. Only the private key that corresponds to the server’s public key can be used to decrypt the pre-master secret.
- The client and the server now both generate a master secret based on the pre-master secret, which in turn will be the basis for a symmetric key. The resulting symmetric session key will be used for the actual data encryption. The length of this session key will be 40 or 128 bits depending on the supported algorithms and key sizes.
- The client sends a message to the server acknowledging that all future traffic from the client will be encrypted with the session key. It then sends a separate, encrypted message acknowledging that the client portion of the handshake is complete.
- The server sends a message to the client acknowledging that all future traffic from the server will be encrypted with the session key. It then sends a separate, encrypted message acknowledging that the server portion of the handshake is complete.
- The SSL handshake is complete and the client and the server use the session key to encrypt, decrypt, and validate the data they send each other. Because the client and the server each generate the symmetric session key based on the pre-master secret, which was securely exchanged using the asymmetric encryption process, the session key is never transmitted across the network, hence cannot be captured by using a network sniffer.
As you may have noticed, SSL employs three types of encryption algorithms: asymmetric encryption (i.e. RSA) to provide authentication, symmetric encryption (i.e. RC2, RC4, DES, 3DES) to provide confidentiality, and hashing (i.e. MD5, SHA) to provide integrity. These three different encryption types will be discussed in more detail in the Basics of Cryptography chapter.
A main difference between SSL and IPsec is that the latter can be used to protect any IP connection and SSL can only be used if the application supports it, such as a web browser and web server software.
When you buy something online using a credit card, the URL should start with https:// instead of http://. At the bottom right of your browser, you should notice a small padlock. Both indicate that a secure HTTP connection over SSL has been established with a web server. The client is connected to port 443 instead of port 80. Remember that SSL by default authenticates the server to the client. This means that any client can connect to website (e.g. to purchase items at an online shop) and those clients can authenticate the website by verifying its public certificate. In addition to authentication of the server, the data transmitted over an HTTPS connection is encrypted hence confidential.
Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS)
The Secure Hypertext Transfer Protocol (S-HTTP) is an extension to HTTP and is designed by the EIT to secure HTTP connections. It is not as similar to HTTPS (HTTP over SSL) as its name might imply. While HTTPS uses SSL to secure an entire session between a client and a server, S-HTTP encapsulates individual messages that can be encrypted, signed, and hashed. Apart from their S-HTTP specific headers, these messages are formatted like normal HTTP messages. S-HTTP is able to use a variety of different algorithms and key infrastructures such as Kerberos and RSA PKI, to provide confidentiality, mutual authentication, and integrity services. The S-HTTP protocol is not widely used.
Secure Hypertext Transfer Protocol (S-HTTP)
The Transport Layer Security (TLS) protocol is standardized by the IETF and intended to replace SSL. It is based on SSL 3.0 and provides very similar services for standard Internet protocols such as HTTP, LDAP, and SMTP. It also employs symmetric encryption to provide confidentiality/privacy, hash algorithms for data integrity, and asymmetric encryption for authentication. However, TLS is more flexible than SSL in that it supports additional cryptosystems, and other key exchange methods in addition to the handshake process. Application protocols protected by TLS typically use the same ports as when they are protected by SSL. For example, HTTP over TLS uses port 443 just as HTTP over SSL. Although they are very similar, the TLS and SSL protocol are not interoperable. However, TLS implementations can downgrade themselves to SSL allowing backward compatibility with SSL clients or servers.
Transport Layer Security (TLS)
The File Transfer Protocol (FTP) is one of the most popular protocols from the TCP/IP suite. It allows files to be transferred between different platforms, but in a very insecure manner. The main problem is that it transmits authentication information, the username and password, in clear text format over the network. This makes it relatively easy for a malicious individual to capture it from the network media by using a packet sniffer. When FTP traffic does not need to cross a firewall or router, it should be blocked. FTP uses port 20 and 21.
FTP (File Transfer Protocol)
A configuration for public FTP servers on the Internet recommended from a security perspective is blind FTP. This allows a user to download files only if he or she knows the exact path and file name – the user will not be able to browse to the directory structure nor list directory contents. For example, if you run a website and want users to be able to download files from your website through blind FTP, you must link directly to the file, i.e. ftp://www.techexams.net/dir2/file1.zip.
If you do not require individual user access, for example, when you have an FTP server to allow file downloads rather than uploads, you can configure the FTP server to allow anonymous access. Users will be able to login without providing a password, or by using any email address as the password. The obvious advantage of anonymous FTP access is that there is no username or password transmitted that might result in damage if they would fall into the wrong hands. You will need to implement the proper access control only for the anonymous user account, i.e. limit its permissions and privileges as much as possible.
The Secure File Transfer Protocol (S/FTP or SFTP) allows you to implement the same functionality as regular FTP, but much more secure. SFTP is basically FTP over SSH (Secure Shell), hence provide the same level of security as SSH. This includes mutual authentication based on digital certificates, and establishing a tunnel between the client and the server through which data is transmitted in an encrypted form. Another mentionable advantage is that SFTP operates over the same port as SSH (port 22) and does not require port 20 and 21 to be open as with regular FTP.
S/FTP (Secure File Transfer Protocol)
Another alternative to FTP that is included in *nix systems is the Secure Copy Protocol (SCP). SCP is the secure counterpart of the Remote Copy Protocol (RCP), and provides secure file transfer using SSH. Like rcp, scp is also a command-line utility on Unix-like systems. SCP is not mentioned in the Security+ exam objectives by is part of the newer Network+ exam.
Instant Messaging (IM) is an electronic communication method that involves real-time correspondence between two or more online users. In contrary to email, communication takes places without passing data through a central server. Users need only an IM client and a network connection to communicate directly with each other. Popular examples of IM clients are ICQ, MSN/Windows Messenger, Yahoo Messenger, and Google Talk. These IM clients allow users to create a private chat room, exchange files, and have voice and video conversations. All on a peer-to-peer basis. IM has become very popular amongst consumers and businesses and as with all popular Internet communication applications, it has become an attractive target for hackers and spammers.
Installing IM software on a computer opens listening ports on the computer, hence makes it vulnerable to network attacks and software exploits. A known example is a security hole in Yahoo Messenger that allowed unauthorized individuals to watch a victim’s webcam remotely. And some of the latest viruses and worms are targeting solely IM clients. Instant messaging clients use rather weak communication protocols that make them vulnerable to packet sniffing. This makes these rogue installations of IM clients unsuitable for private and confidential communication over an open medium as the Internet.
Just as with email, and in fact any other means of communication, IM users are vulnerable to social engineering attacks. Tricking victims into accepting malicious code or disclosing sensitive information through IM is not uncommon. Some companies try to ban the use of IM entirely by blocking the corresponding ports at the firewall or even scrambling IM traffic. IM has become very popular over the past several years so banning it from corporate networks is usually not an option. Instead, companies should look at enterprise level IM software such as those offered by AOL, Yahoo, and Microsoft. Whether and how users are allowed to use IM should be outlined in an Acceptable Use Policy. Educating users and making them aware of the possible risks involved in using instant messaging can have a great impact on overall security. User education and security policies will be covered later on in this book.
One of the main reasons IT departments are usually reluctant towards IM is the lack of central management. IM client are small and can be easily downloaded, installed, and configured by any novice computer user. It is very difficult for the IT department to control the information and the IM software because the IM infrastructure is basically outsourced to a third party (i.e. Microsoft, Yahoo, AOL). Several vendors of security products have released spyware and virus scanners that can protect clients from malicious code. More advanced products allow logging and archiving of all IM messages in a network. This information can be used to monitor the use of IM in a corporate network and report policy violations and attacks.
Java Script is a scripting language developed by Netscape. It allows code to be embedded in HTML pages to add expanded functionality to websites. Java Script is a client-side scripting language, which means the code is compiled and executed on the local client. This makes it vulnerable to being abused for running malicious code on the client as well as access to local files and browser info. For example, an attacker could spoof a web site, lure visitors to the fake site, and have them execute arbitrary Java Script code on their local systems. Another method frequently showing up, especially on the “less legal” areas of the Internet, are small pop-ups that are downsized to go unnoticed to the victim. This allows the Java Script to keep running while the visitor already left the site that popped it up.
By default, a Java Script is bound by a “same origin” policy, which means it can access local files and browser windows from the same domain as the script only. Some browsers such as Netscape and Mozilla support signed Java Script scripts. The digital signature is placed in a separate .JAR file that is loaded with the script and allows users to verify the source and integrity of the script. Signed Java Scripts that are accepted by users can lead to additional vulnerabilities because they can be used to request expanded privileges, such as access to the local file system and control over browser instances and settings. Modern browsers warn the users before accepting signed scripts and requests for expanded privileges or block such scripts entirely. Internet Explorer allows users some control over Java Script acceptance by classifying sites into zones. Java Script still requires user intervention before it can do real damage beyond the browser. Yet again, it is user education and awareness of these risks that can reduce them.
Java is an object-oriented programming language developed by Sun Microsystems. It is platform-independent, which makes it suitable for writing Internet applications. These Java Internet applications are called applets and run on every system that has a Java Virtual Machine installed. The virtual machine compiles the platform-independent applet into a format the local system can interpret. This virtual machine also provides security for running applets by executing them in a sandbox. A sandbox is a restricted virtual area that defines the boundaries for third-party code, such as Java applets, to restrict access to system resources and data. The virtual area is in reality usually some hard disk space, some memory, and a portion of the screen. Keeping the virtual machine software up to date is essential to mitigate attacks through malicious applets.
Java applets can include a digital signature to authenticate the applet and assure the integrity. These signed applets authenticate the author and proof that the applet is not tampered with. As with signed Java Script, signed Java applets can request access to additional resources and data, usually by presenting a dialog box to a users in which they can grant or deny the requested privileges. This makes signed applets potentially more dangerous than unsigned applets because they can be used to do damage outside the sandbox. As with any digital signing system, just because an applet is signed does not guarantee the applet is safe and the author can be trusted. Users should verify the digital signature by verifying if the author’s certificate is valid and issued by a trusted CA.
ActiveX is a Microsoft technology that allows reusable software components to interact with each other in networks. The type of components that is particularly popular in Internet and Intranet environments are called ActiveX controls and are typically used to add Windows functionality and interactivity to web pages. ActiveX controls can be written and interoperate with several different programming languages. They are executed on the client as regular Windows software, and unlike Java applets, ActiveX components do not run in a restricted sandbox. Although modern browsers warn users before accepting an ActiveX control, once it is accepted it can do anything the user can do on the local machine. This obvious lack of security has made ActiveX a popular delivery method for viruses, Trojan Horses, spyware, and other malicious code. ActiveX controls should always be digitally signed to allow users to verify where the control came from and that it has not been tampered with since it was signed. Microsoft provides their own standard for signing files and applications including ActiveX controls. This technology is called Authenticode and works with X.509 certificates and digital signatures just as the previously discussed signing of Java and email.
CGI (Common Gateway Interface) is an interface that allows communication between websites and applications such as Perl scripts and C applications. Typical examples of CGI applications are online contact forms, guest books, and practice test engines. A main disadvantage of CGI is that the application requires execute permissions on the web server. Running poorly coded CGI applications can make a system vulnerable to malformed input, which in turn can result in unauthorized access to non-public areas on the web server’s file system, damage to data, and buffer overflows. Another problem is that they may leak sensitive system information that can aid an attacker in escalating the attack. Newer technologies such as PHP and ActiveX are often used to replace CGI applications because of these security issues.
CGI (Common Gateway Interface)
In a computer system, memory buffers are allocated to processes so they can work with variables and input. When a process fills up the allocated buffer, it may leak out of its boundaries into another buffer causing a buffer overflow. Buffer overflow attacks are often used to create a denial of service situation by crashing a target system. However, an attacker may use it to force a reboot, which is often required to properly load malicious software installed in more advanced attack scenarios. It may even allow arbitrary code to be run on a target system. Buffer overflow attacks are often difficult to detect, as they can appear to be some unknown memory leak errors that just happened for seemingly harmless reasons.
An example of how far an exploit using buffer overflows can go is the Code Red buffer overflow worm that caused havoc on the Internet in 2001. By sending malformed remote requests to a Microsoft IIS server with Indexing service installed, administrative access could be gained that allowed the Code Red worm to propagate and attack other systems and cause damage to data.
Preventing buffer overflows is something the developer of the script or application should take care of by implementing checks for every possible input. Operating systems and platforms for applications and scripts are often able to prevent illegal buffer overflows, but careless programming can still produce a risk. Software applications and scripts that allow user input should check input variables for format and size. The lack of such proper input checking can make the system vulnerable to buffer overflow attacks and means the software basically has a bug. The better software manufacturers provide a patch soon after such a bug has been discovered. Hence, if you do not have control over the code itself, make sure you keep your systems up-to-date. As mentioned in the Software Exploitation section of the Attack TechNotes, software exploits, including known buffer overflow attacks, can be detected and possibly stopped by a decent IDS.