Challenging RSA Cryptosystem Implementations

Total Page:16

File Type:pdf, Size:1020Kb

Challenging RSA Cryptosystem Implementations Ca’ Foscari University of Venice and Masaryk University 1 Challenging RSA cryptosystem implementations Doctoral Thesis Matúš Nemec Doctorate Coordinator Advisor (Masaryk University) Prof. Riccardo Focardi Prof. Vashek Matyáš Advisor (Ca’ Foscari University) Consultant Prof. Riccardo Focardi Doc. Petr Švenda Cycle: 32 Semester: Fall 2019 Matricola: 956333 UČO: 396066 SSD: INF/01 Informatica Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Matúš Nemec Advisor (Ca’ Foscari University of Venice): Prof. Riccardo Focardi Advisor (Masaryk University): Prof. Vashek Matyáš Consultant (Masaryk University): Doc. Petr Švenda i Acknowledgements I would like to thank Vashek Matyáš, Riccardo Focardi, Petr Švenda, and Marek Sýs for their guidance and advice. I am thankful to all my co-authors for their fantastic work, and to all the members of CRoCS and ACADIA groups for creating a welcoming atmosphere. I much appreciate the help of Nicola Miotello and Ada Nazarejová with going through the red tape. Last but not least, this thesis would not be possible without the support of my family and friends. iii Abstract The aim of our research was to study security properties of real- world deployments of the RSA cryptosystem. First we analyze RSA key generation methods in cryptographic libraries. We show a prac- tical application of biases in RSA keys for measuring popularity of cryptographic libraries and we develop a factorization method that breaks a proprietary key generation algorithm. Later we examine published implementation issues in the TLS protocol, such as RSA padding oracles, in the wider context of the Web ecosystem. The main conclusion of our previous research on RSA keys was that libraries leak information about their key generation algorithms through the public keys. The bias in the key is often sufficient to identify a library that likely generated the key. In this thesis, we fur- ther demonstrate a practical method for measuring representation of cryptographic libraries in large datasets of RSA public keys. We use statistical inference to approximate a share of libraries matching an observed distribution of RSA keys in an inspected dataset. Such esti- mate also allows us to deploy an improved key classification method that uses prior probabilities of libraries to more accurately determine the source of a key. Next we adapt a key factorization attack to keys generated by a widely deployed proprietary cryptographic library. Our previous re- search hinted at issues in the algorithm by showing an unusual bias in the keys. We reveal the algorithm without the access to the source code by analyzing algebraic properties of the keys. We develop a practical factorization attack that can compute private keys corresponding to the public keys used in electronic identification documents, Trusted Platform Modules, authentication tokens, and other domains that use secure chips with this RSA key generation algorithm. Our findings were disclosed in coordination with the manufacturer of the devices to minimize the resulting security threats. Finally, we focus on implementation issues in the TLS protocol, of which RSA key exchange is an integral part. We survey existing practical attacks that affect current usage of TLS for securing the Web. We specify conditions for the attacks as attack trees. Using measure- ments on popular domains, we confirm that RSA padding oracles are iv currently the most common threat. We show how such security issues get amplified by the complexity of the Web ecosystem. In many cases of vulnerable websites, the issues are caused by external or related- domain hosts. Our work helps to demonstrate how RSA, a seemingly simple and intuitive cryptosystem, requires a lot of knowledge to be implemented correctly. Unlike RSA, elliptic curve cryptography (ECC) uses random sequences as keys and does not require padding. It is more resistant to bad user configurations and provides many other benefits. We conclude that practitioners should follow the example of TLS version 1.3 and stop using RSA in favor of ECC. v Keywords Bleichenbacher’s oracle, Coppersmith’s algorithm, cryptographic li- brary, cryptographic protocol, factorization, key generation, RSA, TLS vi Contents 1 Introduction1 1.1 Problem statement ......................2 1.2 Contributions .........................3 1.2.1 Biased RSA key generation methods.......3 1.2.2 Vulnerabilities in RSA key generation......3 1.2.3 TLS protocol vulnerabilities............4 1.3 Structure of the thesis .....................5 2 State of the art7 2.1 Survey of RSA key generation methods ............7 2.2 Bias in RSA primes and keys .................8 2.2.1 RSA prime types..................9 2.2.2 RSA keypairs....................9 2.2.3 Modular bias.................... 10 2.3 Pseudo-random number generator failures .......... 10 3 Measuring popularity of cryptographic libraries 13 3.1 Introduction .......................... 14 3.2 Method overview ....................... 17 3.2.1 Choice of key features............... 17 3.2.2 Clustering analysis................. 18 3.2.3 Dataset classification – original approach.... 20 3.2.4 Dataset classification – our approach....... 20 3.2.5 Limitations..................... 22 3.3 Methodology in detail ..................... 23 3.3.1 Model........................ 23 3.3.2 Prior probability estimation............ 23 3.3.3 Key classification.................. 24 3.3.4 Evaluation of accuracy............... 24 3.3.5 Additional accuracy considerations....... 28 3.4 Results on relevant datasets .................. 31 3.4.1 Data preparation.................. 31 3.4.2 Internet-wide TLS scans.............. 35 3.4.3 Popularity between usage domains........ 37 3.4.4 TLS to CT comparison............... 37 vii 3.4.5 Detection of transient events........... 38 3.5 Related work .......................... 40 3.6 Additional results ....................... 41 3.7 Conclusions .......................... 42 4 Factorization of widely used RSA moduli 47 4.1 Introduction .......................... 47 4.2 Fingerprinting and factorization ............... 51 4.2.1 Format of the constructed primes......... 52 4.2.2 Fingerprinting.................... 53 4.2.3 Factorization – attack principle.......... 55 4.2.4 Coppersmith’s algorithm in detail........ 57 4.2.5 Application of Coppersmith’s algorithm.... 60 ∗ 4.2.6 Computing the order of a generator in ZM0 ... 61 4.2.7 Optimization of the parameters M0, m, t ..... 62 4.2.8 Guessing strategy.................. 68 4.3 Practical implementation ................... 69 4.3.1 Details and empirical evaluation......... 69 4.3.2 Possible improvements and limitations..... 69 4.4 Analysis of impacts ...................... 71 4.4.1 Summary of results................. 73 4.4.2 Electronic identity documents.......... 74 4.4.3 Code signing.................... 76 4.4.4 Trusted Platform Modules............. 77 4.4.5 PGP with cryptographic tokens.......... 80 4.4.6 TLS and SCADA-related keys........... 82 4.4.7 Certification authorities.............. 83 4.4.8 Generic Java Card platform............ 83 4.4.9 Other domains................... 85 4.5 Mitigation and disclosure ................... 85 4.5.1 Mitigation...................... 86 4.5.2 Future prevention and analysis.......... 88 4.5.3 Responsible disclosure............... 89 4.6 Related work .......................... 90 4.7 Conclusions .......................... 91 5 Amplification of TLS vulnerabilities on the Web 93 5.1 Introduction .......................... 93 viii 5.2 Background on TLS ...................... 98 5.2.1 The Handshake Protocol.............. 98 5.2.2 Ciphersuites..................... 100 5.3 Attack trees for TLS security ................. 101 5.3.1 Threat model.................... 101 5.3.2 Review of known attacks against TLS...... 102 5.3.3 Insecure channels.................. 105 5.3.4 Leaky channels................... 105 5.3.5 Tainted channels.................. 108 5.3.6 Partially leaky channels.............. 109 5.4 Experimental setup ...................... 110 5.4.1 Analysis platform.................. 110 5.4.2 Data collection and findings............ 111 5.4.3 Roadmap...................... 113 5.5 Page integrity ......................... 114 5.5.1 Security analysis.................. 114 5.5.2 Experimental results................ 116 5.6 Authentication credentials .................. 118 5.6.1 Security analysis.................. 118 5.6.2 Experimental results................ 121 5.6.3 Detected attacks.................. 123 5.7 Web tracking ......................... 124 5.7.1 Security analysis.................. 124 5.7.2 Experimental results................ 126 5.8 Closing remarks ........................ 127 5.8.1 Related work.................... 127 5.8.2 Ethics and limitations............... 128 5.8.3 Summary and perspective............. 129 5.9 Additional results ....................... 130 5.9.1 Notable out of scope attacks against TLS.... 130 5.9.2 More detailed attack trees............. 134 6 Conclusions 139 Bibliography 143 A Author’s publications 167 ix 1 Introduction The RSA cryptosystem predates most currently used cryptographic libraries. It is often a necessary part of a new library and perhaps one of the first features to be implemented. In a survey of RSA key generation implementations [Šve+16a], we saw how the source code for RSA in community-driven
Recommended publications
  • Alcatel-Lucent Security Advisory Sa0xx
    Alcatel-Lucent Security Advisory No. SA0053 Ed. 04 Information about Poodle vulnerability Summary POODLE stands for Padding Oracle On Downgraded Legacy Encryption. The POODLE has been reported in October 14th 2014 allowing a man-in-the-middle attacker to decrypt ciphertext via a padding oracle side-channel attack. The severity is not considered as the same for Heartbleed and/or bash shellshock vulnerabilities. The official risk is currently rated Medium. The classification levels are: Very High, High, Medium, and Low. The SSLv3 protocol is only impacted while TLSv1.0 and TLSv1.2 are not. This vulnerability is identified CVE- 2014-3566. Alcatel-Lucent Enterprise voice products using protocol SSLv3 are concerned by this security alert. Openssl versions concerned by the vulnerability: OpenSSL 1.0.1 through 1.0.1i (inclusive) OpenSSL 1.0.0 through 1.0.0n (inclusive) OpenSSL 0.9.8 through 0.9.8zb (inclusive) The Alcatel-Lucent Enterprise Security Team is currently investigating implications of this security flaw and working on a corrective measure, for OpenTouch 2.1.1 planned in Q4 2015, to prevent using SSLv3 that must be considered as vulnerable. This note is for informational purpose about the padding-oracle attack identified as “POODLE”. References CVE-2014-3566 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 Advisory severity CVSS Base score : 4.3 (MEDIUM) - AV:N/AC:M/Au:N/C:P/I:N/A:N https://www.openssl.org/news/secadv_20141015.txt https://www.openssl.org/~bodo/ssl-poodle.pdf Description of the vulnerabilities Information about Poodle vulnerability (CVE-2014-3566).
    [Show full text]
  • Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities
    Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities Robert Merget and Juraj Somorovsky, Ruhr University Bochum; Nimrod Aviram, Tel Aviv University; Craig Young, Tripwire VERT; Janis Fliegenschmidt and Jörg Schwenk, Ruhr University Bochum; Yuval Shavitt, Tel Aviv University https://www.usenix.org/conference/usenixsecurity19/presentation/merget This paper is included in the Proceedings of the 28th USENIX Security Symposium. August 14–16, 2019 • Santa Clara, CA, USA 978-1-939133-06-9 Open access to the Proceedings of the 28th USENIX Security Symposium is sponsored by USENIX. Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities Robert Merget1, Juraj Somorovsky1, Nimrod Aviram2, Craig Young3, Janis Fliegenschmidt1, Jörg Schwenk1, and Yuval Shavitt2 1Ruhr University Bochum 2Department of Electrical Engineering, Tel Aviv University 3Tripwire VERT Abstract the encryption key. The attack requires a server that decrypts a message and responds with 1 or 0 based on the message va- The TLS protocol provides encryption, data integrity, and lidity. This behavior essentially provides the attacker with a authentication on the modern Internet. Despite the protocol’s cryptographic oracle which can be used to mount an adaptive importance, currently-deployed TLS versions use obsolete chosen-ciphertext attack. The attacker exploits this behavior cryptographic algorithms which have been broken using var- to decrypt messages by executing adaptive queries.Vaudenay ious attacks. One prominent class of such attacks is CBC exploited a specific form of vulnerable behavior, where im- padding oracle attacks. These attacks allow an adversary to plementations validate the CBC padding structure and re- decrypt TLS traffic by observing different server behaviors spond with 1 or 0 accordingly.
    [Show full text]
  • Technical Report RHUL–ISG–2019–1 27 March 2019
    20 years of Bleichenbacher attacks Gage Boyle Technical Report RHUL–ISG–2019–1 27 March 2019 Information Security Group Royal Holloway University of London Egham, Surrey, TW20 0EX United Kingdom Student Number: 100866673 Gage, Boyle 20 Years of Bleichenbacher Attacks Supervisor: Kenny Paterson Submitted as part of the requirements for the award of the MSc in Information Security at Royal Holloway, University of London. I declare that this assignment is all my own work and that I have acknowledged all quotations from published or unpublished work of other people. I also declare that I have read the statements on plagiarism in Section 1 of the Regulations Governing Examination and Assessment Offences, and in accordance with these regulations I submit this project report as my own work. Signature: Date: Acknowledgements I would first like to thank my project supervisor, Kenny Paterson. This project would not have been possible without his continuous encouragement to push the boundaries of my knowledge, and I am grateful for the commitment and expertise that he has provided throughout. Secondly, I would like to thank Nimrod Aviram for his invaluable advice, particularly with respect to algorithm implementation and understanding the finer details of this project. Further thanks should go to Raja Naeem Akram, Oliver Kunz and David Morrison for taking the time to teach me Python and how to run my source code on an Ubuntu server. I am grateful for the time that David Stranack, Thomas Bingham and James Boyle have spent proof reading this project, and for the continuous support from my part- ner, Lisa Moxham.
    [Show full text]
  • TLS Deep Dive
    12/9/17 TLS Deep Dive Website Security & More Joe Pranevich December 5, 2017 Today’s Session – Overview of TLS – Connection Establishment – Testing Tools – Recent Security Issues 1 12/9/17 What is SSL/TLS? – Core internet protocols (IP, TCP, HTTP) were designed without default security – SSL was invented in 1995 by Netscape to support encryption of web traffic for ecommerce and other uses. – SSL/TLS sits above TCP. It can be used to encrypt many protocols, but mostly used for HTTP. – Over two decades, SSL has been improved (with vulnerabilities discovered in older versions). The name was changed to TLS in 1999. SSL & TLS Timeline Protocol Released Notes SSLv2 1995 Vulnerable, depreciated in 2011 SSLv3 1996 Vulnerable, depreciated in 2015 TLS 1.0 1999 At risk, no longer permitted by PCI TLS 1.1 2006 TLS 1.2 2008 TLS 1.3 TBD Internet Draft 2 12/9/17 But Wait, There’s More! – TLS supports dozens of different encryption methods, compression methods, hashing functions, and other details. – Clients and servers select from a menu of these options to negotiate the best security (more on that later) – Most of these options have their own security histories, some have been deprecated, etc. Key Concepts – Shared Key Cryptography (Symmertric) – Public/Private Key Cryptography (Asymmetric) – Hashing 3 12/9/17 Connection Establishment – TLS Handshake – Cipher negotiation – Certificate Validation – Device Compatibility TLS Handshake – Part One – Client sends a “hello” message saying that they want TLS. – It includes TLS version, ciphers it supports, and other details – Server sends a “hello” message back. – It selects the most secure matching TLS version and ciphers – Connection will fail if client and server cannot agree on protocols and ciphers 4 12/9/17 Client Devices Have Different Capabilities As Do Servers & Load Balancers 5 12/9/17 We Care About The Intersection Backwards Compatibility Warning! – Web browsers and operating systems get updated frequently; you can usually rely on web users having a recent TLS stack when they connect to you.
    [Show full text]
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019
    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
    [Show full text]
  • Download a PDF Version of the 2017 Annual Review
    Front Back Cover for Avisan.qxp_Layout 1 11/15/17 1:27 PM Page 1 Secure Technology Alliance 191 Clarksville Road Princeton Junction, New Jersey 08550 Annual Review 2017 Alliance A Secure Publication Technology 7 Volume www.securetechalliance.org Annual Review 2017 SCA-ad 2017 resized.indd 1 10/30/2017 10:40:22 AM EXECUTIVE DIRECTOR’S LETTER: A MESSAGE FROM RANDY VANDERHOOF Delivering Value to a Diverse Market Thank you for taking the time to read the 2017 Annual Review. This publication captures the best aspects of the membership experience for 2017 that hundreds of individual members and their organizations helped to provide. This year was especially sig- nificant, as the organization expanded its mission beyond smart cards and was re-branded as the Secure Technology Alliance. The new name and scope allows the Alliance to include embedded chip technology, hardware and software, and the future of digital security in all forms. The vast number of deliverables and member-driven activities recorded in the publication illustrates the diversity of the markets we serve and the commitment of all the industry professionals who contribute their knowledge and leadership toward expanding the market for smart card and related secure chip technologies. CHANGE COMES WITH NEW OPPORTUNITIES The decision to expand the mission and rebrand the organization was driven THE DECISION TO EXPAND by the changes in the secure chip industry, mostly from mobile technol- ogy and the growth of Internet-connected devices. This does not mean the THE MISSION AND REBRAND market for smart cards has disappeared. In fact, over the last few years, the THE ORGANIZATION WAS U.S.
    [Show full text]
  • TLS Attacks & DNS Security
    IAIK TLS Attacks & DNS Security Information Security 2019 Johannes Feichtner [email protected] IAIK Outline TCP / IP Model ● Browser Issues Application SSLStrip Transport MITM Attack revisited Network Link layer ● PKI Attacks (Ethernet, WLAN, LTE…) Weaknesses HTTP TLS / SSL FLAME FTP DNS Telnet SSH ● Implementation Attacks ... ● Protocol Attacks ● DNS Security IAIK Review: TLS Services All applications running TLS are provided with three essential services Authentication HTTPS FTPS Verify identity of client and server SMTPS ... Data Integrity Detect message tampering and forgery, TLS e.g. malicious Man-in-the-middle TCP IP Encryption Ensure privacy of exchanged communication Note: Technically, not all services are required to be used Can raise risk for security issues! IAIK Review: TLS Handshake RFC 5246 = Establish parameters for cryptographically secure data channel Full handshake Client Server scenario! Optional: ClientHello 1 Only with ServerHello Client TLS! Certificate 2 ServerKeyExchange Certificate CertificateRequest ClientKeyExchange ServerHelloDone CertificateVerify 3 ChangeCipherSpec Finished ChangeCipherSpec 4 Finished Application Data Application Data IAIK Review: Certificates Source: http://goo.gl/4qYsPz ● Certificate Authority (CA) = Third party, trusted by both the subject (owner) of the certificate and the party (site) relying upon the certificate ● Browsers ship with set of > 130 trust stores (root CAs) IAIK Browser Issues Overview Focus: Relationship between TLS and HTTP Problem? ● Attacker wants to access encrypted data ● Browsers also have to deal with legacy websites Enforcing max. security level would „break“ connectivity to many sites Attack Vectors ● SSLStrip ● MITM Attack …and somehow related: Cookie Stealing due to absent „Secure“ flag… IAIK Review: ARP Poisoning How? Attacker a) Join WLAN, ● Sniff data start ARP Poisoning ● Manipulate data b) Create own AP ● Attack HTTPS connections E.g.
    [Show full text]
  • Yet Another Padding Oracle in Openssl CBC Ciphersuites
    Yet Another Padding Oracle in OpenSSL CBC Ciphersuites presented by Raphael Finkel based on https://blog.cloudflare.com/ yet-another-padding-oracle-in-openssl-cbc-ciphersuites/ Keeping Current, September 5, 2018 The Cryptographic Doom Principle I reference: https://moxie.org/blog/ the-cryptographic-doom-principle/ by Moxie Marlinspike I If you have to perform any cryptographic operation before verifying the MAC (message authentication code) on a message you’ve received, it will somehow inevitably lead to doom. I MAC is a cryptographic digest based on a secret key shared by Alice and Bob. I Proper use of MAC: Encrypt Then Authenticate (Encrypt-then-MAC, EtA; used in IPsec) I Alice sends to Bob: E(P) || MAC(E(P)) I Detail: E(P) also includes such information as the initialization vector and the encryption algorithm; both are then covered by MAC(). I Bob first verifies MAC(E(P)), satisfying the principle. If that test passes, Bob decrypts P. I Good: Verifies integrity of E(P), therefore it also verifies integrity of P. I Good: MAC(E(P)) provides no information about P. Authenticate and encrypt (Encrypt-and-MAC, E&A; used in SSH) I Alice sends to Bob: E(P) || MAC(P) I Bob must first decrypt E(P) to get P, then confirm MAC(P), violating the principle. I Good: verifies integrity of P. I Not good: I May theoretically reveal information about P in MAC(P). I No integrity check on E(P). I Bad: vulnerable to chosen-ciphertext attacks on E. I Man-in-the-middle Morton can try various versions of E(P), noting whether Bob gets as far as trying to verify MAC(P).
    [Show full text]
  • Safe and Secure Model-Driven Design for Embedded Systems Letitia Li
    Safe and secure model-driven design for embedded systems Letitia Li To cite this version: Letitia Li. Safe and secure model-driven design for embedded systems. Embedded Systems. Université Paris-Saclay, 2018. English. NNT : 2018SACLT002. tel-01894734 HAL Id: tel-01894734 https://pastel.archives-ouvertes.fr/tel-01894734 Submitted on 12 Oct 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Approche Orientee´ Modeles` pour la Suretˆ e´ et la Securit´ e´ des Systemes` Embarques´ These` de doctorat de l’Universite´ Paris-Saclay prepar´ ee´ a` Telecom ParisTech Ecole doctorale n◦580 Denomination´ (STIC) NNT : 2018SACLT002 Specialit´ e´ de doctorat: Informatique These` present´ ee´ et soutenue a` Biot, le 3 septembre` 2018, par LETITIA W. LI Composition du Jury : Prof. Philippe Collet Professeur, Universite´ Coteˆ d’Azur President´ Prof. Guy Gogniat Professeur, Universite´ de Bretagne Sud Rapporteur Prof. Maritta Heisel Professeur, University Duisburg-Essen Rapporteur Prof. Jean-Luc Danger Professeur, Telecom ParisTech Examinateur Dr. Patricia Guitton
    [Show full text]
  • ECE 435 – Network Engineering Lecture 4
    ECE 435 { Network Engineering Lecture 4 Vince Weaver http://web.eece.maine.edu/~vweaver [email protected] 13 September 2018 Announcements • HW#1 was due. • HW#2 will be posted. Write a mini webserver. • Cybersecurity club Linux Security Lab on Saturday 1 WWW wrapup 2 What if Server Overloaded? • Slashdot effect (modern: HackerNews?) • caching/proxy { squid • Content Delivery Network { akami • Server farms 3 Security • SSL { Secure Socket Layer • Replaced by TLS (Transport Layer Security) • Port 443 for https • Public key encryption. 4 Setting Up a Web-server • Apache • Easy to do, more difficult to secure 5 Web Seach • Web-bots index the web. robots.txt file • Altavista, Hotbot, Excite, Inktomi, etc. • Curated search like Yahoo (people organize links rather than automatically search) • Google (1996 some machine in Stanford, 1997-1998) • MSN search 1999, rebranded Microsoft Bing 2009 6 Remote Connections 7 telnet/rlogin/rsh/ssh • telnet { login to remote system (tcp port 23) everything (including passwords) sent in plain text • rsh/rlogin { remote shell, remote login. (tcp port 514) Didn't even need password, could configure to let you run commands on remote machine. Security based if you had same username on both machines, assumption was getting root on a UNIX machine and connected to Ethernet was expensive/difficult 8 SSH secure shell • tcp port 22 • can login, run commands, tunnel tcp/ip, tunnel X11, file transfer (scp, sftp) • Large number of RFCs • Version 1: 1995, originally freeware but became private • Version 2: 2005, openBSD based on last free version • For security reasons there's a push to drop Version 1 • uses public-key cryptography • transport layer: arranges initial key exchange, server 9 authentication, key re-exchange • user authentication layer: can have password, or can set up keys to allow passwordless, DSA or RSA key pairs • connection layer: set up channels • lots of encryption types supported, old ones being obsoleted as found wanting • Various ssh servers/clients.
    [Show full text]
  • Zerohack Zer0pwn Youranonnews Yevgeniy Anikin Yes Men
    Zerohack Zer0Pwn YourAnonNews Yevgeniy Anikin Yes Men YamaTough Xtreme x-Leader xenu xen0nymous www.oem.com.mx www.nytimes.com/pages/world/asia/index.html www.informador.com.mx www.futuregov.asia www.cronica.com.mx www.asiapacificsecuritymagazine.com Worm Wolfy Withdrawal* WillyFoReal Wikileaks IRC 88.80.16.13/9999 IRC Channel WikiLeaks WiiSpellWhy whitekidney Wells Fargo weed WallRoad w0rmware Vulnerability Vladislav Khorokhorin Visa Inc. Virus Virgin Islands "Viewpointe Archive Services, LLC" Versability Verizon Venezuela Vegas Vatican City USB US Trust US Bankcorp Uruguay Uran0n unusedcrayon United Kingdom UnicormCr3w unfittoprint unelected.org UndisclosedAnon Ukraine UGNazi ua_musti_1905 U.S. Bankcorp TYLER Turkey trosec113 Trojan Horse Trojan Trivette TriCk Tribalzer0 Transnistria transaction Traitor traffic court Tradecraft Trade Secrets "Total System Services, Inc." Topiary Top Secret Tom Stracener TibitXimer Thumb Drive Thomson Reuters TheWikiBoat thepeoplescause the_infecti0n The Unknowns The UnderTaker The Syrian electronic army The Jokerhack Thailand ThaCosmo th3j35t3r testeux1 TEST Telecomix TehWongZ Teddy Bigglesworth TeaMp0isoN TeamHav0k Team Ghost Shell Team Digi7al tdl4 taxes TARP tango down Tampa Tammy Shapiro Taiwan Tabu T0x1c t0wN T.A.R.P. Syrian Electronic Army syndiv Symantec Corporation Switzerland Swingers Club SWIFT Sweden Swan SwaggSec Swagg Security "SunGard Data Systems, Inc." Stuxnet Stringer Streamroller Stole* Sterlok SteelAnne st0rm SQLi Spyware Spying Spydevilz Spy Camera Sposed Spook Spoofing Splendide
    [Show full text]
  • It-Säkerhet - Examensarbete
    IT-SÄKERHET - EXAMENSARBETE Största IT-säkerhetshoten mot svenska företag och organisationer idag, samt kontemporära metoder och verktyg för bekämpning av dessa IT-säkerhetshot. DEN 29 MARS 2016 BENJAMIN LUNDSTRÖM Examensarbete i Nät- & kommunikationsteknik, Umeå universitet. Löpnummer EL1609. BENJAMIN LUNDSTRÖM 16-03-29 IT-SÄKERHET - EXAMENSARBETE Sammanfattning Olika former av IT-relaterade hot har förekommit sedan internets födelse. Inledningsvis var de harmlösa humoristiska program som över tiden utvecklades till kriminella verktyg med ekonomiska syften. Elakartad programkod benämns under samlingsnamnet Malware. En angripare besitter idag ett stort antal metoder för otillåten tillgång till system, neka legitima användare tillgång till system eller på ett stort antal sätt bedriva kriminell verksamhet av ekonomisk karaktär. Skydds- och bekämpningsmetoderna innefattar brandväggar, olika analys-, detektions- och preventionssystem (IDS/IPS) och kryptering. Men för att komma tillrätta med IT-hoten fullt ut krävs också säkerhetsutbildning och incidenthantering som sker via incidentplanering, rapporter, dokumentation, backup och informationsklassning. Kontemporära IT-säkerhetshot av betydande art belyses i rapporten. Stuxnet (2009), som angrep Irans kärnvapenforskning. Flamer (2011), ett cybervapen vars syfte är spårlös informationsinhämtning. BlackEnergy (2015) och angreppet mot elförsörjningen i Ukraina. DDoS- attacken mot Svenska medier behandlas liksom Petya (2016) som är nya generationens Ransomeware. Det är vitalt för företag och organisationer att skydda sin viktigaste tillgång, informationen. Både mot cyberkriminella element i rent finansiellt syfte men i tilltagande grad också mot olika cybervapen och möjligtvis också mot cyberterrorism. Abstract A number of IT-related threats have emerged since the birth of internet. In the beginning they were harmless but over time they developed into fearsome criminal tools for economic purposes.
    [Show full text]