Heartbleed - Wikipedia, the Free Encyclopedia Heartbleed from Wikipedia, the Free Encyclopedia

Total Page:16

File Type:pdf, Size:1020Kb

Heartbleed - Wikipedia, the Free Encyclopedia Heartbleed from Wikipedia, the Free Encyclopedia 4/14/2014 Heartbleed - Wikipedia, the free encyclopedia Heartbleed From Wikipedia, the free encyclopedia Heartbleed is a security bug in the open-source OpenSSL cryptography library, widely used to implement the Internet's Transport Layer Security (TLS) protocol. This vulnerability is due to a missing bounds check in the handling of the Transport Layer Security (TLS) heartbeat extension.[3] A fixed version of OpenSSL was released on April 7, 2014, at the same time as Heartbleed was publicly disclosed. At that time, some 17 percent (around half a million) of the Internet's secure web servers certified by trusted authorities were believed to be vulnerable to the attack, allowing theft of the servers' private keys and users' session cookies and passwords.[4][5][6][7][8] The Electronic Frontier Foundation,[9] Ars Technica,[10] and Bruce Schneier[11] all deemed the Heartbleed bug "catastrophic". Forbes cybersecurity columnist Joseph Steinberg described the bug as potentially "the worst vulnerability found (at least in terms of its potential impact) since commercial traffic began to flow on the Internet", implying that it is worse than the Israeli spyware/malware Logo representing Heartbleed. [12] pandemic of Stuxnet and Duqu combined. Finland's Codenomicon company gave Heartbleed both a name and a Heartbleed is registered in the Common Vulnerabilities and Exposures logo, contributing to public awareness system as CVE-2014-0160.[13] of the issue.[1][2] Contents 1 History 1.1 Appearance 1.2 Resolution 1.3 Possible exploitation prior to disclosure 1.4 Reported exploitation subsequent to disclosure 2 Behavior 2.1 Impact 2.2 Affected OpenSSL versions 2.2.1 Vulnerable Program and Function 2.3 Patch 2.4 Vulnerability testing services 3 Affected services 3.1 Websites and web services 3.2 Software applications 4 Reaction 5 Root causes and possible lessons 6 References 7 External links http://en.wikipedia.org/wiki/Heartbleed 1/12 4/14/2014 Heartbleed - Wikipedia, the free encyclopedia History Appearance The Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols is a proposed standard specified by RFC 6520, published in February 2012. It provides a way to test and keep alive secure communication links without the need to renegotiate the connection each time. In 2011, Dr. Robin Seggelmann, then a Ph.D. student at the University of Duisburg-Essen, implemented the Heartbeat Extension for OpenSSL. Following Seggelmann's request to put the result of his work into OpenSSL,[14][15][16] his change was reviewed by Dr. Stephen N. Henson, one of OpenSSL's four core developers. Henson apparently failed to notice a bug in Seggelmann's implementation, and introduced the resulting vulnerability, Heartbleed, into OpenSSL's source code repository on December 31, 2011. Heartbeat support was enabled by default, causing affected versions to be affected by default. The vulnerable code has been adopted to widespread use with the release of OpenSSL version 1.0.1 on March 14, 2012.[17][18][19] Resolution On March 21, 2014 Bodo Moeller and Adam Langley of Google wrote a patch that fixed the bug. The date of the patch is known from Red Hat's issue tracker.[20] The next chronological date available from the public evidence is the claim by performance and security company CloudFlare that they fixed the flaw on their systems on March 31, 2014.[21] According to Mark J. Cox of OpenSSL, Neel Mehta of Google's security team reported Heartbleed on April 1, 2014.[22] The bug entailed a severe memory handling error in the implementation of the Transport Layer Security Heartbeat Extension.[23][24] This defect could be used to reveal up to 64 kilobytes of the application's memory with every heartbeat.[24] The bug was named by an engineer at the firm Codenomicon, a Finnish cybersecurity company, which also created the bleeding heart logo, and launched the domain Heartbleed.com (http://heartbleed.com) to explain the bug to the public.[25] According to Codenomicon, Neel Mehta first reported the bug to OpenSSL, but both Google and Codenomicon discovered it independently.[17] Codenomicon reports April 3 as their date of discovery of the bug and as their date of notification of NCSC-FI (formerly known as CERT-FI) for vulnerability coordination.[17][26] Mehta also congratulated Codenomicon, without going into detail.[27] On April 10, "Cisco Systems and Juniper Networks, two of the biggest creators of Internet equipment, announced on Thursday that their products had been affected by the Heartbleed bug. Routers, firewalls and switches ... have all likely been affected by the bug, leaving your personal information at risk of being stolen by hackers."[28] On April 12, at least two independent researchers were able to steal private keys using this attack from an experimental server intentionally set up for that purpose by CloudFlare.[29][30] Possible exploitation prior to disclosure http://en.wikipedia.org/wiki/Heartbleed 2/12 4/14/2014 Heartbleed - Wikipedia, the free encyclopedia Many major web sites patched or disabled the bug within days of its announcement,[31] but it is unclear whether potential attackers were aware of it earlier and to what extent it was exploited. Based on examinations of audit logs by researchers, it has been reported that some attackers may have exploited the flaw for at least five months before discovery and announcement.[32][33] Errata Security has partially rejected this hypothesis,[34] whereas the Department of Homeland Security believes that as of April 11, "there have not been any reported attacks or malicious incidents involving this particular vulnerability confirmed".[35] According to two insider sources speaking to Bloomberg.com, the United States National Security Agency was aware of the flaw since shortly after its introduction, but chose to keep it secret, instead of reporting it, in order to exploit it for their own purposes.[36][37][38] The NSA has denied this claim.[39] Reported exploitation subsequent to disclosure Revenue Canada reported the theft of 900 taxpayer social insurance numbers through an exploit of the bug during a 6-hour period on April 8.[40] When the attack was discovered, the agency shut down its web site and extended the taxpayer filing deadline from April 30 to May 5.[41] The agency said it will provide anyone affected with credit protection services at no cost. Behavior The RFC 6520 Heartbeat Extension tests TLS/DTLS secure communication links by allowing a computer at one end of a connection to send a “Heartbeat Request” message, consisting of a payload, typically a text string, along with the payload’s length as a 16-bit integer. The receiving computer then must send the exact same payload back to the sender. The affected versions of OpenSSL allocate a memory buffer for the message to be returned based on the length field in the requesting Depiction of Heartbleed message, without regard to the size of actual payload in that message. Because of this failure to do proper bounds checking, the message returned consists of the requested payload followed by whatever else happened to be in the allocated memory buffer. The problem was compounded by OpenSSL's decision to write its own version of the C dynamic memory allocation (malloc and free) routines. As a result, the oversized memory buffer returned to the requestor was likely to contain data from memory blocks that had been previously requested and freed by OpenSSL. Such memory blocks may contain sensitive data sent by users or even the private keys used by OpenSSL. In addition, by using its own memory management routines OpenSSL bypassed mitigation measures in some operating systems that might have detected or neutralized the bug.[42] The heartbleed bug is exploited by sending a malformed heartbeat request with a small payload and large length field to the server in order to elicit the server's response permitting attackers to read up to 64 kilobytes of server memory that was likely to have been used previously by SSL.[43] Attackers in this way could receive sensitive data, compromising the security of the server and its users. Vulnerable data include the server's private master key,[17][19] which would enable attackers to decrypt current or stored traffic via passive man-in-the-middle attack (if perfect http://en.wikipedia.org/wiki/Heartbleed 3/12 4/14/2014 Heartbleed - Wikipedia, the free encyclopedia forward secrecy is not used by the server and client), or active man-in-the-middle if perfect forward secrecy is used. The attacker cannot control which data are returned, as OpenSSL typically responds with the chunks of memory it has most recently discarded. The bug might also reveal unencrypted parts of users' requests and responses, including any form post data in users' requests, session cookies and passwords, which might allow attackers to hijack the identity of another user of the service.[44] Impact By attacking a service that uses a vulnerable version of OpenSSL, a remote, unauthenticated attacker may be able to retrieve sensitive information, such as secret keys. By leveraging this information, an attacker may be able to decrypt, spoof, or perform man-in-the-middle attacks on network traffic that would otherwise be protected by OpenSSL.[45] Affected OpenSSL versions The affected versions of OpenSSL include OpenSSL 1.0.1 through 1.0.1f (inclusive). OpenSSL 1.0.1g, OpenSSL 1.0.0 branch and OpenSSL 0.9.8 branch are not vulnerable.[46] Vulnerable Program and Function The vulnerable program source files are t1_lib.c and dl_both.c and the vulnerable functions are tls1_process_heartbeat() and dtls1_process_heartbeat().[47] Patch The bug is classified as a buffer over-read,[48] a situation where software allows more data to be read than should be allowed.[49] The problem can be fixed by ignoring Heartbeat Request messages that ask for more data than their payload needs.
Recommended publications
  • The Middle East Under Malware Attack Dissecting Cyber Weapons
    The Middle East under Malware Attack Dissecting Cyber Weapons Sami Zhioua Information and Computer Science Department King Fahd University of Petroleum and Minerals Dhahran, Saudi Arabia [email protected] Abstract—The Middle East is currently the target of an un- have been designed by the same unknown entity 1. The next precedented campaign of cyber attacks carried out by unknown malware of this lineage was Flame [7] which was discovered parties. The energy industry is praticularly targeted. The in May 2012 by Kaspersky Lab while investigating another attacks are carried out by deploying extremely sophisticated malware. The campaign opened by the Stuxnet malware in piece of malware called Wiper [8]. Flame features very 2010 and then continued through Duqu, Flame, Gauss, and unusual characteristics such as large size, large number of Shamoon malware. This paper is a technical survey of the modules, self adapting, etc. As Duqu, Flame’s objective is attacking vectors utilized by the three most famous malware, data collection and espionnage. Gauss [9] is another data namely, Stuxnet, Flame, and Shamoon. We describe their main stealing malware discovered in June 2012 by Kaspersky Lab modules, their sophisticated spreading capabilities, and we discuss what it sets them apart from typical malware. The focusing on banking information. Flame and Gauss exhibit main purpose of the paper is to point out the recent trends striking similarities and several technical evidences indicate infused by this new breed of malware into cyber attacks. that they come from the same “factories” that produced Stuxnet and Duqu [9]. The latest malware-based attack Keywords-Malwares; Information Security; Targeted At- tacks; Stuxnet; Duqu; Flame; Gauss; Shamoon targeting the middle east was the Shamoon attack on Saudi Aramco [10].
    [Show full text]
  • Duqu the Stuxnet Attackers Return
    Uncovering Duqu The Stuxnet Attackers Return Nicolas Falliere 4/24/2012 Usenix Leet - San Jose, CA 1 Agenda 1 Revisiting Stuxnet 2 Discovering Duqu 3 Inside Duqu 4 Weird, Wacky, and Unknown 5 Summary 2 Revisiting Stuxnet 3 Key Facts Windows worm discovered in July 2010 Uses 7 different self-propagation methods Uses 4 Microsoft 0-day exploits + 1 known vulnerability Leverages 2 Siemens security issues Contains a Windows rootkit Used 2 stolen digital certificates Modified code on Programmable Logic Controllers (PLCs) First known PLC rootkit 4 Cyber Sabotage 5 Discovering Duqu 6 Boldi Bencsath Announce (CrySyS) emails: discovery and “important publish 25 page malware Duqu” paper on Duqu Boldi emails: Hours later the “DUQU DROPPER 7 C&C is wiped FOUND MSWORD 0DAY INSIDE” Inside Duqu 8 Key Facts Duqu uses the same code as Stuxnet except payload is different Payload isn‟t sabotage, but espionage Highly targeted Used to distribute infostealer components Dropper used a 0-day (Word DOC w/ TTF kernel exploit) Driver uses a stolen digital certificate (C-Media) No self-replication, but can be instructed to copy itself to remote machines Multiple command and control servers that are simply proxies Infections can serve as peers in a peer-to-peer C&C system 9 Countries Infected Six organizations, in 8 countries confirmed infected 10 Architecture Main component A large DLL with 8 or 6 exports and 1 main resource block Resource= Command & Control module Copies itself as %WINDIR%\inf\xxx.pnf Injected into several processes Controlled by a Configuration Data file Lots of similarities with Stuxnet Organization Code Usual lifespan: 30 days Can be extended 11 Installation 12 Signed Drivers Some signed (C-Media certificate) Revoked on October 14 13 Command & Control Module Communication over TCP/80 and TCP/443 Embeds protocol under HTTP, but not HTTPS Includes small blank JPEG in all communications Basic proxy support Complex protocol TCP-like with fragments, sequence and ack.
    [Show full text]
  • No Random, No Ransom: a Key to Stop Cryptographic Ransomware
    No Random, No Ransom: A Key to Stop Cryptographic Ransomware Ziya Alper Genç, Gabriele Lenzini, and Peter Y.A. Ryan Interdisciplinary Centre for Security Reliability and Trust (SnT) University of Luxembourg Abstract. To be effective, ransomware has to implement strong encryp- tion, and strong encryption in turn requires a good source of random numbers. Without access to true randomness, ransomware relies on the pseudo random number generators that modern Operating Systems make available to applications. With this insight, we propose a strategy to miti- gate ransomware attacks that considers pseudo random number generator functions as critical resources, controls accesses on their APIs and stops unauthorized applications that call them. Our strategy, tested against 524 active real-world ransomware samples, stops 94% of them, including WannaCry, Locky, CryptoLocker and CryptoWall. Remarkably, it also nullifies NotPetya, the latest offspring of the family which so far has eluded all defenses. Keywords: ransomware, cryptographic malware, randomness, mitigation. 1 Introduction Ransomware is a malware, a malicious software that blocks access to victim’s data. In contrast to traditional malware, whose break-down is permanent, ransomware’s damage is reversible: access to files can be restored on the payment of a ransom, usually a few hundreds US dollars in virtual coins. Despite being relatively new, this cyber-crime is spreading fast and it is believed to become soon a worldwide pandemic. According to [24], a US Govern- ment’s white paper dated June 2016, on average more than 4,000 ransomware attacks occurred daily in the USA. This is 300-percent increase from the previous year and such important increment is probably due to the cyber-crime’s solid business model: with a small investment there is a considerable pecuniary gain which, thanks to the virtual currency technology, can be collected reliably and in a way that is not traceable by the authorities.
    [Show full text]
  • Attributing Cyber Attacks Thomas Rida & Ben Buchanana a Department of War Studies, King’S College London, UK Published Online: 23 Dec 2014
    This article was downloaded by: [Columbia University] On: 08 June 2015, At: 08:43 Publisher: Routledge Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK Journal of Strategic Studies Publication details, including instructions for authors and subscription information: http://www.tandfonline.com/loi/fjss20 Attributing Cyber Attacks Thomas Rida & Ben Buchanana a Department of War Studies, King’s College London, UK Published online: 23 Dec 2014. Click for updates To cite this article: Thomas Rid & Ben Buchanan (2015) Attributing Cyber Attacks, Journal of Strategic Studies, 38:1-2, 4-37, DOI: 10.1080/01402390.2014.977382 To link to this article: http://dx.doi.org/10.1080/01402390.2014.977382 PLEASE SCROLL DOWN FOR ARTICLE Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) contained in the publications on our platform. However, Taylor & Francis, our agents, and our licensors make no representations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of the Content. Any opinions and views expressed in this publication are the opinions and views of the authors, and are not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon and should be independently verified with primary sources of information. Taylor and Francis shall not be liable for any losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoever or howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use of the Content.
    [Show full text]
  • Threat Landscape Report – 1St Quarter 2018
    TLP-AMBER Threat Landscape Report – 1st Quarter 2018 (FINAL) V1.0 – 10/04/2018 This quarterly report summarises the most significant direct cyber threats to EU institutions, bodies, and agencies (EU-I or 'Constituents') in Part I, the development of cyber-threats on a broader scale in Part II, and recent technical trends in Part III. KEY FINDINGS Direct Threats • In Europe, APT28 / Sofacy threat actor (likely affiliated to Russia military intelligence GRU) targeted government institutions related to foreign affairs and attendees of a military conference. Another threat actor, Turla (likely affiliated to Russia’s security service FSB) executed a cyber-operation against foreign affairs entities in a European country. • A spear-phishing campaign that targeted European foreign ministries in the end of 2017 was attributed to a China-based threat actor (Ke3chang) which has a long track record of targeting EU institutions (since 2011). As regards cyber-criminality against EU institutions, attempts to deliver banking trojans are stable, ransomware activities are still in decline and cryptojacking on the rise. Phishing lures involve generic matters (’invoice’, ‘payment’, ‘purchase’, ‘wire transfer’, ‘personal banking’, ‘job application’) and more specific ones (foreign affairs issues, European think tanks matters, energy contracts, EU delegation, EU watch keeper). Almost all EU-I are affected by credential leaks (email address | password) on pastebin-like websites. Several credential- harvesting attempts have also been detected. Attackers keep attempting to lure EU-I staff by employing custom methods such as spoofed EU-I email addresses or weaponisation of EU-I documents. Broader Threats • Critical infrastructure. In the energy sector, the US authorities have accused Russian actors of targeting critical infrastructure (including nuclear) for several years and are expecting this to continue in 2018.
    [Show full text]
  • Stuxnet, Flame, and Duqu
    Page 212 Part 4: Militarization A Fierce Domain: Conflict in Cyberspace, 1986 to 2012 Page 213 Stuxnet, Flame, and Duqu - the DLYMPIC GAMES succeeded in creating problems for a lirnited number of our centrifuges with the software they had installed in electronic parts."3 The Iranian government seemed to downplay the Chris Morton1 impact Stuxnet had on their systems, but a public adrnission of interference was ouc of Stuxnet emerged on the wořld stage in the sununer of2010 as the most sophisticated piece character for a government known for playing their nuclear program cards close to their chest. of malicious software ever found. Designed to permanently damage Iranian uranium enriclunent gas centrifuges, Stuxnet represented a quantum leap in complexity and Ultimately,Stuxnet rendered nearly 1,000 ofthe 9,000 IR-1 type gas centrifuges unusable audaciry in cyber conflict. Not only did the malware astonish researchers with its ab~ty to at the Natanz uranium enrichment facility.Whil e the computer virus <lid not cripple Iran's penetrate and cripple a secretive regime's sensitive nuclear enrichment prog~, 1t. ~so ability to enrich uranium, it is unclear how close Iran would be to producing a nuclear \ concerned security experts due to its brash destruction of part of a na non s cnttcal weapon without the Stuxnet infection.4 i infrastructure.With the emergence of the Duqu and Flame computer viruses, the revelation ofa covertAmerican cyber campaign (code- named OLYMPIC GAMES) against Iran, and Geopolitical Context the recognition of commonality between the three pieces of malware, Stuxnet became known as the centerpiece of a broader campaign, one that rnight hint at the future of On the international stage, Iran was perceived as a destabilizing force, accused ofs ponsoring warfare.
    [Show full text]
  • Bashe Attack Global Infection by Contagious Malware 2
    CyRiM Report 2019 Bashe attack Global infection by contagious malware 2 About CyRiM About Cambridge Centre for Risk Studies Cyber risks are emerging risk with new complexities that The Centre for Risk Studies is a world leading centre for call for insurers and risk managers to jointly develop the study of the management of economic and societal innovative solutions and tools, and enhance awareness risks. The Centre’s focus is the analysis, assessment, and underwriting expertise. and mitigation of global vulnerabilities for the The Cyber Risk Management (CyRiM) project is led by advancement of political, business, and individual NTU-IRFRC in collaboration with industry partners and decision makers. academic experts. CyRiM is a pre-competitive research project that aims to foster an efficient cyber risk The Centre provides frameworks for recognizing, insurance market place through engaging industry and assessing, and managing the impacts of systemic academic experts guided by government and policy level threats. The research programme is concerned with research. The CyRiM project will help Singapore to catastrophes and how their impacts ripple across an become an industry centre of excellence on cyber risk increasingly connected world with consequent effects on and grow the cyber risk insurance market by promoting the international economy, financial markets, firms in the both the demand and the supply of insurance coverage. financial sectors, and global corporations. To test research outputs and guide new research agendas, the For more information about CyRiM please visit Centre engages with the business community, http://irfrc.ntu.edu.sg/Research/cyrim/Pages/Home.aspx government policy makers, regulators, and industry bodies.
    [Show full text]
  • A History of Cyber Incidents and Threats Involving Industrial Control Systems Kevin Hemsley, Ronald Fisher
    A History of Cyber Incidents and Threats Involving Industrial Control Systems Kevin Hemsley, Ronald Fisher To cite this version: Kevin Hemsley, Ronald Fisher. A History of Cyber Incidents and Threats Involving Industrial Control Systems. 12th International Conference on Critical Infrastructure Protection (ICCIP), Mar 2018, Arlington, VA, United States. pp.215-242, 10.1007/978-3-030-04537-1_12. hal-02076302 HAL Id: hal-02076302 https://hal.archives-ouvertes.fr/hal-02076302 Submitted on 22 Mar 2019 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. Distributed under a Creative Commons Attribution| 4.0 International License Chapter 12 A HISTORY OF CYBER INCIDENTS AND THREATS INVOLVING INDUSTRIAL CONTROL SYSTEMS Kevin Hemsley and Ronald Fisher Abstract For many years, malicious cyber actors have been targeting the indus- trial control systems that manage critical infrastructure assets. Most of these events are not reported to the public and their details along with their associated threats are not as well-known as those involving enterprise (information technology) systems. This chapter presents an analysis of publicly-reported cyber incidents involving critical infras- tructure assets. The list of incidents is by no means comprehensive.
    [Show full text]
  • THE DUQU 2.0 Technical Details
    THE DUQU 2.0 Technical Details Version: 2.1 (11 June 2015) www.kaspersky.com THE DUQU 2.0 2 Technical Details CONTENTS EXECUTIVE SUMMARY 3 INITIAL ATTACK 4 LATERAL MOVEMENT 4 ANALYSIS OF A DUQU 2.0 MSI PACKAGE 7 File properties 7 First Layer: ActionDLL (msi.dll) 10 Second Layer: ActionData0 10 Third Layer: klif.dll 11 Attacking AVP.EXE 12 CTwoPENC.dll zero-day and KMART.dll 14 PAYLOAD CONTAINERS AND MIGRATION 15 Payload type “L” 15 Payload run type “G” 16 Payload run type “I” 16 Payload run type “K” 17 Payload run type “Q” 17 PLATFORM PLUGGINABLE MODULES 17 PERSISTENCE MECHANISM 33 COMMAND AND CONTROL MECHANISMS 33 The “portserv.sys” driver analysis 35 SIMILARITIES BETWEEN DUQU AND DUQU 2.0 37 VICTIMS OF DUQU 2.0 42 ATTRIBUTION 43 CONCLUSIONS 44 REFERENCES 45 For any inquiries, please contact [email protected] THE DUQU 2.0 3 Technical Details EXECUTIVE SUMMARY Earlier this year, during a security sweep, Kaspersky Lab detected a cyber intrusion affecting several of its internal systems. Following this finding, we launched a large-scale investigation, which led to the discovery of a new malware platform from one of the most skilled, mysterious and powerful groups in the APT world – Duqu. The Duqu threat actor went dark in 2012 and was believed to have stopped working on this project - until now. Our technical analysis indicates the new round of attacks include an updated version of the infamous 12011 Duqu malware, sometimes referred to as the step-brother of 2Stuxnet. We named this new malware and its associated platform “Duqu 2.0”.
    [Show full text]
  • Tofino-Security-Blog-Re-Shamoon
    The latest post-Stuxnet discovery of advanced threats is a malicious malware known as Shamoon. Like Stuxnet, Duqu and Flame, it targeted energy companies in the Middle East, this time Saudi Aramco and likely other oil and gas concerns in the region including Qatar’s RasGaz. It is a new species however, because it did not disrupt an industrial process as Stuxnet did, nor did it stealthily steal business information as Flame and Duqu did. Instead it removed and overwrote the information on the hard drives of 30,000 (yes that number is correct1) workstations of Saudi Aramco (and who knows how many more at other firms). Nothing this damaging has been seen in a while. As a Kaspersky Lab expert commented “Nowadays, destructive malware is rare; the main focus of cybercriminals is financial profit. Cases like the one here do not appear very often.” What does Shamoon mean for SCADA and ICS Security? Hold that thought for a few paragraphs… 1 1 Copyright © 2012 by Byres Security Inc., All Rights Reserved.. First publicized on August 16, 2012 by Symantec, Kaspersky Labs, and Seculert, Shamoon took control of an Internet connected computer at Saudi Aramco. It then used that computer to communicate back to an external Command-and-Control server and to infect other computers running Microsoft Windows that were not Internet connected. The name Shamoon comes from a folder name within the malware executable: “c:\shamoon\ArabianGulf\wiper\release.pdb” While the significance of the word “Shamoon” is not known, it is speculated that it is the name of one of the malware authors.
    [Show full text]
  • Ransomware Ransomware Ransomware
    ABOUT: • Security researcher • Crazy Drummer ANTES AHORA NEWS NEWS NEWS NEWS NEWS https://www.youtube.com/watch?v=ZX8aN70stE0#t=4 CARACTERÍSTICAS DE STUXNET El uso de vulnerabilidades desconocidas hasta el momento para difundirse • Stuxnet usaba 4 0day no conocidos. • Era eficaz contra sistema operativo Windows desde 2000 hasta Windows 7 El uso inteligente combinando las vulnerabilidades • Algunas de las vulnerabilidades dejaban activo el autoRUN. • Otra vulnerabilidad tenía elevación de privilegios Uso de certificados válidos • Stuxnet llevaba un certiticado de Realtek válido DUQU CARACTERÍSTICAS DE DUQU Finalidad de Duqu • Instalar un Keylogguer en el sistema • Se comporta como una botnet tradicional, comunicandose via HTTP y HTTPS • El envío de información es disfrazado con envío de ficheros JPG a un C&C alojado en INDIA • A los 36 días, el troyano se eliminaba a si mismo • Venía firmado con certficados C-MEDIA • Se encontró en no mas de 100 equipos FLAME CARACTERÍSTICAS DE FLAME Finalidad de Flame • Instalar un Keylogguer en el sistema = que Duqu • Relacionado con el Medio Oriente • Capacidad de comunicación vía Bluetooth • Capacidad de capturar pantallas cuando están en ejecución ciertas aplicaciones (IM,) • A diferencia de Duqu y Stuxnet que pesaban unos 500 MB, Flame con plugins unos 20 MB • Se encontró en no mas de 100 equipos CAMBIO DE TENDENCIA • Mafia tradicional al uso CAMBIO DE TENDENCIA • Nuevo concepto, “Fraud as a service” • Definición de nuevos roles • Los mas malos Ejemplos de campañas OBJETIVOS DE LA INFECCIÓN • Meternos
    [Show full text]
  • Understanding the Twitter User Networks of Viruses and Ransomware Attacks
    Understanding the Twitter user networks of Viruses and Ransomware attacks Michelangelo Puliga12,∗ Guido Caldarelli123†, Alessandro Chessa12‡, and Rocco De Nicola1§ 1 Scuola IMT Alti Studi Lucca, Piazza San Francesco 19 55100, Italy [email protected] 2 Laboratorio Linkalab, Cagliari, Italy 3 London Institute for Mathematical Sciences, 35a South St. Mayfair London UK Abstract We study the networks of Twitter users posting information about Ransomware and Virus and other malware since 2010. We collected more than 200k tweets about 25 attacks measuring the impact of these outbreaks on the social network. We used the mention network as paradigm of network analysis showing that the networks have a similar behavior in terms of topology and tweet/retweet volumes. A detailed analysis on the data allowed us to better understand the role of the major technical web sites in diffusing the news of each new epidemic, while a study of the social media response reveal how this one is strictly correlated with the media hype but it is not directly proportional to the virus/ransomware diffusion. In fact ransomware is perceived as a problem hundred times more relevant than worms or botnets. We investigated the hypothesis of Early Warning signals in Twitter of malware attacks showing that, despite the popularity of the platform and its large user base, the chances of identifying early warning signals are pretty low. Finally we study the most active users, their distribution and their tendency of discussing more attack and how in time the users switch from a topic to another. Investigating the quality of the information on Twitter about malware we saw a great quality and the possibility to use this information as automatic classification of new attacks.
    [Show full text]