Posts Tagged ‘SSL

Web Spoofing: Threat Models, Attacks and Current Defenses

The initial design of  Web protocols and Internet assumed benign environment, where servers, clients and routers cooperate and follow the standard protocols, except for unintentional errors. However, as the amount and sensitivity of usage increased, concerns about security, fraud and attacks became important. In particular, since currently Internet access is widely (and often freely) available, it is very easy for attackers to obtain many client and even host connections and addresses, and use them to launch different attacks on the network itself (routers and network services such as DNS) and on other hosts and clients. In particular, with the proliferation of commercial domain name registrars allowing automated, low-cost registration in most top level domains, it is currently very easy for attackers to acquire essentially any unallocated domain name, and place there malicious hosts and clients. We call this the unallocated domain adversary: an adversary who is able to issue and receive messages using many addresses in any domain name, excluding the finite list of already allocated domain names. This is probably the most basic and common type of adversary.

Unfortunately, we believe, as explained below, that currently, most web users are vulnerable even against unallocated domain adversaries. This claim may be surprising, as sensitive web sites are usually protected using the SSL or TLS protocols, which, as we explain in the following subsection, securely authenticate webpages even in the presence of intercepting adversaries (often referred to as Man In The Middle (MITM) attackers).Intercepting adversaries are able to send and intercept (receive, eavesdrop) messages to and from all domains.Indeed, even without SSL/TLS, the HTTP protocol securely authenticates web pages against spoofing adversaries, which are able to send messages from all domains, but receive only messages sent to unallocated (adversary-controlled) domains. However, the security by SSL/TLS (against intercepting adversary; or by HTTP against spoofing adversary) is only with respect to the address (URL) and security mechanism (HTTPS, using SSL/TLS, or ‘plain’ HTTP) requested by the application (usually browser). In a phishing attack (and most other spoofing attacks), the application specifies, in its request, the URL of the spoofed site. Namely, web spoofing attacks focus on the gap between the intentions and expectations of the user, and the address and security mechanism specified by the browser to the transport layer.


Tags : , , , , , , , , , , , , , , ,

Transport Layer Security Protocol

TLS (Transport Layer Security) was released in response to the Internet community’s demands for a standardized protocol. The IETF provided a venue for the new protocol to be openly discussed, and encouraged developers to provide their input to the protocol.

The TLS protocol was released in January 1999 to create a standard for private communications. The protocol “allows client/server applications to communicate in a way that is designed to prevent eavesdropping,tampering or message forgery.” According to the protocol’s creators, the goals of the TLS protocol are cryptographic security, interoperability, extensibility, and relative efficiency.These goals are achieved through implementation of the TLS protocol on two levels: the TLS Record protocol and the TLS Handshake protocol.

TLS Record Protocol

The TLS Record protocol negotiates a private, reliable connection between the client and the server. Though the Record protocol can be used without encryption, it uses symmetric cryptography keys, to ensure a private connection. This connection is secured through the use of hash functions generated by using a Message Authentication Code.

TLS Handshake Protocol

The TLS Handshake protocol allows authenticated communication to commence between the server and client. This protocol allows the client and server to speak the same language, allowing them to agree upon an encryption algorithm and encryption keys before the selected application protocol begins to send data. Using the same handshake protocol procedure as SSL, TLS provides for authentication of the server, and optionally, the client.

Tags : , , , , , , , , , , , ,

Use of SOAP over HTTP

Since the SOAP binding requires that conformant applications support HTTP over TLS/SSL with a number of different bilateral authentication methods such as Basic over server-side SSL and certificate-backed authentication over server-side SSL, these methods are always available to mitigate threats in cases where other lower-level systems are not available and the above listed attacks are considered significant threats.

This does not mean that use of HTTP over TLS with some form of bilateral authentication is mandatory. If an acceptable level of protection from the various risks can be arrived at through other means (for example, by an IPsec tunnel), full TLS with certificates is not required. However, in the majority of cases for SOAP over HTTP, using HTTP over TLS with bilateral authentication will be the appropriate choice.

The HTTP Authentication RFC describes possible attacks in the HTTP environment when basic or message-digest authentication schemes are used. Note, however, that the use of transport-level security (such as the SSL or TLS protocols under HTTP)only provides confidentiality and/or integrity and/or authentication for “one hop”. For models where there may be intermediaries, or the assertions in question need to live over more than one hop, the use of  HTTP with TLS/SSL does not provide adequate security.

Tags : , , , , , , , , , , , ,

Security a New Dimension in Embedded System Design

Embedded systems, which will be ubiquitously used to capture, store, manipulate, and access data of a sensitive nature, pose several unique and interesting security challenges. Security has been the subject of intensive research in the areas of cryptography, computing, and networking. However, security is often mis-construed by embedded system designers as the addition of features, such as specific cryptographic algorithms and security protocols, to the system. In reality, it is an entirely new metric that designers should consider throughout the design process, along with other metrics such as cost, performance, and in one form or another is a requirement for an increasing number of embedded systems, ranging from low-end systems such as PDAs, wireless handsets, networked sensors, and smart cards, to high-end systems such as routers, gateways, firewalls, storage servers, and web servers. Technological advances that have spurred the development of these electronic systems have also ushered in seemingly parallel trends in the sophistication of security attacks. It has been observed that the cost of insecurity in electronic systems can be very high. For example, it was estimated that the “I Love You” virus caused nearly one billion dollars in lost revenues worldwide.
With an increasing proliferation of such attacks, it is not surprising that a large number of users in the mobile commerce world (nearly 52% of cell phone users and 47% of PDA users, according to a survey by Forrester Research) feel that security is the single largest concern preventing the successful deployment of next-generation mobile services. With the evolution of the Internet, information and communications security has gained significant attention. For example, various security protocols and standards such as IPSec, SSL, WEP, and WTLS, are used for secure communications. While security protocols and the cryptographic algorithms they contain address security considerations from a functional perspective, many embedded systems are constrained by the environments they operate in, and by the resources they possess. For such systems, there are several factors that are moving security considerations from a functioncentric perspective into a system architecture (hardware/software) design issue.

Tags : , , , , , , , , , , , , , , , , , , , ,

Securing against software attacks

Software is a central and critical aspect of the computer (and embedded system) security problem. Software defects with security ramifications —including implementation bugs such as buffer overflows and design flaws such as inconsistent error handling — promise to be with us for years. All too often, malicious intruders can hack into systems by exploiting software defects. Moreover, Internet-enabled software applications present the most common security risk encountered today, with software’s ever expanding complexity and extensibility adding further fuel to the fire.

Software security’s best practices leverage good software engineering practice and involve thinking about security early in the software design life cycle (SDLC), knowing and understanding common threats (including language-based flaws and pitfalls), designing for security, and subjecting all software artifacts to thorough objective risk analyses and testing.

Security is an emergent property of a software system. This is a subtle point often lost on development people who tend to focus on functionality. Obviously, there are security functions in the world, and most modern software includes security features, but adding features such as SSL (for cryptographically protecting communications) does not present a complete solution to the security problem. A security problem is more likely to arise because of a problem in a standard part of the system (e.g., the API to the server) than in some given security feature. This is an important reason why software security must be part of a full lifecycle approach. Just as you cannot test quality into a piece of software, you can not spray paint security features onto a design and expect it to become secure.

Figure 1: Software security best practices applied to various software artifacts in the Software Design Life Cycle (SDLC)

As practitioners become aware of software security’s importance, they are increasingly adopting and evolving a set of best practices to address the problem. There is no substitute for working software security as deeply into the development process as possible and taking advantage of the engineering lessons software practitioners have learned over the years. Figure 1 specifies one set of best practices and shows how software practitioners can apply them to the various software artifacts produced during software development. Although the artifacts are shown laid out in a linear sequence, most organizations follow an iterative approach, which means that best practices will be cycled through more than once as the software evolves.

Software security best practices apply at various levels:

  1. The requirements level: Security requirements must cover both overt functional security (e.g., the use of applied cryptography) and emergent characteristics.
  2. The design and architecture level: A system must be coherent and present a unified security architecture that takes into account security principles (such as the principle of least privilege).
  3. The code level: Static analysis tools — tools that scan source code for common vulnerabilities — can discover implementation bugs at the code level.

Risks crop up during all stages of the software life cycle, so a constant risk analysis thread, with recurring risk tracking and monitoring activities, is highly recommended. Security testing must encompass two strategies: testing security functionality with standard functional testing techniques, and risk-based security testing based on attack patterns and threat models. Penetration testing is also useful, especially if an architectural risk analysis is specifically driving the tests.

Tags : , , , , , , , , , , , , , , , , ,

Flaws in Authentication Protocols

Several database systems have plain text authentication protocols, by which we mean authentication protocols in which the password is passed “on the wire” in a plain text or easily decrypted format. In a default configuration (that Sybase warns against, but which we have still seen in use) Sybase passes passwords in plaintext. By default, Microsoft SQL Server obfuscates passwords by swapping the nibbles (4-bit halves of a byte) and XORing with 0xA5. In both ofthese cases, the vendors warn against using the plain text versions of their authentication protocols and provide strong, encrypted mechanisms that are relatively easy to deploy — but the defaults are still there, and still dangerous.

MySQL has historically had a number of serious problems with its authentication protocol. Although the protocol isn’t plaintext, the mathematical basis of the authentication algorithm prior to version 4.1 was called into question by Ariel Waissbein, Emiliano Kargieman, Carlos Sarraute, Gerardo Richarte, and Agustin Azubel of CORE SDI (CVE-2000-0981). This describes an attack in which an attacker that can observe multiple authentications is quickly ableto determine the password hash.

A further conceptual problem with the authentication protocol in MySQL prior to version 4.1 is that the protocol only tests knowledge of the password hash, not the password itself. This leads to serious problems if a user is able to somehow determine another user’s password hash — and MySQL has been subject to a number of issues in which that was possible. Robert van der Meulen found an issue (CVE-2000-0148) in MySQL versions prior to 3.23.11 whereby an attacker could authenticate using only a single byte of the expected response to the server’s challenge, leading to a situation whereby if you knew a user’s username, you could authenticate as that user in around 32 attempts.

Chris Anley recently found a very similar problem in MySQL (CAN-2004-0627) whereby a user could authenticate using an empty response to the server’s challenge, provided he or she passed certain flags to the remote server.This category of bugs is almost as dangerous as the “unauthenticated flaws in network protocols” category, because in many cases the traffic simply looks like a normal authentication. Attackers don’t need to exploit an overflow or do anything clever, they simply authenticate without necessarily needing the password—or if they’ve been able to sniff the password, they just authenticate.The best defense against this kind of bug is to ensure that your database patches are up-to-date, and that you don’t have any plaintext authentication mechanisms exposed on your databases. If your DBMS cannot support encrypted authentication in your environment, you could use IPSec or SSH to provide an encrypted tunnel. MySQL provides explicit guidelines on how to do this in its documentation, though recent versions of MySQL allow authentication to take place over an SSL-encrypted channel.


Tags : , , , , , , ,