DOCSLIB.ORG

The Security Layer

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Security Layer Brigham Young University BYU ScholarsArchive Theses and Dissertations 2019-01-01 The Security Layer Mark Thomas O'Neill Brigham Young University Follow this and additional works at: https://scholarsarchive.byu.edu/etd Part of the Computer Sciences Commons BYU ScholarsArchive Citation O'Neill, Mark Thomas, "The Security Layer" (2019). Theses and Dissertations. 7761. https://scholarsarchive.byu.edu/etd/7761 This Dissertation is brought to you for free and open access by BYU ScholarsArchive. It has been accepted for inclusion in Theses and Dissertations by an authorized administrator of BYU ScholarsArchive. For more information, please contact [email protected], [email protected]. The Security Layer Mark Thomas O'Neill A dissertation submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Doctor of Philosophy Daniel Zappala, Chair Kent Seamons Michael Goodrich Tony Martinez Ryan Farrell Department of Computer Science Brigham Young University Copyright c 2018 Mark Thomas O'Neill All Rights Reserved ABSTRACT The Security Layer Mark Thomas O'Neill Department of Computer Science, BYU Doctor of Philosophy Transport Layer Security (TLS) is a vital component to the security ecosystem and the most popular security protocol used on the Internet today. Despite the strengths of the protocol, numerous vulnerabilities result from its improper use in practice. Some of these vulnerabilities arise from weaknesses in authentication, from the rigidity of the trusted authority system to the complexities of client certificates. Others result from the misuse of TLS by developers, who misuse complicated TLS libraries, improperly validate server certificates, employ outdated cipher suites, or deploy other features insecurely. To make matters worse, system administrators and users are powerless to fix these issues, and lack the ability to properly control how their own machines communicate securely online. In this dissertation we argue that the problems described are the result of an improper placement of security responsibilities. We show that by placing TLS services in the operating system, both new and existing applications can be automatically secured, developers can easily use TLS without intimate knowledge of security, and security settings can be controlled by administrators. This is demonstrated through three explorations that provide TLS features through the operating system. First, we describe and assess TrustBase, a service that repairs and strengthens certificate-based authentication for TLS connections. TrustBase uses traffic interception and a policy engine to provide administrators fine-tuned control over the trust decisions made by all applications on their systems. Second, we introduce and evaluate the Secure Socket API (SSA), which provides TLS as an operating system service through the native POSIX socket API. The SSA enables developers to use modern TLS securely, with as little as one line of code, and also allows custom tailoring of security settings by administrators. Finally, we further explore a modern approach to TLS client authentication, leveraging the operating system to provide a generic platform for strong authentication that supports easy deployment of client authentication features and protects user privacy. We conclude with a discussion of the reasons for the success of our efforts, and note avenues for future work that leverage the principles exhibited in this work, both in and beyond TLS. Keywords: SSL, TLS, man in the middle, certificate, OpenSSL, security, operating system, administrator control, kernel security, policy, certificates, transport layer security, secure sock- ets layer, developer mistakes, vulnerabilities, client authentication, DANE, OSCP, CRLSet, CRL, Convergence, notary, POSIX, socket API, API ACKNOWLEDGMENTS I'd like to thank my advisor, Daniel Zappala, for allowing me the freedom to pursue my degree in the way and areas I wanted. His immediate, unsolicited, and unending support of me and my ideas was a great source of confidence and encouragement, especially during the most frustrating times. A small army of peers assisted me in the development of the works described in this dissertation: Benjamin Davis, Dan Bunker, Elham Vaziripour, Jordan Whitehead, Joshua Reynolds, Justin Wu, Luke Dickinson, Mason Coram, Nick Bonner, Scott Heidbrink, Tanner Perdue, Torstein Collett, and Travis Hendershot. Their work has been exemplary, and I'm proud to call every single one of them my friend. A special thanks goes to Scott Heidbrink, who worked with me from the time this dissertation was a mere fantasy, through its publications, obtaining his master's degree in the process. His dedication, expertise, and wit, did not go unnoticed and will be missed. Another special thanks goes to my fellow PhD students, Elham Vaziripour and Justin Wu, whose companionship during fun weekend outings and all-nighters in the lab will be forever remembered. I'd also like to thank those who were involved behind the scenes, including Jen Bonnett, whose help none of us graduate students could graduate without, and all of the babysitters who volunteered their time to watch my son as I worked. Most of all, I'd like to thank my wife, Leah, who sacrificed her time and talents to support me both financially and mentally during these years. Finally, I want to thank the National Science Foundation, the Department of Homeland Security, and Sandia National Laboratories, for their interest and financial support of this work. Table of Contents List of Figures x List of Tables xii 1 Introduction 1 1.1 TLS Server Authentication . .2 1.1.1 Background . .2 1.1.2 Problems in Practice . .3 1.2 Using TLS in Applications . .7 1.2.1 Background . .7 1.2.2 Problems in Practice . .8 1.3 TLS Client Authentication . .9 1.3.1 Background . .9 1.3.2 Problems in Practice . 11 1.4 Synthesis . 13 1.5 Solution: A Well-formed Security Layer . 15 2 TrustBase 19 2.1 Abstract . 19 2.2 Introduction . 20 2.3 Related Work . 24 2.4 TrustBase . 26 2.4.1 Threat Model . 26 iv 2.4.2 Design Goals . 27 2.4.3 Architecture . 28 2.4.4 Addressing Certificate Pinning . 31 2.4.5 TLS 1.3 and Overriding the CA System . 32 2.4.6 Operating System Support . 33 2.5 Linux Implementation . 34 2.5.1 Traffic Interceptor . 35 2.5.2 TLS Handler . 38 2.5.3 Opportunistic TLS Handler . 39 2.5.4 Policy Engine . 40 2.6 Security Analysis . 40 2.6.1 Centralization . 40 2.6.2 Coverage . 41 2.6.3 Threat Analysis . 42 2.6.4 Hardening . 44 2.7 Evaluation . 46 2.7.1 Performance . 46 2.7.2 Compatibility . 48 2.7.3 Android Prototype . 49 2.7.4 Windows Prototype . 51 2.7.5 Utility . 52 2.8 Future Work . 52 2.9 Conclusion . 54 3 The Secure Socket API 55 3.1 Abstract . 55 3.2 Introduction . 56 3.3 Motivation . 58 v 3.4 SSA Design Goals . 59 3.5 OpenSSL Analysis . 61 3.5.1 Version Selection . 62 3.5.2 Cipher Suite Selection . 63 3.5.3 Extension Management . 64 3.5.4 Certificate/Key Management . 64 3.5.5 Certificate Validation . 65 3.5.6 Session Management . 66 3.5.7 Configuration . 66 3.5.8 Non-TLS Protocol Specific Functions . 67 3.6 The Secure Socket API . 68 3.6.1 Usage . 68 3.6.2 Administrator Options . 71 3.6.3 Developer Options and Use Cases . 74 3.6.4 Porting Applications to the SSA . 76 3.6.5 Language Support . 77 3.6.6 TLS 1.3 0-RTT . 79 3.7 Implementation Details . 79 3.7.1 Basic Operation . 81 3.7.2 Performance . 83 3.8 Coercing Existing Applications . 85 3.9 Discussion . 87 3.9.1 General Benefits . 87 3.9.2 Implementation Benefits . 88 3.9.3 Configuration Considerations . 89 3.9.4 Alternative Implementations . 89 3.9.5 Security Analysis . 90 vi 3.10 Limitations and Future Work . 92 3.11 Related Work . 93 3.12 Conclusion . 94 4 Modernizing TLS Client Authentication 96 4.1 Abstract . 96 4.2 Introduction . 97 4.3 Background . 99 4.3.1 Typical TLS handshake . 99 4.3.2 Handshake with Client Authentication . 100 4.3.3 TLS 1.3 Advances . 101 4.3.4 Secure Socket API . 103 4.4 Problems . 104 4.4.1 Servers and Administration . 104 4.4.2 Clients and Users . ..
Load more

Recommended publications
  • Email Transport Encryption STARTTLS Vs. DANE Vs. MTA-STS
    Email Transport Encryption STARTTLS vs. DANE vs. MTA-STS Delimitation This document deals with the encrypted transport of messages between two email servers. Encryption during transport is crucial for a basic level of security for the exchange of messages. The exchange of messages between an email client and a server or the end-to-end encryption of messages are not covered in this article. If the aim is to create a secure overall system, these aspects should be considered in addition to the recommendations in this article. Initial situation When the first standard for the Simple Mail Transfer Protocol (in short: SMTP) was adopted, encryption of the transport was not included. All messages were exchanged as plain text between the servers. They were thus basically readable for anyone who could tap into the data exchange between the two servers. This only changed with the introduction of the SMTP Service Extensions for Extend SMTP (ESMTP for short), which made it possible to choose encrypted transport as an opportunistic feature of data exchange. Opportunistic, because it had to be assumed that not all servers would be able to handle transport encryption. They should only encrypt when it is opportune; encryption is not mandatory. To indicate the basic ability to encrypt to a sending server, it was agreed that the receiving server should send the keyword STARTTLS at the beginning of an ESMTP transport session. STARTTLS STARTTLS can encrypt the transport between two email servers. The receiving server signals the sending server that it is capable of encrypting after a connection is established and in the ESMTP session.
    [Show full text]
  • File Transfer Documentation
    LRS File Transfer Service Version 2 User Guide October 27, 2017 Introduction The LRS® File Transfer Service offers customers a secure way to send and receive files using HTTPS or FTPS protocols. This can help when working with LRS support staff, for example, in instances where you need to transmit files for troubleshooting or other support functions. The service supports the LRS Privacy Policy. If you want to read the LRS Privacy Policy, you can reach it from nearly any LRS web page. Just click the Online Privacy Policy link to read the complete company policy. You can also find the Privacy Policy at the following address: http://www.lrs.com/privacy-policy. This document explains the various file transfer options available and the steps required to send and/or receive files using the LRS File Transfer Service. Please refer to the following sections for more information about the system: File transfer options: HTTPS and FTPS 2 Sending a file to LRS via the File Transfer Service 3 Sending files via secured HTTPS 5 Sending files using FTP or secured FTPS 6 Receiving a file from the LRS File Transfer Service 8 File transfer options: HTTPS and FTPS Depending on the size of the file being transmitted, you may opt to use either the browser-based HTTPS protocol or the FTPS protocol, which requires the use of a file transfer client program. File sizes of up to 25GB can be transmitted via the secure HTTPS protocol using the LRS File Transfer Service. You can perform HTTPS-based transfers using most popular browsers, including Internet Explorer, Edge, Google Chrome, or Firefox.
    [Show full text]
  • MTA STS Improving Email Security.Pdf
    Improving Email Security with the MTA-STS Standard By Brian Godiksen An Email Best Practices Whitepaper CONTENTS Executive Overview 03 Why Does Email Need Encryption in Transit? 04 The Problem with “Opportunistic Encryption” 07 The Anatomy of a Man-in-the-Middle Attack 08 The Next Major Step with Email Encryption: MTA-STS 10 What Steps Should Senders Take to Adopt MTA-STS? 11 About SocketLabs 12 Brian Godiksen Brian has been helping organizations optimize email deliverability since joining SocketLabs in 2011. He currently manages a team of deliverability analysts that consult with customers on best infrastructure practices, including email authentication implementation, bounce processing, IP address warm-up, and email marketing list management. Brian leads the fight against spam and email abuse at SocketLabs by managing compliance across the platform. He is an active participant in key industry groups such as M3AAWG and the Email Experience Council. You can read more of Brian’s content here on the SocketLabs website. ©2019 SocketLabs 2 Executive The Edward Snowden leaks of 2013 opened many peoples’ eyes to the fact that mass surveillance was possible by Overview intercepting and spying on email transmissions. Today, compromised systems, database thefts, and technology breaches remain common fixtures in news feeds around the world. As a natural response, the technology industry is rabidly focused on improving the security and encryption of communications across all platforms. Since those early days of enlightenment, industry experts have discussed and attempted a variety of new strategies to combat “pervasive monitoring” of email channels. While pervasive monitoring assaults can take many forms, the most prominent forms of interference were man-in-the-middle (MitM) attacks.
    [Show full text]
  • HTTP2 Explained
    HTTP2 Explained Daniel Stenberg Mozilla Corporation [email protected] ABSTRACT credits to everyone who helps out! I hope to make this document A detailed description explaining the background and problems better over time. with current HTTP that has lead to the development of the next This document is available at http://daniel.haxx.se/http2. generation HTTP protocol: HTTP 2. It also describes and elaborates around the new protocol design and functionality, 1.3 License including some implementation specifics and a few words about This document is licensed under the the future. Creative Commons Attribution 4.0 This article is an editorial note submitted to CCR. It has NOT license: been peer reviewed. The author takes full responsibility for this http://creativecommons.org/licenses/by/4.0/ article’s technical content. Comments can be posted through CCR Online. 2. HTTP Today Keywords HTTP 1.1 has turned into a protocol used for virtually everything HTTP 2.0, security, protocol on the Internet. Huge investments have been done on protocols and infrastructure that takes advantage of this. This is taken to the 1. Background extent that it is often easier today to make things run on top of HTTP rather than building something new on its own. This is a document describing http2 from a technical and protocol level. It started out as a presentation I did in Stockholm in April 2014. I've since gotten a lot of questions about the contents of 2.1 HTTP 1.1 is Huge that presentation from people who couldn't attend, so I decided to When HTTP was created and thrown out into the world it was convert it into a full-blown document with all details and proper probably perceived as a rather simple and straight-forward explanations.
    [Show full text]
  • Curl User Survey 2019 Analysis
    curl user survey 2019 analysis “there are so many useful features” summary and analysis by Daniel Stenberg version 1 - June 4, 2019 Table of Contents About curl.............................................................................................................................................3 Survey Background..........................................................................................................................3 Number of responses............................................................................................................................4 Returning respondents?........................................................................................................................5 Users living where?..............................................................................................................................6 What kind of users?..............................................................................................................................7 What protocols......................................................................................................................................8 Multiple platforms..............................................................................................................................10 What platforms...................................................................................................................................11 Which Windows versions...................................................................................................................13
    [Show full text]
  • Ftp Vs Http Protocol
    Ftp Vs Http Protocol Unilobed Bentley unstrings reportedly while Durand always waul his stigmatists lull remittently, he dozing so asymmetrically. When Stuart ad-lib his ageings bumble not centrically enough, is Bryant definite? Jerold often appraised wearily when corruptible Tomlin blackouts balefully and expiate her Libyan. FTP stands for File Transfer Protocol used to transfer files online. To ensure the functionality of the Sophos Web Appliance, configure your network to allow access on the ports listed below. Syntax error in any data since a time when and passive mode, when a tcp connection and get closed prematurely or http or other end the parent directory. What is File Transfer Protocol FTP What she My IP Address. Why FTPFTPSSFTP file transport related protocols are not mentioned but used HTTPS As did general concepts PUTGET are more FTP related requests. Using ftp protocol relatively easy to the protocols can just serve other. The ftp vs protocol, not to the protocol. Expand your ftp vs https protocols offer the size can use in the server needs to the latest version. This ftp vs http is specifically remember the protocols with ftps: it is not at once authenticated and services similar. Rfcs are ftp protocol at this https protocols in the ass with. Smtp server ftp protocol runs on http does it has rules to https because data packets are on. To begin a characterbased command session on a Windows computer, follow these steps. The web server sends the requested content really a response message. XML and JSON and learned that kid are custom data formats indeed.
    [Show full text]
  • Ftp Port Number and Protocol
    Ftp Port Number And Protocol Flavorful Willey transport decani. High-key Alix shackle cold. Isidore knelt her papyrus misapprehensively, she cables it inveterately. FTP is a protocol specifically used to transfer files. Do this point command may negatively impact your browser. Ip address of these client? An ip network services, disregarding transfer a data through a remote ftp, but not supported by using a single location in which represents information. The default FTP port is TCP 21 TCP is a transmission level protocol that provides reliable data frame between hosts FTP port can be. Client picks a new port number each quality and sends a PORT command announcing that opinion the server. It should also has two incompatible variants of numbers that a number of these ports you are precisely accurate. Grab the White paper and contain your options along that specific needs for our environment. Service truck and Transport Protocol Port Number Registry. FTP is used to make changes to a website. The first fuel of each line nearly the Fortran format control character. The server responds to make temporary client port. Which destination Transport-layer protocol and port number leave a TFTP client use to. Ftp server passive ftp or delete, server system administrators can fix this example results in. All connections for a number of numbers, link tracking code? PORT Character string allowing the port number used to be specified. Ftp and may substitute cream of ports for students, these cases however, which ftp commands. Default Network Ports for EFT and DMZ Gateway. Ftp uses rpc over an official protocol number it for ftp defines ftp? IBM Knowledge Center.
    [Show full text]
  • SSL Reference Manual
    HP NonStop SSL Reference Manual HP Part Number: 628203-009 Published: January 2014 Edition: HP NonStop SSL Reference Manual 1.8 H06.07 and subsequent H-series RVUs J06.01 and subsequent J-series RVUs Hewlett Packard Company 3000 Hanover Street Palo Alto, CA 94304-1185 © 2014 HP All rights reserved © Copyright 2014 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Export of the information contained in this publication may require authorization from the U.S. Department of Commerce. Microsoft, Windows, and Windows NT are U.S. registered trademarks of Microsoft Corporation. Intel, Pentium, and Celeron are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Java is a U.S. trademark of Sun Microsystems, Inc. Motif, OSF/1, UNIX, X/Open, and the "X" device are registered trademarks, and IT DialTone and The Open Group are trademarks of The Open Group in the U.S. and other countries. Open Software Foundation, OSF, the OSF logo, OSF/1, OSF/Motif, and Motif are trademarks of the Open Software Foundation, Inc.
    [Show full text]
  • Communication & Network Security
    6/13/19 Communication & Network Security MIS-5903 http://community.mis.temple.edu/mis5903sec011s17/ OSI vs. TCP/IP Model • Transport also called Host-to-Host in TCP/IP model. Encapsulation • System 1 is a “subject” (client) • System 2 has the “object” (server) 1 6/13/19 OSI Reference Notice: • Segments • Packets (Datagrams) • Frames • Bits Well known ports Protocol TCP/UDP Port Number File Transfer Protocol (FTP) (RFC 959) TCP 20/21 Secure Shell (SSH) (RFC 4250-4256) TCP 22 Telnet (RFC TCP 23 854) Simple Mail Transfer Protocol (SMTP) (RFC 5321) TCP 25 Domain Name System (DNS) (RFC 1034-1035) TCP/UDP 53 Dynamic Host Configuration Protocol (DHCP) (RFC 2131) UDP 67/68 Trivial File Transfer Protocol (TFTP) (RFC 1350) UDP 69 Hypertext Transfer Protocol (HTTP) (RFC 2616) TCP 80 Post Office Protocol (POP) version 3 (RFC 1939) TCP 110 Network Time Protocol (NTP) (RFC 5905) UDP 123 NetBIOS (RFC TCP/UDP 1001-1002) 137/138/139 Internet Message Access Protocol (IMAP) (RFC 3501) TCP 143 Well known ports (continued) Protocol TCP/UDP Port Number Simple Network Management Protocol (SNMP) UDP (RFC 1901-1908, 3411-3418) 161/162 Border Gateway Protocol (BGP) (RFC 4271) TCP 179 Lightweight Directory Access Protocol (LDAP) (RFC 4510) TCP/UDP 389 Hypertext Transfer Protocol over SSL/TLS (HTTPS) (RFC 2818) TCP 443 Line Print Daemon (LPD) TCP 515 Lightweight Directory Access Protocol over TLS/SSL (LDAPS) (RFC 4513) TCP/UDP 636 FTP over TLS/SSL (RFC 4217) TCP 989/990 Microsoft SQL Server TCP 1433 Oracle Server TCP 1521 Microsoft Remote Desktop Protocol (RDP) TCP 3389 • http://www.iana.org/assignments/service-names-port- numbers/service-names-port-numbers.xml.
    [Show full text]
  • Empfehlungen Für Den Einsatz Von Transportverschlüsselung Zwischen Mailservern
    Empfehlungen für den Einsatz von Transportverschlüsselung zwischen Mailservern 11.08.2017 Empfehlungen für Transportverschlüsselung zwischen Mailservern Seite 2 von 19 Dokument-Informationen Autoren Antje Bendrich, Jürgen Brauckmann, Lars Weber, Marc Thomas, Stefan Kelm Dateiname smtp-transportverschluesslung.pdf letzte Bearbeitung 15. August 2017 Seitenzahl 19 Version Datum Autor(en) Änderungen 0.1 1.1.1970 Marc Thomas Formatvorlage 0.2 28.11.2016 Marc Thomas Struktur, Inhalt 0.3 07.12.2016 Lars Weber Kapitel 2.4, 3 0.4 24.02.2017 Marc Thomas Kapitel 4 0.5 27.03.2017 Stefan Kelm QA 0.6 28.03.2017 Antje Bendrich QA 0.7 01.06.2017 Jürgen Brauckmann QA 0.8 13.06.2017 Lars Weber Kapitel 2.4.3 0.9 11.08.2017 Lars Weber Kapitel 2.4 überarbeitet ©2017 by DFN-CERT Services GmbH / All Rights reserved. Stand: 11.08.2017 Empfehlungen für Transportverschlüsselung zwischen Mailservern Seite 3 von 19 Inhaltsverzeichnis 1. Einleitung 4 2. TLS-Konfiguration 4 2.1. SSL/TLS-Protokolle . .5 2.2. SSL/TLS-Algorithmen . .6 2.3. SSL/TLS-Parameter . .7 2.4. MTA-Konfiguration . .8 2.4.1. Grenzen der Konfiguration . .8 2.4.2. Postfix . .9 2.4.3. Exim . 11 3. DNS-based Authentication of Named Entities (DANE) 14 3.1. Postfix . 15 3.2. Exim . 15 4. Best-Practices-Konfiguration 16 4.1. Postfix . 16 4.2. Exim . 17 A. Quellen 19 ©2017 by DFN-CERT Services GmbH / All Rights reserved. Stand: 11.08.2017 Empfehlungen für Transportverschlüsselung zwischen Mailservern Seite 4 von 19 1. Einleitung Moderne Bürokommunikation läuft zum großen Teil über E-Mail.
    [Show full text]
  • Applied Crypto Hardening
    Applied Crypto Hardening Wolfgang Breyha, David Durvaux, Tobias Dussa, L. Aaron Kaplan, Florian Mendel, Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, Berg San, Ralf Schlatterbeck, Thomas Schreck, Alexander Würstlein, Aaron Zauner, Pepi Zawodsky (University of Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, coretec.at,FH Campus Wien, VRVis, MilCERT Austria, A-Trust, Runtux.com,Friedrich-Alexander University Erlangen-Nuremberg, azet.org, maclemon.at) April 25, 2017 Contents 1. Abstract 5 1.1. Acknowledgements ........................................ 6 2. Introduction 8 2.1. Audience .............................................. 8 2.2. Related publications ........................................ 8 2.3. How to read this guide ....................................... 8 2.4. Disclaimer and scope ........................................ 9 2.4.1. Scope ............................................ 10 2.5. Methods ............................................... 11 3. Practical recommendations 12 3.1. Webservers ............................................. 12 3.1.1. Apache ........................................... 12 3.1.2. lighttpd ........................................... 13 3.1.3. nginx ............................................ 14 3.1.4. Cherokee .......................................... 15 3.1.5. MS IIS ............................................ 17 3.2. SSH ................................................. 20 3.2.1. OpenSSH .......................................... 20 3.2.2. Cisco ASA .........................................
    [Show full text]
  • Network Vulnerability Scan with Openvas Report
    Network Vulnerability Scan with OpenVAS Report 10.8.0.1 (Metasploitable2) Summary Overall risk level: High Risk ratings: High: 13 Medium: 20 Low: 69 Info: 1 Scan information: Start time: 2018-03-02 11:24:54 Finish time: 2018-03-02 12:02:48 Scan duration: 37 min, 54 sec Tests performed: 103/103 Scan status: Finished Findings Check for rexecd Service (port 512/tcp) The rexecd Service is not allowing connections from this host. Details Risk description: Rexecd Service is running at this Host. Rexecd (Remote Process Execution) has the same kind of functionality that rsh has : you can execute shell commands on a remote computer. The main difference is that rexecd authenticate by reading the username and password *unencrypted* from the socket. Recommendation: Disable rexec Service. Read more about this issue: https//web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-0618 Check for rlogin Service (port 513/tcp) The service is misconfigured so it is allowing conntections without a password. Details Risk description: rlogin has several serious security problems, - All information, including passwords, is transmitted unencrypted. - .rlogin (or .rhosts) file is easy to misuse (potentially allowing anyone to login without a password) Impact Level: System This remote host is running a rlogin service. Recommendation: Disable rlogin service and use ssh instead. Read more about this issue: https//web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-0651 https//web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-0651 http//en.wikipedia.org/wiki/Rlogin http//www.ietf.org/rfc/rfc1282.txt DistCC Detection (port 3632/tcp) No evidence Details Risk description: DistCC is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network.
    [Show full text]