Network
Latest external collaboration on country level. Dive into details by clicking on the dots.
Publication
Featured researches published by Ryan Permeh.
Archive | 2002
David R. Mirza Ahmad; Ido Dubrawsky; Hal Flynn; Joe Grand; Robert Graham; Norris L. Johnson; F. William Lynch; Steve W. Manzuik; Ryan Permeh; Ken Pfeil; Ryan Russell
The purpose of this chapter is to describe session hijacking and the various tools available to carry out hijacking attacks. The term session hijacking refers to an attackers ability to take over a portion of a session and act as one of the participants. Session hijacking is usually an extension of sniffing, except that sniffing is passive and hijacking requires active participation. Hijacking exploits the inherent weaknesses in most types of networks and unencrypted protocols, namely that the information passes in the clear. This is the same weakness that sniffing takes advantage of. In addition to monitoring, a hijacking attack may also inject a packet or flame pretending to be one of the communicating hosts. This act is similar to spoofing, except no guessing is involved and all the necessary information is available to the attacker. This chapter discusses what a hacker can achieve with hijacking and the tools that are currently available to perform hijacking attacks.
Archive | 2002
David R. Mirza Ahmad; Ido Dubrawsky; Hal Flynn; Joe Grand; Robert Graham; Norris L. Johnson; F. William Lynch; Steve W. Manzuik; Ryan Permeh; Ken Pfeil; Ryan Russell
Tunneling is typically virtualizing the lack of connectivity through the .sensible use of cryptography. First there was very restricted global network access, then global network access was everywhere, then there was a clampdown on that connectivity, and finally holes are poked in the clampdown for those systems engineered well enough to be cryptographically secure. The focus of this chapter is this engineering. These methods are not ideal but they work. Determining a suitable method of tunneling between networks is not minor as one has to choose from the wide range of available protocols, packages, and possible configurations. The purpose of this chapter is to describe some of the more cutting-edge mechanisms available for establishing connectivity across any network architecture and understand just what makes a tunneling solution viable. Tunneling is a technique of bypassing overly restrictive security controls. The primary concerns for tunneling design are privacy, routability, deployablity, flexibility, and quality. The process of designing tunnels includes creating a path between the client and the server, independently authenticating and encrypting over this new path, forwarding services over this virtual independent link. OpenSSH is one such package to create end-to-end tunnels.
Archive | 2002
David R. Mirza Ahmad; Ido Dubrawsky; Hal Flynn; Joe Grand; Robert Graham; Norris L. Johnson; F. William Lynch; Steve W. Manzuik; Ryan Permeh; Ken Pfeil; Ryan Russell
This purpose of this chapter is to study unexpected input, how it is dangerous, techniques to eradicate vulnerabilities, and tools used to handle unexpected data. To interact with a user, an application must accept user-supplied data. It could be in a simple form or a complex stream. In either case, the user may submit data the application was not expecting. The result could be nil, or it could modify the intended response of the application. It could lead to the application providing information to users that they would not normally be able to get, or it could interfere with the application or underlying system. Three classes of attack can result from unexpected data: buffer overflow, system functions, and logic alteration. There is o concrete distinction between attacks and particular attacks may fall into multiple classes. The actual format of the unexpected data varies; an unexpected data attack could be as simple as supplying a normal value that modifies the applications intended logical execution. This format usually requires very little technical prowess. There are attacks that succeed due to the inclusion of special meta-characters that have alternate meaning to the application, or the system supporting it.
Archive | 2002
David R. Mirza Ahmad; Ido Dubrawsky; Hal Flynn; Joe Grand; Robert Graham; Norris L. Johnson; F. William Lynch; Steve W. Manzuik; Ryan Permeh; Ken Pfeil; Ryan Russell
This chapter is designed to study automated security review and attack tools. Accumulating and putting together a set of security scanning tools can be time consuming. They might not work together as well as needed or offer all of the features required. Integrated tools are available some commercial, some free that present the required features. The automated tools fall into two categories. The first category will attempt to identify vulnerabilities on a system based on a list of known vulnerabilities, called checks or signatures, without actually exploiting them. This category old, and many of the security software vendors offer such a product. They are usually called a vulnerability assessment tool or a remote vulnerability scanner. The second category is tools that will attempt to exploit security holes, and in some cases, use the newly compromised victim to further penetrate into a network. This category is newer and tools have only been announced and are not yet available to the public. The first category is chiefly intended for security administrators to evaluate their network for vulnerabilities. The second category is intended for use primarily by penetration testers. These automated tools can be a great help, especially when many hosts must be evaluated for weaknesses. Like any set of signatures, these tools can report both false positives and false negatives. This chapter examines some of the tools that are available, both commercial and free.
Archive | 2002
David R. Mirza Ahmad; Ido Dubrawsky; Hal Flynn; Joe Grand; Robert Graham; Norris L. Johnson; F. William Lynch; Steve W. Manzuik; Ryan Permeh; Ken Pfeil; Ryan Russell
This chapter is designed to illustrate attacks on trusted identities referred to as spoofing. Spoofing attacks are defined as providing false information about a principals identity to obtain unauthorized access to systems and their services. This definition is accurate, but certain clarifications should be made to accurately separate spoofing attacks from other, network-based methods of attack. The concept of assuming the identity of another is essential to the nature of the spoof. The canonical example of spoofing is the Internet Protocol (IP) spoofing attack. Essentially, Transmission Control Protocol/IP (TCP/IP) and the Internet trusts users to specify their own source address when communicating with other hosts. It is up to the sender of any given message to determine the source address to preface it with. Should the sender use a falsified source address, no reply will be received. Spoofing at its core involves sending a message that is not what it claims to be. This message may appear to have been sent by a different, more trusted individual than. One of the more interesting and unrecognized aspects of spoofing is that, as a methodology of attack, it can and will operate at all layers in-between the client and the server. One important thing about spoofing is that it is not always malicious. There exist technologies that can help safeguard against spoofing. These include firewalls to guard against unauthorized transmissions, non-reliance on undocumented protocols, various crypto types to guard to provide different levels of authentication.
Archive | 2002
David R. Mirza Ahmad; Ido Dubrawsky; Hal Flynn; Joe Grand; Robert Graham; Norris L. Johnson; F. William Lynch; Steve W. Manzuik; Ryan Permeh; Ken Pfeil; Ryan Russell
This chapter is designed to elucidate laws of security. One of the shortcuts that security researchers use in discovering vulnerabilities is a mental list of observable behaviors that tells them something about the security of the system they are examining. If they can observe a particular behavior, it is a good indication that the system has a trait that they would consider to be insecure, even before they have a chance to perform detailed tests. This list is referred to as the Laws of Security. These laws are guidelines that can be used to keep an eye out for security problems while reviewing or designing a system. The system in this case might be a single software program, or it could be an entire network of computers, including firewalls, filtering gateways, and virus scanners. The Laws of Security identifies the weak points and allows focusing research on the most easily attackable areas. This chapter concerns itself with familiarizing with these laws. Some laws of security include: client-side security does not work, one cannot securely exchange encryption keys without a shared piece of information, malicious code cannot be 100 percent protected against, any malicious code can be completely morphed to bypass signature detection, and firewalls cannot protect 100 percent from attack. This chapter focuses on theory, or laws that are closer to a mathematical rule..
Archive | 2002
David R. Mirza Ahmad; Ido Dubrawsky; Hal Flynn; Joe Grand; Robert Graham; Norris L. Johnson; F. William Lynch; Steve W. Manzuik; Ryan Permeh; Ken Pfeil; Ryan Russell
This chapter is designed to discuss hardware hacking. Hardware hacking is defined as modifying hardware appliances or electronic products to perform functions for which they were not originally intended. This could range from a simple software replacement to a complicated electrical circuit attack. Any piece of electronic equipment can serve as a candidate for hardware hacking. Particularly of interest are Personal Digital Assistants (PDAs), mobile telephones, and hardware authentication devices such as dongles, token cards, biometric devices, and smart cards. Other common targets are any devices that are network-enabled and have embedded cryptographic functionality, such as routers, switches, virtual private networks (VPNs), and cryptographic accelerators. Hardware hacking is done for the following reasons—general analysis of the product to determine common security weaknesses and attacks, access to the internal circuitry without evidence of device tampering, retrieval of any internal or secret data components, cloning of the device, retrieving memory contents, and elevation of privilege. Hardware hacking requires a physical set of tools. This chapter covers the background and process of hardware hacking, tools and other resources, and a few real-world examples. It chapter focuses on hacking electronic hardware devices to gain a security advantage.
Archive | 2002
David R. Mirza Ahmad; Ido Dubrawsky; Hal Flynn; Joe Grand; Robert Graham; Norris L. Johnson; F. William Lynch; Steve W. Manzuik; Ryan Permeh; Ken Pfeil; Ryan Russell
This chapter is designed to comprehend the various classes of attack. The seriousness of a particular attack type depends on two things: how the attack is carried out, and what damage is done to the compromised system. An attacker being able to run code on his machine is probably the most serious kind of attack for a home user. For an e-commerce company, a denial of service (DOS) attack or information leakage may be of more concern. Each vulnerability that can lead to compromise can be traced to a particular category, or class, of attack. The properties of each class give a vague idea for how serious an attack in that class is, as well as how hard it is to defend against. This chapter aims at elucidating each of the attack classes in detail, including the kinds of damage they can cause the victim, as well as what the attacker can gain by using the. Attacks can lead to anything from leaving systems without the ability to function, to giving a remote attacker complete control of ones systems. This chapter examines seven categorized attack types. These seven attack types are the general criteria used to classify security issues: denial of service, information leakage, regular file access, misinformation, special file/database access, remote arbitrary code execution, and elevation of privileges. This chapter also discusses the placement of these attacks on a line of severity.
Archive | 2002
David R. Mirza Ahmad; Ido Dubrawsky; Hal Flynn; Joe Grand; Robert Graham; Norris L. Johnson; F. William Lynch; Steve W. Manzuik; Ryan Permeh; Ken Pfeil; Ryan Russell
This chapter illustrates vulnerability resource methodologies. It also discusses the importance of source code reviews, reverse engineering technologies, and black box testing. In the case of vulnerability research challenges, the resources used to tackle a problem may be code, time, or tools. In some cases, reading the source code may be the simplest way for them to determine whether or not there are vulnerabilities; much vulnerability are tied to particular language functions or ways of calling external functions. The source code often gives the clearest picture of how this happens in a given program. Another method of determining how a program works, and therefore whether there are holes, is reverse engineering, which may require special tools, such as disassemblers and debuggers. The last method is black box testing. Black box testing permits only for the manipulation of the inputs and the viewing of a given system outputs, without the internals being known. In some cases, black box testing may be the sole method initially available. In other cases, it may be employed to aid choose where to focus further efforts.
Archive | 2002
David R. Mirza Ahmad; Ido Dubrawsky; Hal Flynn; Joe Grand; Robert Graham; Norris L. Johnson; F. William Lynch; Steve W. Manzuik; Ryan Permeh; Ken Pfeil; Ryan Russell
The term diffing refers to the comparison of a program, library, or other file before and after some action. It is one of the simplest hacking techniques. It is extensively employed during security research, often to the point that it is not thought of as a separate step. Diffing can be done at the disk, file, and database levels. At the disk level, one can discover which files have been modified. At the file level, one can discover which bytes have been changed. At the database level, one can discover which records are different. This helps in discovering how to manipulate the data outside of the application for which it is intended. The diff utility predates many of the modern UNIX and UNIX-clone operating systems, appearing originally in the UNIX implementation distributed by ATT whether or not a binary is different from another claiming to be the same; or how a data file used by a program has changed from one operation to another.