How-To Tutorials - Cybersecurity

This article is an excerpt from the book, "Effective Threat Investigation for SOC Analysts", by Mostafa Yahia. This is a practical guide that enables SOC professionals to analyze the most common security appliance logs that exist in any environment.IntroductionIn today’s cybersecurity landscape, threat detection and investigation are essential for defending against sophisticated attacks. VirusTotal, a powerful Threat Intelligence Platform (TIP), provides security analysts with robust tools to analyze suspicious files, domains, URLs, and IP addresses. Leveraging VirusTotal’s extensive security database and community-driven insights, SOC analysts can efficiently detect potential malware and other cyber threats. This article delves into the ways VirusTotal empowers analysts to investigate suspicious digital artifacts and enhance their organization’s security posture, focusing on critical features such as file analysis, domain reputation checks, and URL scanning.Investigating threats using VirusTotalVirusTotal is a  Threat Intelligence Platform (TIP) that allows security analysts to analyze suspicious files, hashes, domains, IPs, and URLs to detect and investigate malware and other cyber threats. Moreover, VirusTotal is known for its robust automation capabilities, which allow for the automatic sharing of this intelligence with the broader security community. See Figure 14.1:Figure 14.1 – The VirusTotal platform main web pageThe  VirusTotal scans submitted artifacts, such as hashes, domains, URLs, and IPs, against more than 88 security solution signatures and intelligence databases. As a SOC analyst, you should use the VirusTotal platform to investigate the  following:Suspicious filesSuspicious domains and URLsSuspicious outbound IPsInvestigating suspicious filesVirusTotal allows cyber security analysts to analyze suspicious files either by uploading the file or searching for the file hash’s reputation. Either after uploading a fi le or submitting a file hash for analysis, VirusTotal scans it against multiple antivirus signature databases and predefined YARA rules and analyzes the file behavior by using different sandboxes.After the analysis of the submitted file is completed, VirusTotal provides analysts with general information about the analyzed file in five tabs; each tab contains a wealth of information. See Figure 14.2:Figure 14.2 – The details and tabs provided by analyzing a file on VirusTotalAs you see in the preceding figure, aft er submitting the file to the VirusTotal platform for analysis, the file was analyzed against multiple vendors’ antivirus signature databases, Sigma detection rules, IDS detection rules, and several sandboxes for dynamic analysis.The preceding figure is the first page provided by VirusTotal after submitting the file. As you can see, the first section refers to the most common name of the submitted file hash, the file hash, the number of antivirus vendors and sandboxes that flagged the submitted hash as malicious, and tags of the suspicious activities performed by the file when analyzed on the sandboxes, such as the persistence tag, which means that the executable file tried to maintain persistence. See Figure 14.3:Figure 14.3 – The first section of the first page from VirusTotal when analyzing a fileThe first tab of the five tabs provided by the VirusTotal platform that appear is the DETECTION tab. The first parts of the DETECTION tab include the matched Sigma rules, IDS rules, and dynamic analysis results from the sandboxes. See Figure 14.4:Figure 14.4 – The first parts of the DETECTION tabThe Sigma rules are threat detection rules designed to analyze system logs. Sigma was built to allow collaboration between the SOC teams as it allows them to share standardized detection rules regardless of the SIEM in place to detect the various threats by using the event logs. VirusTotal sandboxes store all event logs that are generated during the file detonation, which are later used to test against the list of the collected Sigma rules from different repositories. VirusTotal users will find the list of Sigma rules matching a submitted file in the DETECTION tab. As you can see in the preceding figure, it appears that the executed file has performed certain actions that have been identified by running the Sigma rules against the sandbox logs. Specifically, it disabled the Defender service, created an Auto-Start Extensibility Point (ASEP) entry to maintain persistence, and created another executable.Then as can be  observed, VirusTotal shows that the Intrusion Detection System (IDS) rules successfully detected the presence of Redline info-stealer malware's Command and Control (C&C) communication that matched four IDS rules.Important Note: It is noteworthy that both Sigma and IDS rules are assigned a severity level, and analysts can easily view the matched rule as well as the number of matches.Following the successful matching against IDS rules, you will find the dynamic sandboxes’ detections of the submitted file. In this case, the sandboxes categorized the submitted file/hash as info-stealer malware.Finally, the last part of the DETECTION tab is Security vendors’ analysis. See Figure 14.5:Figure 14.5 – The Security vendors’ analysis sectionAs you see in the preceding figure, the submitted fi le or hash is flagged as malicious by several security vendors and most of them label the given file as a Redline info-stealer malware.The second tab is the DETAILS tab, which includes the Basic properties section on the given file, which includes the file hashes, file type, and file size. That tab also includes times such as file creation, first submission on the platform, last submission on the platform, and last analysis times. Additionally, this tab provides analysts with all the filenames associated with previous submissions of the same file. See Figure 14.6:Figure 14.6 – The first three sections of the DETAILS tabMoreover, the DETAILS tab provides analysts with useful information such as signature verification, enabling identification of whether the file is digitally signed, a key indicator of its authenticity and trustworthiness. Additionally, the tab presents crucial insights into the imported Dynamic Link Libraries (DLLs) and called libraries, allowing analysts to understand the file intents.The third tab is the RELATIONS tab, which includes the IoCs of the analyzed file, such as the domains and IPs that the file is connected with, the files bundled with the executable, and the files dropped by the executable. See Figure 14.7:Figure 14.7 – The RELATIONS tabImportant noteWhen analyzing a malicious file, you can use the connected IPs and domains to scope the infection in your environment by using network security system logs such as the firewall and the proxy logs. However, not all the connected IPs and domains are necessarily malicious and may also be legitimate domains or IPs used by the malware for malicious intents.At the bottom of the RELATIONS tab, VirusTotal provides a great graph that binds the given file and all its relations into one graph, which should facilitate your investigations. To maximize the graph in a new tab, click on it. See Figure 14.8:Figure 14.8 – VT Relations graphThe fourth tab is the BEHAVIOR tab, which contains the detailed sandbox analysis of the submitted file. This report is presented in a structured format and includes the tags, MITRE ATT&CK Tactics and Techniques conducted by the executed file, matched IDS and Sigma rules, dropped files, network activities, and process tree information that was observed during the analysis of the given file. See Figure 14.9:Figure 14.9 – The BEHAVIOR tabRegardless of the matched signatures of security vendors, Sigma rules, and IDS rules, the BEHAVIOR tab allows analysts to examine the file’s actions and behavior to determine whether it is malicious or not. This feature is especially critical in the investigation of zero-day malware, where traditional signature-based detection methods may not be effective, and in-depth behavior analysis is required to identify and respond to potential threats.The fifth tab is the COMMUNITY tab, which allows analysts to contribute to the VirusTotal community with their thoughts and to read community members’ thoughts regarding the given file. See Figure 14.10:Figure 14.10 – The COMMUNITY tabAs you can see, we have two comments from two sandbox vendors indicating that the file is malicious and belongs to the Redline info-stealer family according to its behavior during the dynamic analysis of the file.Investigating suspicious domains and URLsA SOC analyst may depend on the VirusTotal platform to investigate suspicious domains and URLs. You can analyze the suspicious domain or URL on the VirusTotal platform either by entering it into the URL or Search form.During the Investigating suspicious files section, we noticed while navigating the RELATION tab that the file had established communication with the hueref[.]eu domain. In this section, we will investigate the hueref[.]eu domain by using the VirusTotal platform. See Figure 14.11:Figure 14.11 – The DETECTION tabUpon submitting the suspicious domain to the Search form in VirusTotal, it was discovered that the domain had several tags indicating potential security risks. These tags refer to the web domain category. As you can see in the preceding screenshot, there are two tags indicating that the domain is malicious.The first provided tab is the DETECTION tab, which include the Security vendors’ analysis. In this case, several security vendors labeled the domain as Malware or a Malicious domain.The second tab is the DETAILS tab, which includes information about the given domain such as the web domain categories from different sources, the last DNS records of the domain, and the domain Whois lookup results. See Figure 14.12:Figure 14.12 – The DETAILS tabThe third tab is the RELATIONS tab, which provides analysts with all domain relations, such as the DNS resolving the IP(s) of the given domain, along with their reputations, and the files that communicated with the given domain when previously analyzed in the VirusTotal sandboxes, along with their reputations. See Figure 14.13.Figure 14.13 – The RELATIONS tabThe RELATIONS tab is very useful, especially when investigating potential zero-day malicious domains that have not yet been detected and fl agged by security vendors. By analyzing the domain’s resolving IP(s) and their reputation, as well as any connections between the domain and previously analyzed malicious files on the VT platform, SOC analysts can quickly and accurately identify potential threats that potentially indicate a C&C server domain.At the bottom of the RELATIONS tab, you will find the same VirusTotal graph discussed in the previous section.The fourth tab is the COMMUNITY tab, which allows you to contribute to the VirusTotal community with your thoughts and read community members’ thoughts regarding the given domain.Investigating suspicious outbound IPsAs a security analyst, you may depend on the VirusTotal platform to investigate suspicious outbound IPs that your internal systems may have communicated with. By entering the IP into the search form, the VirusTotal platform will show you nearly the same tab details provided when analyzing domains in the last section.In this section, we will investigate the IP of the hueref[.]eu domain. As we mentioned, the tabs and details provided by VirusTotal when analyzing an IP are the same as those provided when analyzing a domain. Moreover, the RELATIONS tab in VirusTotal provides all domains hosted on this IP and their reputations. See Figure 14.14:Figure 14.14 – Domains hosted on the same IP and their reputationsImportant noteIt’s not preferred to depend on the VirusTotal platform to investigate suspicious inbound IPs such as port-scanning IPs and vulnerability-scanning IPs. This is due to the fact that VirusTotal relies on the reputation assessments provided by security vendors, which are particularly effective in detecting outbound IPs such as those associated with C&C servers or phishing activities.By the end of this section, you should have learned how to investigate suspicious files, domains, and outbound IPs by using the VirusTotal platform.ConclusionIn conclusion, VirusTotal is an invaluable resource for SOC analysts, enabling them to streamline threat investigations by analyzing artifacts through multiple detection engines and sandbox environments. From identifying malicious file behavior to assessing suspicious domains and URLs, VirusTotal’s capabilities offer comprehensive insights into potential threats. By integrating this tool into daily workflows, security professionals can make data-driven decisions that enhance response times and threat mitigation strategies. Ultimately, VirusTotal not only assists in pinpointing immediate risks but also contributes to a collaborative, community-driven approach to cybersecurity.Author BioMostafa Yahia is a passionate threat investigator and hunter who hunted and investigated several cyber incidents. His experience includes building and leading cyber security managed services such as SOC and threat hunting services. He earned a bachelor's degree in computer science in 2016. Additionally, Mostafa has the following certifications: GCFA, GCIH, CCNA, IBM Qradar, and FireEye System engineer. Mostafa also provides free courses and lessons through his Youtube channel. Currently, he is the cyber defense services senior leader for SOC, Threat hunting, DFIR, and Compromise assessment services in an MSSP company.

With new technology threats, rising international tensions, and state-sponsored cyber-attacks, cybersecurity is more important than ever. In organizations worldwide, there is not only a dire need for cybersecurity analysts, engineers, and consultants but the senior management executives and leaders are expected to be cognizant of the possible threats and risk management. The era of cyberwarfare is now upon us. What we do now and how we determine what we will do in the future is the difference between whether our businesses live or die and whether our digital self-survives the digital battlefield.  In this article, we'll discuss 6 titles from Packt’s bank of cybersecurity resources for everyone from an aspiring cybersecurity professional to an expert. Adversarial Tradecraft in Cybersecurity  A comprehensive guide that helps you master cutting-edge techniques and countermeasures to protect your organization from live hackers. It enables you to leverage cyber deception in your operations to gain an edge over the competition.  Little has been written about how to act when live hackers attack your system and run amok. Even experienced hackers sometimes tend to struggle when they realize the network defender has caught them and is zoning in on their implants in real-time. This book provides tips and tricks all along the kill chain of an attack, showing where hackers can have the upper hand in a live conflict and how defenders can outsmart them in this adversarial game of computer cat and mouse.  This book contains two subsections in each chapter, specifically focusing on the offensive and defensive teams. Pentesters to red teamers, SOC analysis to incident response, attackers, defenders, general hackers, advanced computer users, and security engineers should gain a lot from this book. This book will also be beneficial to those getting into purple teaming or adversarial simulations, as it includes processes for gaining an advantage over the other team.  The author, Dan Borges, is a passionate programmer and security researcher who has worked in security positions for companies such as Uber, Mandiant, and CrowdStrike. Dan has been programming various devices for >20 years, with 14+ years in the security industry.  Cybersecurity – Attack and Defense Strategies, Second Edition  A book that enables you to counter modern threats and employ state-of-the-art tools and techniques to protect your organization against cybercriminals. It is a completely revised new edition of the bestselling book, covering the very latest security threats and defense mechanisms including a detailed overview of Cloud Security Posture Management (CSPM) and an assessment of the current threat landscape, with additional focus on new IoT threats and cryptomining.  This book is for IT professionals venturing into the IT security domain, IT pentesters, security consultants, or those looking to perform ethical hacking. Prior knowledge of penetration testing is beneficial.  This book is authored by Yuri Diogenes and Dr. Erdal Ozkaya. Yuri Diogenes is a professor at EC-Council University for their master's degree in cybersecurity and a Senior Program Manager at Microsoft for Azure Security Center. Dr. Erdal Ozkaya is a leading Cybersecurity Professional with business development, management, and academic skills who focuses on securing Cyber Space and sharing his real-life skills as a Security Advisor, Speaker, Lecturer, and Author.  Cyber Minds  This book comprises insights on cybersecurity across the cloud, data, artificial intelligence, blockchain, and IoT to keep you cyber safe. Shira Rubinoff's Cyber Minds brings together the top authorities in cybersecurity to discuss the emergent threats that face industries, societies, militaries, and governments today. Cyber Minds serves as a strategic briefing on cybersecurity and data safety, collecting expert insights from sector security leaders. This book will help you to arm and inform yourself of what you need to know to keep your business – or your country – safe.  This book is essential reading for business leaders, the C-Suite, board members, IT decision-makers within an organization, and anyone with a responsibility for cybersecurity.  The author, Shira Rubinoff is a recognized cybersecurity executive, cybersecurity and blockchain advisor, global keynote speaker, and influencer who has built two cybersecurity product companies and led multiple women-in-technology efforts.  Cyber Warfare – Truth, Tactics, and Strategies  Cyber Warfare – Truth, Tactics, and Strategies is as real-life and up-to-date as cyber can possibly be, with examples of actual attacks and defense techniques, tools, and strategies presented for you to learn how to think about defending your own systems and data.  This book introduces you to strategic concepts and truths to help you and your organization survive on the battleground of cyber warfare. The book not only covers cyber warfare, but also looks at the political, cultural, and geographical influences that pertain to these attack methods and helps you understand the motivation and impacts that are likely in each scenario.  This book is for any engineer, leader, or professional with either responsibility for cybersecurity within their organizations, or an interest in working in this ever-growing field.  The author, Dr. Chase Cunningham holds a Ph.D. and M.S. in computer science from Colorado Technical University and a B.S. from American Military University focused on counter-terrorism operations in cyberspace.  Incident Response in the Age of Cloud  This book is a comprehensive guide for organizations on how to prepare for cyber-attacks and control cyber threats and network security breaches in a way that decreases damage, recovery time, and costs, facilitating the adaptation of existing strategies to cloud-based environments.  It is aimed at first-time incident responders, cybersecurity enthusiasts who want to get into IR, and anyone who is responsible for maintaining business security. This book will also interest CIOs, CISOs, and members of IR, SOC, and CSIRT teams. However, IR is not just about information technology or security teams, and anyone with legal, HR, media, or other active business roles would benefit from this book.   The book assumes you have some admin experience. No prior DFIR experience is required. Some infosec knowledge will be a plus but isn’t mandatory.  The author, Dr. Erdal Ozkaya, is a technically sophisticated executive leader with a solid education and strong business acumen. Over the course of his progressive career, he has developed a keen aptitude for facilitating the integration of standard operating procedures that ensure the optimal functionality of all technical functions and systems.  Cybersecurity Threats, Malware Trends, and Strategies   This book trains you to mitigate exploits, malware, phishing, and other social engineering attacks. After scrutinizing numerous cybersecurity strategies, Microsoft's former Global Chief Security Advisor provides unique insights on the evolution of the threat landscape and how enterprises can address modern cybersecurity challenges.    The book will provide you with an evaluation of the various cybersecurity strategies that have ultimately failed over the past twenty years, along with one or two that have actually worked. It will help executives and security and compliance professionals understand how cloud computing is a game-changer for them.  This book is designed to benefit senior management at commercial sector and public sector organizations, including Chief Information Security Officers (CISOs) and other senior managers of cybersecurity groups, Chief Information Officers (CIOs), Chief Technology Officers (CTOs), and senior IT managers who want to explore the entire spectrum of cybersecurity, from threat hunting and security risk management to malware analysis.  The author, Tim Rains worked at Microsoft for the better part of two decades where he held a number of roles including Global Chief Security Advisor, Director of Security, Identity and Enterprise Mobility, Director of Trustworthy Computing, and was a founding technical leader of Microsoft's customer-facing Security Incident Response team.  Summary  If you aspire to become a cybersecurity expert, any good study/reference material is as important as hands-on training and practical understanding. By choosing a suitable guide, one can drastically accelerate the learning graph and carve out one’s own successful career trajectory. 

When it comes to mobile operating systems, iOS 12 is generally considered to be one of the most secure — if not the leader — in mobile security. It's now a little more than a year old, and its features may be a bit overshadowed by the launch of iOS 13. Still, a considerable number of devices run iOS 12, and developers should know about its security features. Further Reading If you want to build iOS 12 applications from scratch with the latest Swift 4.2 language and Xcode 10, explore our book iOS 12 Programming for Beginners by Craig Clayton.  For beginners, this book starts by introducing you to iOS development as you learn Xcode 10 and Swift 4.2. You'll also study advanced iOS design topics, such as gestures and animations. The book also details new iOS 12 features, such as the latest in notifications, custom-UI notifications, maps, and the recent additions in Sirikit.  Below are the most prominent changes iOS 12 made in terms of security. Based on these changes, app developers can take advantage of several safety features if they want to build secure mobile apps for devices running on this OS. Major security features in iOS 12 iOS 12's biggest security upgrades were primarily outright new features. In general, these changes reflected a pivot towards privacy, i.e., giving users more control over how their data can be collected and used, as well as towards better password and device security. Default updating: Automatic software updates are now turned on by default. This feature is good news for developers — if they need to push an update that patches a major security flaw, most users will update to the more secure version of the app automatically. Users are also likely to have the most secure version of first-party apps and iOS 12. Password auditing: iOS 12's password auditing tools let users know when they've used the same password more than twice — devices themselves now encourage users to create strong and secure passwords when logging into their apps. The OS keeps a record of all passwords a user creates and stores them on the iCloud. While this feature may not sound particularly secure — especially considering iCloud's discovered security flaw last year — all these passwords are encrypted with AES-256. USB connection: If a user hasn't unlocked a device running iOS 12 in more than an hour, USB devices won't be able to connect. Safari upgrades: The mobile version of Safari will now, by default, prevent websites from using tracking cookies without explicit user permission. 2FA integration: iOS 12 offers better native integration with two-factor authentication (2FA). If an app uses 2FA and sends a security code to a user's phone over text, iOS 12 can autofill the security code field for the user. This may be a good reason for developers to consider implementing 2FA functionality if their apps don't already support it. Improvements in iOS 12 specific to app developers Other changes in iOS 12 were more subtle to end-users but more relevant to app developers. Automated password generation: Since iOS 11, developers have been able to label their password and username fields, allowing users to automatically populate these fields with saved passwords and usernames for a specific app or Safari webpage. With iOS 12's new functionality, users can have iOS 12 generate a unique, strong password that fills the password field once prompted by an app. In-house business app development: Apple now supports the development of in-house business apps. Businesses that partner with Apple through the Apple Developer Enterprise Program can develop apps that work only on specific, permitted devices. Sandboxed apps: By default, all third-party apps are now sandboxed and cannot directly access files modified by other apps. If an app needs to alter files outside of its specific home directory — which is randomly assigned by iOS 12 on install — it will do so through iOS. The same is true for all system files and resources. If an app needs to run a background process, it can do so only through system-provided APIs. Content sharing: Apps created by the same developer can share content — like user preferences and stored data — with each other when configured to be part of an App Group. App frameworks: New software development frameworks like HomeKit are now available to developers working with iOS 12. HomeKit allows developers to create apps that configure or otherwise communicate with smart home appliances and IoT devices. Likewise, SiriKit lets developers update their apps to work with user requests that originate from Siri and Maps. Editor’s tip: To learn more about SirKit you can through Chapter 24 of the book iOS 12 Programming for Beginners by Packt Publishing. Handoff: iOS 12's new Handoff feature allows developers to design apps and websites so that users can use an app one device, then seamlessly transfer their activity to another. The feature will be useful for developers working on apps that also have web versions. App Store review guideline updates with iOS 12 Along with the launch of iOS 12 came some changes to the App Store review guidelines. App developers will need to be aware of these if they want to continue developing programs for iOS devices. Apple now limits the amount of data, developers can collect from user's address books — and how apps are allowed to use this data. This fact doesn't bar developers from using an iPhone's address book to add social functionality to their apps. Developers can still scan a user's contact lists to allow users to send invites or to link users up with friends who also use a specific app. Developers, however, can't maintain and transfer databases of user address information. Apple also banned the selling of user info to third parties. Some tech analysts consider this a response to the Cambridge Analytica scandal of last year, as well as growing discontentment over how large companies were collecting and using user data. Depending on how a developer plans on using user data, these guidelines may not bring about huge changes. However, app designers may want to review what data collection is allowed and how they can use that data. Over time, iOS security updates have trended towards giving users more control over their data, apps less control over the system and developers more APIs for adding specific functionality. Following that trend, iOS 12 is built with user security in mind. For developers, implementing security features will be easier than it has been in the past — and they can also feel more confident that the devices accessing their app are secure. Some of these changes make apps more secure for developers — like the addition of password auditing and better 2FA authentication. Others, like app sandboxing and the updates to the app store review guidelines, may require more planning from app developers than Apple has asked for in the past. To start building iOS 12 applications of your own with Xcode 10 and Swift 4.2, the building blocks of iOS development, read the book iOS 12 Programming for Beginners by Packt Publishing. Author Bio Kayla Matthews writes about big data, cybersecurity, and technology. You can find her work on The Week, Information Age, KDnuggets and CloudTweaks, or over at ProductivityBytes.com.

It's no surprise that cybersecurity has become a major priority for global businesses of all sizes, often employing a dedicated IT team to focus on thwarting attacks. Huge budgets are spent on acquiring and integrating security solutions, but one of the most effective tools might be hiding in plain sight. Encouraging your own engineers and developers to purposely break systems through a process known as chaos engineering can drive a huge return on investment by identifying unknown weaknesses in your digital architecture. As modern networks become more complex with a vastly larger threat surface, stopping break-ins before they happen takes on even greater importance. Evolution of Cyberattacks Hackers typically have a background in software engineering and actually run their criminal enterprises in cycles that are similar to what happens in the development world. That means these criminals focus on iterations and agile changes to keep themselves one step ahead of security tools. Most hackers are focused on financial gains and look to steal data from enterprise or government systems for the purpose of selling it on the Dark Web. However, there is a demographic of cybercriminals focused on simply causing the most damage to certain organizations that they have targeted. In both scenarios, the hacker will first need to find a way to enter the perimeter of the network, either physically or digitally. Many cybercrimes now start with what's known as social engineering, where a hacker convinces an internal employee to divulge information that allows unauthorized access to take place. Principles of Chaos Engineering So how can you predict cyberattacks and stop hackers before they infiltrate your systems? That's where chaos engineering can help. The term first gained popularity a decade ago when Netflix created a tool called Chaos Monkey that would randomly take a node of their network offline to force teams to react accordingly. This proved effective because Netflix learned how to better keep their streaming service online and reduce dependencies between cloud servers. The Chaos Monkey tool can be seen as an example of a much broader practice: Chaos Engineering. The central insight of this form of testing is that, regardless of how all-encompassing your test suite is, as soon as your code is running on enough machines, errors are going to occur. In large, complex systems, it is essentially impossible to predict where these points of failure are going to occur. Rather than viewing this as a problem, chaos engineering sees it as an opportunity. Since failure is unavoidable, why not deliberately introduce it, and then attempt to solve randomly generated errors, in order to ensure your systems and processes can deal with the failure? For example, Netflix runs on AWS, but in response to frequent regional failures have changed their systems to become region agnostic. They have tested that this works using chaos engineering: they regularly take down important services in separate regions via a “chaos monkey” which randomly selects servers to take down, and challenges engineers to work around these failures. Though Netflix popularized the concept, chaos engineering, and testing is now used by many other companies, including Microsoft. The rise of cloud computing has meant that a high proportion of the systems running today have a similar level of complexity to Netflix’s server architecture. The cloud computing model has added a high level of complexity to online systems and the practice of chaos engineering will help to manage that over time, especially when it comes to cybersecurity. It's impossible to predict how and when a hacker will execute an attack, but chaos tests can help you be more proactive in patching your internal vulnerabilities. At first, your developers may be reluctant to jump into chaos activities since they will think their normal process works. However, there’s a good chance that, over time, they will grow to love chaos testing. You might have to do some convincing in the beginning, though, because this new approach likely goes against everything they’ve been taught about securing a network. Designing a Chaos Test Chaos tests need to be run in a controlled manner in order to be effective, and in many ways, the process lines up with the scientific method: in order to run a successful chaos test, you first need to identify a well-formed and refutable hypothesis. A test can then be designed that will prove (or more likely falsify) your hypothesis. For example, you might want to know how your network will react if one DNS server drops offline during a distributed denial of service (DDoS) attack by a hacker. This tactic of masking one’s IP address and overloading a website’s server can be executed through a VPN. Your hypothesis, in this case, is that you will be able to re-route traffic around the affected server. From there, you can begin designing and scheduling the experiment. If you are new to chaos engineering, you will want to restrict the test to a testing or staging environment to minimize the impact on live systems. Then make sure you have one person responsible for documenting the outcomes as the experiment begins. If you identify an issue during the first run of the chaos test, then you can pause that effort and focus on coming up with a solution plan. If not, expand the radius of the experiment until it produces worthwhile results. Running through this type of fire drill can be positive for various groups within a software organization, as it will provide practice for real incidents. Source: Medium How Chaos Engineering Fits Into Quality Assurance A lot of companies hear about chaos engineering and jump into it full-speed. But then over time they lose their enthusiasm for the practice or get distracted with other projects. So how should chaos tests be run and how do you ensure that they remain consistent and valuable? First, define the role of chaos engineering within your larger quality assurance efforts. In fact, your QA team may want to be the leaders of all chaos tests that are run. One important clarification is to distinguish between penetration tests and chaos tests. They both have the same goal of proactively finding system issues, but a penetration test is a specific event with a finite focus while chaos testing must be more open-ended. When teaching your teams about chaos engineering, it's vital to frame it as a practice and not a one-time activity. Return on investment will be hard to find if you do not systematically follow-up after chaos tests are run. The aim should be for continuous improvement to ensure your systems are prepared for any type of cyberattack. Final Thoughts These days, security vendors offer a wide range of tools designed to help companies protect their people, data, and infrastructure. Solutions like firewalls and virus scanners are certainly deployed to great success as part of most cybersecurity strategies, but they should never be treated as foolproof. Hackers are notorious at finding ways to get past these types of tools and exploit companies who are not prepared at a deeper level. The most mature organizations go one step further and find ways to proactively locate their own weaknesses before an outsider can expose them. Chaos engineering is a great way to accomplish this, as it encourages developers to look for gaps and bugs that they might not stumble upon normally. No matter how much planning goes into a system's architecture, unforeseen issues still come up, and hackers are a very dangerous variable in that equation. Author Bio Sam Bocetta is a freelance journalist specializing in U.S. diplomacy and national security, with emphasis on technology trends in cyberwarfare, cyberdefense, and cryptography.

On September 28, the National Security Agency revealed a vulnerability in Ghidra, a free, open-source software reverse-engineering tool. The NSA released the Ghidra toolkit at the RSA security conference in San Francisco on March 6, this year. The vulnerability, tracked as CVE-2019-16941, allows a remote attacker to compromise exposed systems, according to a NIST National Vulnerability Database description. This vulnerability is reported as medium severity and currently does not have a fix available. The NSA tweeted on its official account, “A flaw currently exists within Ghidra versions through 9.0.4. The conditions needed to exploit this flaw are rare and a patch is currently being worked. This flaw is not a serious issue as long as you don’t accept XML files from an untrusted source.” According to the bug description, the flaw manifests itself “when [Ghidra] experimental mode is enabled.” This “allows arbitrary code execution if the Read XML Files feature of Bit Patterns Explorer is used with a modified XML document,” the description further reads. “Researchers add since the feature is experimental, to begin with, it’s already an area to expect bugs and vulnerabilities. They also contend, that despite descriptions of how the bug can be exploited, it can’t be triggered remotely,” Threatpost reports. Ghidra, a disassembler written in Java, breaks down executable files into assembly code that can then be analyzed. By deconstructing malicious code and malware, cybersecurity professionals can gain a better understanding of potential vulnerabilities in their networks and systems. The NSA has used it internally for years, and recently decided to open-source it. Other instances when bugs have been found in Ghidra include, in March, a proof-of-concept was released showing how an XML external entity (XXE) vulnerability (rated serious) can be exploited to attack Ghidra project users (version 9.0 and below). In July, researchers found an additional path-retrieval bug (CVE-2019-13623) that was also rated high severity. The bug, similar to CVE-2019-1694, also impacts the ghidra.app.plugin.core.archive and allows an attacker to achieve arbitrary code execution on vulnerable systems, Threatpost reports. Researchers said they are unaware that this most recent bug (CVE-2019-16941) has been exploited in the wild. To know more about this news in detail, read the bug description. A Cargo vulnerability in Rust 1.25 and prior makes it ignore the package key and download a wrong dependency 10 times ethical hackers spotted a software vulnerability and averted a crisis A zero-day pre-auth vulnerability is currently being exploited in vBulletin, reports an anonymous researcher

On September 26, a few researchers from the Delft University of Technology (TU Delft) in the Netherlands, released a research paper which highlighted the importance of crowdsource ethical hacking approaches for enhancing IoT vulnerability management. They have focussed on Bug Bounty Programs (BBP) and Responsible Disclosure (RD), which stimulate hackers to report vulnerabilities in exchange for monetary rewards. Supported by literature survey and expert interviews, these researchers carried out an investigation on how BBP and RD can facilitate the practice of identifying, classifying, prioritizing, remediating, and mitigating IoT vulnerabilities in an effective and cost-efficient manner. The researchers have also made recommendations on how BBP and RD can be integrated with the existing security practices to further boost the IoT security. The researchers first identified the causes for lack of security practices in IoT from socio-technical and commercial perspectives. By identifying the hidden pitfalls and blind spots, stakeholders can avoid repeating the same mistakes. They have also derived a set of recommendations as best-practices that can benefit IoT vendors, developers, and regulators. The researcher in their paper added, “We note that this study does not intend to cover all the potential vulnerabilities in IoT nor to provide an absolute solution to cure the IoT security puzzle. Instead, our focus is to provide practical and tangible recommendations and potentially new options for stakeholders to tackle IoT-oriented vulnerabilities in consumer goods, which will help enhance the overall IoT security practices.” Challenges in IoT Security The researchers have highlighted six major reasons from the system and device perspective: IoT systems do not have well-defined perimeters as they can continuously change. IoT systems are highly heterogeneous with respect to communication medium and protocols. IoT systems often include devices that are not designed to be connected to the Internet or for being secure. IoT devices can often autonomously control other IoT devices without human supervision. IoT devices could be physically unprotected and/or controlled by different parties. The large number of devices increases the security complexity The other practical challenges for IoT include the fact that enterprises targeting end-users do not have security as a priority and are generally driven by time-to-market instead of by security requirements. Several IoT products are the results of an increasing number of startup companies that have entered this market recently. This vast majority of startups accounts for less than 10 employees, and their obvious priority is to develop functional rather than secure products. In this scenario, investing in security can be perceived as a costly and time-consuming obstacle. In addition, consumers demand for security is low, and they tend to prefer cheaper rather than secure products. As a result, companies lack explicit incentives to invest in security. Crowdsourced security methods: An alternative in Ethical Hacking "Government agencies and business organizations today are in constant need of ethical hackers to combat the growing threat to IT security. A lot of government agencies, professionals and corporations now understand that if you want to protect a system, you cannot do it by just locking your doors," the researchers observe. The benefits of Ethical Hacking include: Preventing data from being stolen and misused by malicious attackers. Discovering vulnerabilities from an attacker’s point of view so to fix weak points. Implementing a secure network that prevents security breaches. Protecting networks with real-world assessments. Gaining trust from customers and investors by ensuring security. Defending national security by protecting data from terrorism. Bug bounty benefits and Responsible Disclosure The alternative for Pen Testing in Ethical Hacking is Crowdsourced security methods. These methods involve the participation of large numbers of ethical hackers, reporting vulnerabilities to companies in exchange for rewards that can consist of money or, just recognition. Similar practices have been utilized at large scale in the software industry. For example, the Vulnerability Rewards Programs (VRP) which have been applied to Chrome and Firefox, yielding several lessons on software security development. As per results, the Chrome VRP has cost approximately $580,000 over 3 years and has resulted in 501 bounties paid for the identification of security vulnerabilities. Crowdsource methods involve thousands of hackers working on a security target. In specific, instead of a point-in-time test, crowdsourcing enables continuous testing. In addition, as compared with Pen Testing, crowdsourcing hackers are only paid when a valid vulnerability is reported. Let us in detail understand Bug Bounty Programs (BBP) and Responsible Disclosure (RD). How do Bug Bounty Programs (BBP) work? Also known as Bug Bounties, the BBP represents reward-driven crowdsourced security testing where ethical hackers who successfully discover and report vulnerabilities to companies are rewarded. The BBPs can further be classified into public and private programs. Public programs allow entire communities of ethical hackers to participate in the program. They typically consist of large scale bug bounty programs and can be both time-limited and open-ended. Private programs, on the other hand, are generally limited to a selected sub-group of hackers, scoped to specific targets, and limited in time. These programs usually take place through commercial bug bounty platforms, where hackers are selected based on reputation, skills, and experience. The main platform vendors that included BBP are HackerOne, BugCrowd, Cobalt Labs, and Synack. Those platforms have facilitated establishing and maintaining BBPs for organizations. What is Responsible Disclosure (RD)? Also known as coordinated vulnerability disclosure, RD consists of rules and guidelines from companies that allow individuals to report vulnerabilities to organizations. The RD policies will define the models for a controlled and responsible disclosure of information upon vulnerabilities discovered by users. Here, most of the software vulnerabilities are discovered by both benign users and ethical hackers. In many situations, individuals might feel responsible for reporting the vulnerability to the organization, but companies may lack a channel for them to report the found vulnerabilities. Hence three different outcomes might occur including failed disclosure, full disclosure, and organization capture. Among these three, the target of RD is the organization capture where companies create a safe channel and provide rules for submitting vulnerabilities to their security team, and further allocate resources to follow up the process. One limitation of this qualitative study is that only experts that were conveniently available participated in the interview. The experts that participated in the research were predominantly from the Netherlands (13 experts), and more in general all from Europe, the results should be generalized with regard to other countries and the whole security industry. For IoT vulnerability management, the researchers recommend launching BBP only after companies have performed initial security testing and fixed the problems. The objective of BBP and RD policies should always be to provide additional support in finding undetected vulnerabilities, and never to be the only security practice. To know more about this study in detail, read the original research paper. How Blockchain can level up IoT Security How has ethical hacking benefited the software industry MITRE’s 2019 CWE Top 25 most dangerous software errors list released

Two days ago, the Cybersecurity and Infrastructure Security Agency (CISA) announced MITRE’s 2019 Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Errors list. This list includes a compilation of the most frequent and critical errors that can lead to serious vulnerabilities in software. For aggregating the data for this list, the CWE Team used a data-driven approach that leverages published Common Vulnerabilities and Exposures (CVE®) data and related CWE mappings found within the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD), as well as the Common Vulnerability Scoring System (CVSS) scores associated with the CVEs. The team then applied a scoring formula (elaborated in later sections) to determine the level of prevalence and danger each weakness presents.  This Top 25 list of errors include the NVD data from the years 2017 and 2018, which consisted of approximately twenty-five thousand CVEs. The previous SANS/CWE Top 25 list was released in 2011 and the major difference between the lists released in the year 2011 and the current 2019 is in the approach used. In 2011, the data was constructed using surveys and personal interviews with developers, top security analysts, researchers, and vendors. These responses were normalized based on the prevalence, ranked by the CWSS methodology. However, in the 2019 CWE Top 25, the list was formed based on the real-world vulnerabilities found in NVD’s data. CWE Top 25 dangerous software errors, developers should watch out for  Improper Restriction of Operations within the Bounds of a Memory Buffer In this error(CWE-119), the software performs operations on a memory buffer. However, it can read from or write to a memory location that is outside of the intended boundary of the buffer. The likelihood of exploit of this error is high as an attacker may be able to execute arbitrary code, alter the intended control flow, read sensitive information, or cause the system to crash.  This error can be exploited in any programming language without memory management support to attempt an operation outside of the bounds of a memory buffer, but the consequences will vary widely depending on the language, platform, and chip architecture. Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') This error, CWE-79, can cause the software to incorrectly neutralize the user-controllable input before it is placed in output that is used as a web page that is served to other users. Once the malicious script is injected, the attacker could transfer private information, such as cookies that may include session information, from the victim's machine to the attacker. This error can also allow attackers to send malicious requests to a website on behalf of the victim, which could be especially dangerous to the site if the victim has administrator privileges to manage that site. Such XSS flaws are very common in web applications since they require a great deal of developer discipline to avoid them. Improper Input Validation With this error, CWE-20, the product does not validate or incorrectly validates input thus affecting the control flow or data flow of a program. This can allow an attacker to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in an altered control flow, arbitrary control of a resource, or arbitrary code execution. Input validation is problematic in any system that receives data from an external source. “CWE-116 [Improper Encoding or Escaping of Output] and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message,” the researchers mention in the CWE definition post.  Information Exposure This error, CWE-200, is the intentional or unintentional disclosure of information to an actor that is not explicitly authorized to have access to that information. According to the CEW- Individual Dictionary Definition, “Many information exposures are resultant (e.g. PHP script error revealing the full path of the program), but they can also be primary (e.g. timing discrepancies in cryptography). There are many different types of problems that involve information exposures. Their severity can range widely depending on the type of information that is revealed.” This error can be executed for specific named Languages, Operating Systems, Architectures, Paradigms(Mobiles), Technologies, or a class of such platforms. Out-of-bounds Read In this error, CWE-125, the software reads data past the end, or before the beginning, of the intended buffer. This can allow attackers to read sensitive information from other memory locations or cause a crash. The software may modify an index or perform pointer arithmetic that references a memory location that is outside of the boundaries of the buffer.  This error may occur for specific named Languages (C, C++), Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms.  Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') In this error (weakness ID: CWE-89) the software constructs all or part of an SQL command using externally-influenced input from an upstream component. However, it incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. This error can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database, possibly including the execution of system commands. It can occur in specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. Cross-Site Request Forgery (CSRF) This error CWE-352, the web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request. This might allow an attacker to trick a client into making an unintentional request to the webserver which will be treated as an authentic request. The likelihood of the occurrence of this error is medium.  This can be done via a URL, image load, XMLHttpRequest, etc. and can result in the exposure of data or unintended code execution.  Integer Overflow or Wraparound In this error, CWE-190, the software performs a calculation that can produce an integer overflow or wraparound, when the logic assumes that the resulting value will always be larger than the original value. This can introduce other weaknesses when the calculation is used for resource management or execution control. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') In this error, CWE-22, the software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory. However, the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.  In most programming languages, injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to widen the scope of attack. For example, when the software adds ".txt" to any pathname, this may limit the attacker to text files, but a null injection may effectively remove this restriction. Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') In this error, CWE-78, the software constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. This error can allow attackers to execute unexpected, dangerous commands directly on the operating system. This weakness can lead to a vulnerability in environments in which the attacker does not have direct access to the operating system, such as in web applications.  Alternately, if the weakness occurs in a privileged program, it could allow the attacker to specify commands that normally would not be accessible, or to call alternate commands with privileges that the attacker does not have. The researchers write, “More investigation is needed into the distinction between the OS command injection variants, including the role with argument injection (CWE-88). Equivalent distinctions may exist in other injection-related problems such as SQL injection.” Here’s the list of the remaining errors from MITRE’s 2019 CWE Top 25 list: CWE ID Name of the Error Average CVSS score CWE-416 Use After Free 17.94 CWE-287 Improper Authentication 10.78 CWE-476 NULL Pointer Dereference 9.74 CWE-732  Incorrect Permission Assignment for Critical Resource 6.33 CWE-434 Unrestricted Upload of File with Dangerous Type 5.50 CWE-611 Improper Restriction of XML External Entity Reference 5.48 CWE-94 Improper Control of Generation of Code ('Code Injection') 5.36 CWE-798 Use of Hard-coded Credentials 5.1 CWE-400 Uncontrolled Resource Consumption 5.04 CWE-772  Missing Release of Resource after Effective Lifetime 5.04 CWE-426  Untrusted Search Path 4.40 CWE-502 Deserialization of Untrusted Data 4.30 CWE-269 Improper Privilege Management 4.23 CWE-295 Improper Certificate Validation 4.06 To know about the other errors in detail, read CWE’s official report. Scoring formula to calculate the rank of weaknesses The CWE team had developed a scoring formula to calculate a rank order of weaknesses. The scoring formula combines the frequency that a CWE is the root cause of vulnerability with the projected severity of its exploitation. In both cases, the frequency and severity are normalized relative to the minimum and maximum values seen.  A few properties of the scoring method include: Weaknesses that are rarely exploited will not receive a high score, regardless of the typical severity associated with any exploitation. This makes sense, since if developers are not making a particular mistake, then the weakness should not be highlighted in the CWE Top 25. Weaknesses with a low impact will not receive a high score. This again makes sense, since the inability to cause significant harm by exploiting a weakness means that weakness should be ranked below those that can.  Weaknesses that are both common and can cause harm should receive a high score. However, there are a few limitations to the methodology of the data-driven approach chosen by the CWE Team. Limitations of the data-driven methodology This approach only uses data publicly reported and captured in NVD, while numerous vulnerabilities exist that do not have CVE IDs. Vulnerabilities that are not included in NVD are therefore excluded from this approach. For vulnerabilities that receive a CVE, often there is not enough information to make an accurate (or precise) identification of the appropriate CWE that is exploited.  There is an inherent bias in the CVE/NVD dataset due to the set of vendors that report vulnerabilities and the languages that are used by those vendors. If one of the largest contributors to CVE/NVD primarily uses C as its programming language, the weaknesses that often exist in C programs are more likely to appear.  Another bias in the CVE/NVD dataset is that most vulnerability researchers and/or detection tools are very proficient at finding certain weaknesses but do not find other types of weaknesses. Those types of weaknesses that researchers and tools struggle to find will end up being under-represented within 2019 CWE Top 25. Gaps or perceived mischaracterizations of the CWE hierarchy itself lead to incorrect mappings.  In Metric bias, it indirectly prioritizes implementation flaws over design flaws, due to their prevalence within individual software packages. For example, a web application may have many different cross-site scripting (XSS) vulnerabilities due to a large attack surface, yet only one instance of the use of an insecure cryptographic algorithm. https://twitter.com/mattfahrner/status/1173984732926943237 To know more about this CWE Top 25 list in detail, head over to MITRE’s CWE Top 25 official page.  Other news in Security LastPass patched a security vulnerability from the extensions generated on pop-up windows An unsecured Elasticsearch database exposes personal information of 20 million Ecuadoreans including 6.77M children under 18 A new Stuxnet-level vulnerability named Simjacker used to secretly spy over mobile phones in multiple countries for over 2 years: Adaptive Mobile Security reports

Updated: On September 27, a few researchers from the Security Research Labs (SRLabs) released five key research findings based on the extent of Simjacker and how one can understand whether is SIM is vulnerable to such an exploit. Yesterday, Adaptive Mobile Security made a breakthrough announcement revealing a new vulnerability which the firm calls Simjacker has been used by attackers to spy over mobile phones. Researchers at Adaptive Mobile Security believe the vulnerability has been exploited for at least the last 2 years “by a highly sophisticated threat actor in multiple countries, primarily for the purposes of surveillance.” They further added that the Simjacker vulnerability “is a huge jump in complexity and sophistication compared to attacks previously seen over mobile core networks. It represents a considerable escalation in the skillset and abilities of attackers seeking to exploit mobile networks.” Also Read: 25 million Android devices infected with ‘Agent Smith’, a new mobile malware How Simjacker attack works and why it is a grave threat In the Simjacker attack, an SMS that contains a specific spyware-like code is sent to a victim’s mobile phone. This SMS when received, instructs the UICC (SIM Card) within the phone to ‘take over’ the mobile phone, in order to retrieve and perform sensitive commands. “During the attack, the user is completely unaware that they received the SMS with the Simjacker Attack message, that information was retrieved, and that it was sent outwards in the Data Message SMS - there is no indication in any SMS inbox or outbox,” the researchers mention on their official blog post. Source: Adaptive Mobile Security The Simjacker attack relies on the S@T(SIMalliance Toolbox ‘pronounced as sat’) browser software as an execution environment. The S@T browser, an application specified by the SIMalliance, can be installed on different UICC (SIM cards), including eSIMs. The S@T browser software is quite old and unpopular with an initial aim to enable services such as getting your account balance through the SIM card. The software specifications have not been updated since 2009 and have been superseded by many other technologies since then. Researchers say they have observed the “S@T protocol being used by mobile operators in at least 30 countries whose cumulative population adds up to over a billion people, so a sizable amount of people are potentially affected. It is also highly likely that additional countries have mobile operators that continue to use the technology on specific SIM cards.” Simjacker attack is a next-gen SMS attack Simjacker attack is unique. Previous SMS malware involved sending links to malware. However, the Simjacker Attack Message carries a complete malware payload, specifically spyware with instructions for the SIM card to execute the attack. Simjacker attack can do more than simply tracking the user’s location and user’s personal data. By modifying the attack message, the attacker could instruct the UICC to execute a range of other attacks. This is because the same method allows an attacker to have complete access to the STK command set including commands such as launch browser, send data, set up a call, and much more. Also Read: Using deep learning methods to detect malware in Android Applications The researchers used these commands in their own tests and were successfully able to make targeted handsets open up web browsers, ring other phones, send text messages and so on. They further highlighted other purposes this attack could be used for: Mis-information (e.g. by sending SMS/MMS messages with attacker-controlled content) Fraud (e.g. by dialling premium rate numbers), Espionage (as well as the location retrieving attack an attacked device it could function as a listening device, by ringing a number), Malware spreading (by forcing a browser to open a web page with malware located on it) Denial of service (e.g by disabling the SIM card) Information retrieval (retrieve other information like language, radio type, battery level etc.) The researchers highlight another benefit of the Simjacker attack for the attackers: many of its attacks seem to work independent of handset types, as the vulnerability is dependent on the software on the UICC and not the device. Adaptive Mobile says behind the Simjacker attack is a “specific private company that works with governments to monitor individuals.” This company also has extensive access to the SS7 and Diameter core network. Researchers said that in one country, roughly 100-150 specific individual phone numbers being targeted per day via Simjacker attacks. Also, a few phone numbers had been tracked a hundred times over a 7-day period, suggesting they belonged to high-value targets. Source: Adaptive Mobile Security The researchers added that they have been “working with our own mobile operator customers to block these attacks, and we are grateful for their assistance in helping detect this activity.” They said they have also communicated to the GSM Association – the trade body representing the mobile operator community - the existence of this vulnerability. This vulnerability has been managed through the GSMA CVD program, allowing information to be shared throughout the mobile community. “Information was also shared to the SIM alliance, a trade body representing the main SIM Card/UICC manufacturers and they have made new security recommendations for the S@T Browser technology,” the researchers said. “The Simjacker exploit represents a huge, nearly Stuxnet-like, leap in complexity from previous SMS or SS7/Diameter attacks, and show us that the range and possibility of attacks on core networks are more complex than we could have imagined in the past,” the blog mentions. The Adaptive Mobile Security team will present more details about the Simjacker attack in a presentation at Virus Bulletin Conference, London, on 3rd October 2019. https://twitter.com/drogersuk/status/1172194836985913344 https://twitter.com/campuscodi/status/1172141255322689537   To know more about the Simjacker attack in detail, read Adaptive Mobile’s official blog post. SRLabs researchers release protection tools against Simjacker and other SIM-based attacks On September 27, a few researchers from the Security Research Labs (SRLabs) released five key findings based on the extent of Simjacker and how one can understand whether is SIM is vulnerable to such an exploit. The researchers have highlighted five key findings in their research report and also provided an FAQ for users to implement necessary measures. Following are the five key research findings the SRLabs researchers mention: Around 6% of 800 tested SIM cards in recent years were vulnerable to Simjacker A second, previously unreported, vulnerability affects an additional 3.5% of SIM cards The tool SIMtester  provides a simple way to check any SIM card for both vulnerabilities (and for a range of other issues reported in 2013) The SnoopSnitch Android app warns users about binary SMS attacks including Simjacker since 2014. (Attack alerting requires a rooted Android phone with Qualcomm chipset.) A few Simjacker attacks have been reported since 2016 by the thousands of SnoopSnitch users that actively contribute data To know about these key findings by SRLabs' researchers in detail, read the official report. Other interesting news in Security Endpoint protection, hardening, and containment strategies for ransomware attack protection: CISA recommended FireEye report Highlights Intel’s DDIO and RDMA enabled microprocessors vulnerable to new NetCAT attack Wikipedia hit by massive DDoS (Distributed Denial of Service) attack; goes offline in many countries

Last week, the Cybersecurity and Infrastructure Security Agency (CISA) shared some strategies with users and organizations to prevent, mitigate, and recover against ransomware. They said, “The Cybersecurity and Infrastructure Security Agency (CISA) has observed an increase in ransomware attacks across the Nation. Helping organizations protect themselves from ransomware is a chief priority for CISA.” They have also advised that those attacked by ransomware should report immediately to CISA, a local FBI Field Office, or a Secret Service Field Office. In the three resources shared, the first two include general awareness about what ransomware is and why it is a major threat, mitigations, and much more. The third resource is a FireEye report on ransomware protection and containment strategies. Also Read: Vulnerabilities in the Picture Transfer Protocol (PTP) allows researchers to inject ransomware in Canon’s DSLR camera CISA INSIGHTS and best practices to prevent ransomware The CISA, as a part of their first “CISA INSIGHTS” product, has put down three simple steps or recommendations organizations can take to manage their cybersecurity risk. CISA advises users to take necessary precautionary steps such as backing up the entire system offline, keeping the system updated and patched, update security solutions, and much more. If users have been affected by ransomware, they should contact the CISA or FBI immediately, work with an experienced advisor to help recover from the attack, isolate the infected systems and phase your return to operations, etc. Further, the CISA also tells users to practice good cyber hygiene, i.e. backup, update, whitelist apps, limit privilege, and using multi-factor authentication. Users should also develop containment strategies that will make it difficult for bad actors to extract information. Users should also review disaster recovery procedures and validate goals with executives, and much more. The CISA team has suggested certain best practices which the organizations should employ to stay safe from a ransomware attack. These include, users should restrict permissions to install and run software applications, and apply the principle of “least privilege” to all systems and services thus, limiting ransomware to spread further. The organization should also ensure using application whitelisting to allow only approved programs to run on a network. All firewalls should be configured to block access to known malicious IP addresses. Organizations should also enable strong spam filters to prevent phishing emails from reaching the end users and authenticate inbound emails to prevent email spoofing. A measure to scan all incoming and outgoing emails to detect threats and filter executable files from reaching end-users should be initiated. Read the entire CISA INSIGHTS to know more about the various ransomware outbreak strategies in detail. Also Read: ‘City Power Johannesburg’ hit by a ransomware attack that encrypted all its databases, applications and network FireEye report on Ransomware Protection and Containment strategies As a third resource, the CISA shared a FireEye report titled “Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment”. In this whitepaper, FireEye discusses different steps organizations can proactively take to harden their environment to prevent the downstream impact of a ransomware event. These recommendations can also help organizations with prioritizing the most important steps required to contain and minimize the impact of a ransomware event after it occurs. The FireEye report points out that any ransomware can be deployed across an environment in two ways. First, by Manual propagation by a threat actor after they have penetrated an environment and have administrator-level privileges broadly across the Environment to manually run encryptors on the targeted system through Windows batch files, Microsoft Group Policy Objects, and existing software deployment tools used by the victim’s organization. Second, by Automated propagation where the credential or Windows token is extracted directly from disk or memory to build trust relationships between systems through Windows Management Instrumentation, SMB, or PsExec. This binds systems and executes payloads. Hackers also automate brute-force attacks on unpatched exploitation methods, such as BlueKeep and EternalBlue. “While the scope of recommendations contained within this document is not all-encompassing, they represent the most practical controls for endpoint containment and protection from a ransomware outbreak,” FireEye researchers wrote. To combat these two deployment techniques, the FireEye researchers have suggested two enforcement measures which can limit the capability for a ransomware or malware variant to impact a large scope of systems within an environment. The FireEye report covers several technical recommendations to help organizations mitigate the risk of and contain ransomware events some of which include: RDP Hardening Remote Desktop Protocol (RDP) is a common method used by malicious actors to remotely connect to systems, laterally move from the perimeter onto a larger scope of systems for deploying malware. Organizations should also scan their public IP address ranges to identify systems with RDP (TCP/3389) and other protocols (SMB – TCP/445) open to the Internet in a proactive manner. RDP and SMB should not be directly exposed to ingress and egress access to/from the Internet. Other measures that organizations can take include: Enforcing Multi-Factor Authentication Organizations can either integrate a third-party multi-factor authentication technology or leverage a Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS. Leveraging Network Level Authentication (NLA) Network Level Authentication (NLA) provides an extra layer of pre-authentication before a connection is established. It is also useful for protecting against brute force attacks, which mostly target open internet-facing RDP servers. Reducing the exposure of privileged and service accounts For ransomware deployment throughout an environment, both privileged and service accounts credentials are commonly utilized for lateral movement and mass propagation. Without a thorough investigation, it may be difficult to determine the specific credentials that are being utilized by a ransomware variant for connectivity within an environment. Privileged account and service account logon restrictions For accounts having privileged access throughout an environment, these should not be used on standard workstations and laptops, but rather from designated systems (e.g., Privileged Access Workstations (PAWS)) that reside in restricted and protected VLANs and Tiers. Explicit privileged accounts should be defined for each Tier, and only utilized within the designated Tier. The recommendations for restricting the scope of access for privileged accounts is based upon Microsoft’s guidance for securing privileged access. As a quick containment measure, consider blocking any accounts with privileged access from being able to login (remotely or locally) to standard workstations, laptops, and common access servers (e.g., virtualized desktop infrastructure). If a service account is only required to be leveraged on a single endpoint to run a specific service, the service account can be further restricted to only permit the account’s usage on a predefined listing of endpoints. Protected Users Security Group With the “Protected Users” security group for privileged accounts, an organization can minimize various risk factors and common exploitation methods for exposing privileged accounts on endpoints. Starting from Microsoft Windows 8.1 and Microsoft Windows Server 2012 R2 (and above), the “Protected Users” security group was introduced to manage credential exposure within an environment. Members of this group automatically have specific protections applied to their accounts, including: The Kerberos ticket granting ticket (TGT) expires after 4 hours, rather than the normal 10-hour default setting.  No NTLM hash for an account is stored in LSASS since only Kerberos authentication is used (NTLM authentication is disabled for an account).  Cached credentials are blocked. A Domain Controller must be available to authenticate the account. WDigest authentication is disabled for an account, regardless of an endpoint’s applied policy settings. DES and RC4 can’t be used for Kerberos pre-authentication (Server 2012 R2 or higher); rather Kerberos with AES encryption will be enforced. Accounts cannot be used for either constrained or unconstrained delegation (equivalent to enforcing the “Account is sensitive and cannot be delegated” setting in Active Directory Users and Computers). Cleartext password protections Organizations should also try minimizing the exposure of credentials and tokens in memory on endpoints. On older Windows Operating Systems, cleartext passwords are stored in memory (LSASS) to primarily support WDigest authentication. The WDigest should be explicitly disabled on all Windows endpoints where it is not disabled by default. WDigest authentication is disabled in Windows 8.1+ and in Windows Server 2012 R2+, by default. Starting from Windows 7 and Windows Server 2008 R2, after installing Microsoft Security Advisory KB2871997, WDigest authentication can be configured either by modifying the registry or by using the “Microsoft Security Guide” Group Policy template from the Microsoft Security Compliance Toolkit. To implement these and other ransomware protection and containment strategies, read the FireEye report. Other interesting news in Cybersecurity Wikipedia hit by massive DDoS (Distributed Denial of Service) attack; goes offline in many countries Exim patches a major security bug found in all versions that left millions of Exim servers vulnerable to security attacks CircleCI reports of a security breach and malicious database in a third-party vendor account

Updated with Valve’s response: Valve, in a statement on August 22, said that its HackerOne bug bounty program, should not have turned away Kravets when he reported the second vulnerability and called it “a mistake”. A Russian security researcher, Vasily Kravets, has found a second zero-day vulnerability in the Steam gaming platform, in a span of two weeks. The researcher said he reported the first Steam zero-day vulnerability earlier in August, to its parent company, Valve, and tried to have it fixed before public disclosure. However, “he said he couldn't do the same with the second because the company banned him from submitting further bug reports via its public bug bounty program on the HackerOne platform,” ZDNet reports. Source: amonitoring.ru This first flaw was a “privilege-escalation vulnerability that can allow an attacker to level up and run any program with the highest possible rights on any Windows computer with Steam installed. It was released after Valve said it wouldn’t fix it (Valve then published a patch, that the same researcher said can be bypassed),” according to Threatpost. Although Kravets was banned from the Hacker One platform, he disclosed the second flaw that enables a local privilege escalation in the Steam client on Tuesday and said that the flaw would be simple for any OS user to exploit. Kravets told Threatpost that he is not aware of a patch for the vulnerability. “Any user on a PC could do all actions from exploit’s description (even ‘Guest’ I think, but I didn’t check this). So [the] only requirement is Steam,” Kravets told Threatpost. He also said, “It’s sad and simple — Valve keeps failing. The last patch, that should have solved the problem, can be easily bypassed so the vulnerability still exists. Yes, I’ve checked, it works like a charm.” Another security researcher, Matt Nelson also said he had found the exact same bug as Kravets had, which “he too reported to Valve's HackerOne program, only to go through a similar bad experience as Kravets,” ZDNet reports. He said both Valve and HackerOne took five days to acknowledge the bug and later refused to patch it. Further, they locked the bug report when Nelson wanted to disclose the bug publicly and warn users. “Nelson later released proof-of-concept code for the first Steam zero-day, and also criticized Valve and HackerOne for their abysmal handling of his bug report”, ZDNet reports. https://twitter.com/enigma0x3/status/1148031014171811841 “Despite any application itself could be harmful, achieving maximum privileges can lead to much more disastrous consequences. For example, disabling firewall and antivirus, rootkit installation, concealing of process-miner, theft any PC user’s private data — is just a small portion of what could be done,”  said Kravets. Kravets demonstrated the second Steam zero-day and also detailed the vulnerability on his website. Per Threatpost as of August 21, “Valve did not respond to a request for comment about the vulnerability, bug bounty incident and whether a patch is available. HackerOne did not have a comment.” Other researchers who have participated in Valve’s bug bounty program are infuriated over Valve’s decision to not only block Kravets from submitting further bug reports, but also refusing to patch the flaw. https://twitter.com/Viss/status/1164055856230440960 https://twitter.com/kamenrannaa/status/1164408827266998273 A user on Reddit writes, “If management isn't going to take these issues seriously and respect a bug bounty program, then you need to bring about some change from within. Now they are just getting bug reports for free.” Nelson said the Hacker One “representative said the vulnerability was out of scope to qualify for Valve’s bug bounty program,” Ars Technica writes. Further, when Nelson said that he was not seeking any monetary gains and only wanted the public to be aware of the vulnerability, the HackerOne representative asked Nelson to “please familiarize yourself with our disclosure guidelines and ensure that you’re not putting the company or yourself at risk. https://www.hackerone.com/disclosure-guidelines.” https://twitter.com/enigma0x3/status/1160961861560479744 Nelson also reported the vulnerability directly to Valve. Valve, first acknowledged the report and “noted that I shouldn’t expect any further communication.” He never heard anything more from the company. In am email to Ars Technica, Nelson writes, “I can certainly believe that the scoping was misinterpreted by HackerOne staff during the triage efforts. It is mind-blowing to me that the people at HackerOne who are responsible for triaging vulnerability reports for a company as large as Valve didn’t see the importance of Local Privilege Escalation and simply wrote the entire report off due to misreading the scope.” A HackerOne spokeswoman told Ars Technica, “We aim to explicitly communicate our policies and values in all cases and here we could have done better. Vulnerability disclosure is an inherently murky process and we are, and have always been, committed to protecting the interests of hackers. Our disclosure guidelines emphasize mutual respect and empathy, encouraging all to act in good faith and for the benefit of the common good.” Katie Moussouris, founder and CEO of Luta Security, also said, “Silencing the researcher on one issue is in complete violation of the ISO standard practices, and banning them from reporting further issues is simply irresponsible to affected users who would otherwise have benefited from these researchers continuing to engage and report issues privately to get them fixed. The norms of vulnerability disclosure are being warped by platforms that put profits before people.” Valve agrees that turning down Kravets’ request was “a mistake” Valve, in a statement on August 22, said that its HackerOne bug bounty program, should not have turned away Kravets when he reported the second vulnerability and called it a mistake. In an email statement to ZDNet, a Valve representative said that “the company has shipped fixes for the Steam client, updated its bug bounty program rules, and is reviewing the researcher's ban on its public bug bounty program.” The company also writes, “Our HackerOne program rules were intended only to exclude reports of Steam being instructed to launch previously installed malware on a user’s machine as that local user. Instead, misinterpretation of the rules also led to the exclusion of a more serious attack that also performed local privilege escalation through Steam.  In regards to the specific researchers, we are reviewing the details of each situation to determine the appropriate actions. We aren’t going to discuss the details of each situation or the status of their accounts at this time.” To know more about this news in detail, read Kravets’ blog post. You could also check out Threatpost’s detailed coverage. Puppet launches Puppet Remediate, a vulnerability remediation solution for IT Ops A second zero-day found in Firefox was used to attack Coinbase employees; fix released in Firefox 67.0.4 and Firefox ESR 60.7.2 The EU Bounty Program enabled in VLC 3.0.7 release, this version fixed the most number of security issue

At the DefCon 27, Eyal Itkin, a vulnerability researcher at Check Point Software Technologies, demonstrated how vulnerabilities in the Picture Transfer Protocol (PTP) allowed him to infect a Canon EOS 80D DSLR with ransomware over a rogue WiFi connection. The PTP along with image transfer also contains dozens of different commands that support anything from taking a live picture to upgrading the camera’s firmware. The researcher chose Canon’s EOS 80D DSLR camera for three major reasons: Canon is the largest DSLR maker, controlling more than 50% of the market. The EOS 80D supports both USB and WiFi. Canon has an extensive “modding” community, called Magic Lantern, an open-source free software add-on that adds new features to the Canon EOS cameras. Eyal Itkin highlighted six vulnerabilities in the PTP that can easily allow a hacker to infiltrate the DSLRs and inject ransomware and lock the device. Next, the users might have to pay ransom to free up their camera and picture files. CVE-2019-5994 – Buffer Overflow in SendObjectInfo  (opcode 0x100C) CVE-2019-5998 – Buffer Overflow in NotifyBtStatus (opcode 0x91F9) CVE-2019-5999– Buffer Overflow in BLERequest (opcode 0x914C) CVE-2019-6000– Buffer Overflow in SendHostInfo (opcode0x91E4) CVE-2019-6001– Buffer Overflow in SetAdapterBatteryReport (opcode 0x91FD) CVE-2019-5995 – Silent malicious firmware update Itkin’s team informed Canon about the vulnerabilities in their DSLR on March 31, 2019. Recently, on August 6, Canon published a security advisory informing users that, “at this point, there have been no confirmed cases of these vulnerabilities being exploited to cause harm” and asking them to take advised measures to ensure safety. Itkin told The Verge, “due to the complexity of the protocol, we do believe that other vendors might be vulnerable as well, however, it depends on their respective implementation”. Though Itkin said he worked only with the Canon model, he also said DSLRs of other companies may also be at high risk. Vulnerability discovery by Itkin’s team in Canon’s DSLR After Itkin’s team was successful in dumping the camera’s firmware and loading it into their disassembler (IDA Pro), they say finding the PTP layer was an easy task. This is because, The PTP layer is command-based, and every command has a unique numeric opcode. The firmware contains many indicative strings, which eases the task of reverse-engineering it. Next, the team traversed back from the PTP OpenSession handler and found the main function that registers all of the PTP handlers according to their opcodes. “When looking on the registration function, we realized that the PTP layer is a promising attack surface. The function registers 148 different handlers, pointing to the fact that the vendor supports many proprietary commands. With almost 150 different commands implemented, the odds of finding a critical vulnerability in one of them is very high,” Itkin wrote in the research report. Each PTP command handler implements the same code API. The API makes use of the ptp_context object, an object that is partially documented thanks to ML, Itkin said. The team realized that most of the commands were relatively simple. “They receive only a few numeric arguments, as the protocol supports up to 5 such arguments for every command. After scanning all of the supported commands, the list of 148 commands was quickly narrowed down to 38 commands that receive an input buffer,” Itkin writes. “From an attacker’s viewpoint, we have full control of this input buffer, and therefore, we can start looking for vulnerabilities in this much smaller set of commands. Luckily for us, the parsing code for each command uses plain C code and is quite straight-forward to analyze,” he further added. Following this, they were able to find their first vulnerabilities and then the rest. Check Point and Canon have advised users to ensure that their cameras are using the latest firmware and install patches whenever they become available. Also, if the device is not in use camera owners should keep the device’s Wi-Fi turned off. A user on HackerNews points out, “It could get even worse if the perpetrator instead of bricking the device decides to install a backdoor that silently uploads photos to a server whenever a wifi connection is established.” Another user on Petapixel explained what quick measures they should take,  “A custom firmware can close the vulnerability also if they put in the work. Just turn off wifi and don't use random computers in grungy cafes to connect to your USB port and you should be fine. It may or may not happen but it leaves the door open for awesome custom firmware to show up. Easy ones are real CLOG for 1dx2. For the 5D4, I would imagine 24fps HDR, higher res 120fps, and free Canon Log for starters. For non tech savvy people that just leave wifi on all the time, that visit high traffic touristy photo landmarks they should update. Especially if they have no interest in custom firmware.” Another user on Petapixel highlighted the fact, “this hack relies on a serious number of things to be in play before it works, there is no mention of how to get the camera working again, is it just a case of flashing the firmware and accepting you may have lost a few images ?... there’s a lot more things to worry about than this.” Check Point has demonstrated the entire attack in the following YouTube video. https://youtu.be/75fVog7MKgg To know more about this news in detail, read Eyal Itkin’s complete research on Check Point. Researchers reveal vulnerability that can bypass payment limits in contactless Visa card Apple patched vulnerability in Mac’s Zoom Client; plans to address ‘video on by default’ VLC media player affected by a major vulnerability in a 3rd library, libebml

Recently, British Airways was slapped with a $230M fine after attackers stole data from hundreds of thousands of its customers in a massive breach. The fine, the result of a GDPR prosecution, was issued after a 2018 Magecart attack. Attackers were able to insert around 22 lines of code into the airline’s website, allowing them to capture customer credit card numbers and other sensitive pieces of information. Magecart attacks have largely gone unnoticed within the security world in recent years in spite of the fact that the majority occur at eCommerce companies or other similar businesses that collect credit card information from customers. Magecart has also been responsible for significant damage, theft, and fraud across a variety of industries. According to a 2018 report conducted by RiskIQ and Flashpoint, at least 6,400 websites had been affected by Magecart as of November 2018. To safeguard against Magecart and protect your organization from web-based threats, there are a few things you should do: Understand how Magecart attacks happen There are two approaches hackers take when it comes to Magecart attacks; the first focuses on attacking the main website or application, while the second focuses on exploiting third-party tags. In both cases, the intent is to insert malicious JavaScript which can then skim data from HTML forms and send that data to servers controlled by the attackers. Users typically enter personal data — whether it’s for authentication, searching for information, or checking out with a credit card — into a website through an HTML form. Magecart attacks utilize JavaScript to monitor for this kind of sensitive data when it’s entered into specific form fields, such as a password, social security number, or a credit card number. They then make a copy of it and send the copy to a different server on the internet.  In the British Airways attack, for example, hackers inserted malicious code into the airline’s baggage claim subdomain, which appears to have been less secure than the main website. This code was referenced on the main website, which when run within the airline’s customers’ browsers, could skim credit card and other personal information. Get ahead of the confusion that surrounds the attacks Magecart attacks are very difficult for web teams to identify because they do not take place on the provider’s backend infrastructure, but instead within the visitor’s browser. This means data is transferred directly from the browser to malicious servers, without any interaction with the backend website server — the origin — needing to take place. As a result, auditing the backend infrastructure and code supporting website on a regular basis won’t stop attacks, because the issue is happening in the user’s browser which traditional auditing won't detect.  This means Magecart attacks can only be discovered when the company is alerted to credit card fraud or a client-side code review including all the third-party services takes place. Because of this, there are still many sites online today that hold malicious Magecart JavaScript within their pages leaking sensitive information. Restrict access to sensitive data There are a number of things your team can do to prevent Magecart attacks from threatening your website visitors. First, it’s beneficial if your team limits third-party code on sensitive pages. People tend to add third-party tags all over their websites, but consider if you really need that kind of functionality on high-security pages (like your checkout or login pages). Removing non-essential third-party tags like chat widgets and site surveys from sensitive pages limit your exposure to potentially malicious code.  Next, you should consider implementing content security policies (CSP). Web teams can build policies that dictate which domains can run code and send data on sensitive pages. While this approach requires ongoing maintenance, it’s one way to prevent malicious hackers from gaining access to visitors’ sensitive information. Another approach is to adopt a zero-trust strategy. Web teams can look to a third-party security service that allows creating a policy that, by default, blocks access to sensitive data entered in web forms or stored in cookies. Then the team should restrict access to this data to everyone except for a select set of vetted scripts. With these policies in place, if malicious skimming code does make it onto your site, it won’t be able to access any sensitive information, and alerts will let you know when a vendor’s code has been exploited. Magecart doesn’t need to destroy your brand. Web skimming attacks can be difficult to detect because they don’t attack core application infrastructure — they focus on the browser where protections are not in place. As such, many brands are confused about how to protect their customers. However, implementing a zero-trust approach, thinking critically about how many third-party tags your website really needs and limiting who is able to run code will help you keep your customer data safe. Author bio Peter is the VP of Technology at Instart. Previously, Peter was with Citrix, where he was senior director of product management and marketing for the XenClient product. Prior to that, he held a variety of pre-sales, web development, and IT admin roles, including five years at Marimba working with enterprise change management systems. Peter has a BA in Political Science with a minor in Computer Science from UCSD. British Airways set to face a record-breaking fine of £183m by the ICO over customer data breach. A universal bypass tricks Cylance AI antivirus into accepting all top 10 Malware. An IoT worm Silex, developed by a 14 year old resulted in malware attack and took down 2000 devices  

Last week, Capital One revealed it was subject to a major data breach due to a configuration vulnerability in its firewall to access its Amazon S3 database, affecting 106 million users in the US and Canada. A week after the breach, not only Capital One, but GitHub and Amazon are also facing scrutiny for their inadvertent role in the breach. Capital One and GitHub sued in California Last week, the law firm Tycko & Zavareei LLP filed a lawsuit in California's federal district court on behalf of their plaintiffs Seth Zielicke and Aimee Aballo. Both plaintiffs claim Capital One and GitHub were unable to protect user’s personal data. The complaint highlighted that Paige A. Thompson, the alleged hacker stole the data in March, posted about the theft on GitHub in April. According to the lawsuit, “As a result of GitHub’s failure to monitor, remove, or otherwise recognize and act upon obviously-hacked data that was displayed, disclosed, and used on or by GitHub and its website, the Personal Information sat on GitHub.com for nearly three months.” The law firm also alleged that with the help of computer logs, Capital One should have known about the data breach when the information was first stolen in March. They “criticized Capital One for not taking action to respond to the breach until last month,” The Hill reports. The lawsuit also alleges that GitHub “encourages (at least) friendly hacking." "GitHub had an obligation, under California law, to keep off (or to remove from) its site Social Security numbers and other Personal Information," the lawsuit further mentions. According to Newsweek, GitHub also violated the federal Wiretap Act, "which permits civil recovery for those whose 'wire, oral, or electronic communication' has been 'intercepted, disclosed, or intentionally used' in violation of, inter alia, the Wiretap Act." A GitHub spokesperson told Newsweek, "GitHub promptly investigates content, once it's reported to us, and removes anything that violates our Terms of Service." "The file posted on GitHub in this incident did not contain any Social Security numbers, bank account information, or any other reportedly stolen personal information. We received a request from Capital One to remove content containing information about the methods used to steal the data, which we took down promptly after receiving their request," the spokesperson further added. On 30th July, New York Attorney General, Letitia James also announced that her office is opening an investigation into the Capital One data breach. “My office will begin an immediate investigation into Capital One’s breach, and will work to ensure that New Yorkers who were victims of this breach are provided relief. We cannot allow hacks of this nature to become every day occurrences,” James said in a statement. Many are confused about why a lawsuit was filed against GitHub as they believe that GitHub is not at fault. Tony Webster, a journalist, and a public records researcher tweeted, “I genuinely can't tell if this lawsuit is incompetence or malice. GitHub owed no duty to CapitalOne customers. This would be like suing a burglar's landlord because they didn't detect and stop their tenant from selling your stolen TV from their apartment.” https://twitter.com/rickhholland/status/1157658909563379713 https://twitter.com/NSQE/status/1157479467805057024 https://twitter.com/xxdesmus/status/1157679112699277312 A user on HackerNews writes, “This is incredible: they're suggesting that, in the same way that YouTube has content moderators, GitHub should moderate every repository that has a 9-digit sequence. They also say that GitHub "promotes hacking" without any nuance regarding modern usage of the word, and they claim that GitHub had a "duty" to put processes in place to monitor submitted content, and that by not having such processes they were in violation of their own terms of service. I hope that this gets thrown out. If not, it could have severe consequences for any site hosting user-generated content.” Read the lawsuit to know more about this news in detail. U.S. Senator’s letter to Amazon CEO raises questions on the security of AWS products Yesterday, Senator Ron Wyden wrote to Amazon’s CEO, Jeff Bezos “requesting details about the security of Amazon’s cloud service”, the Wall Street Journal reports. The letter has put forth questions to understand how the configuration error occurs and what measures is Amazon taking to protect its customers. The Journal reported, “more than 800 Amazon users were found vulnerable to a similar configuration error, according to a partial scan of cloud users, conducted in February by a security researcher.” According to the Senator’s letter, “When a major corporation loses data on a hundred million Americans because of a configuration error, attention naturally focuses on that corporation’s cybersecurity practices.” “However, if several organizations all make similar configuration errors, it is time to ask whether the underlying technology needs to be made safer and whether the company that makes it shares responsibility for the breaches,” the letter further mentions. Jeff Bezos has been asked to reply to these questions by August 13, 2019. “Amazon has said that its cloud products weren’t the cause of the breach and that it provides tools to alert customers when data is being improperly accessed,” WSJ reports. Capital One did not comment on this news. Read the complete letter to know more in detail. U.S. Senator introduces a bill that levies jail time and hefty fines for companies violating data breaches Facebook fails to fend off a lawsuit over data breach of nearly 30 million users Equifax breach victims may not even get the promised $125; FTC urges them to opt for 10-year free credit monitoring services

Yesterday, two members of the Google Project Zero team revealed about six “interactionless” security bugs that can affect iOS by exploiting the iMessage Client. Four of these bugs can execute malicious code on a remote iOS device, without any prior user interaction. Apple released fixes for these bugs in the iOS 12.4 update on July 22. The two Project Zero researchers, Natalie Silvanovich and Samuel Groß, published details and demo proof-of-concept only for five out of the six vulnerabilities. Details of one of the "interactionless" vulnerabilities have been kept private because Apple's iOS 12.4 patch did not completely resolve the bug, according to Natalie Silvanovich. https://twitter.com/natashenka/status/1155941211275956226 4 bugs can perform an RCE via a malformed message Bugs with vulnerability IDs, CVE-2019-8647, CVE-2019-8660, CVE-2019-8662, CVE-2019-8641 (the one whose details are kept private), can execute malicious code on a remote iOS device. The attacker has to simply send a malformed message to the victim’s phone. Once the user opens the message and views it, the malicious code will automatically execute without the user knowing about it. 2 bugs can leak user’s on-device data to a remote device The other two bugs, CVE-2019-8624 and CVE-2019-8646, allow an attacker to leak data from a user’s device memory and read files off a remote device. This execution too can happen without the user knowing. “Apple's own notes about iOS 12.4 indicate that the unfixed flaw could give hackers a means to crash an app or execute commands of their own on recent iPhones, iPads and iPod Touches if they were able to discover it”, BBC reports. Silvanovich will talk about these remote and interactionless iPhone vulnerabilities at this year’s Black Hat security conference held at Las Vegas from August 3 - 8. An abstract of her talk reads, “There have been rumors of remote vulnerabilities requiring no user interaction being used to attack the iPhone, but limited information is available about the technical aspects of these attacks on modern devices.” Her presentation will explore “the remote, interaction-less attack surface of iOS. It discusses the potential for vulnerabilities in SMS, MMS, Visual Voicemail, iMessage and Mail, and explains how to set up tooling to test these components. It also includes two examples of vulnerabilities discovered using these methods." According to ZDNet, “When sold on the exploit market, vulnerabilities like these can bring a bug hunter well over $1 million, according to a price chart published by Zerodium. It wouldn't be an exaggeration to say that Silvanovich just published details about exploits worth well over $5 million, and most likely valued at around $10 million”. For iOS users who haven’t yet updated the latest version, it is advisable to install the iOS 12.4 release without any delay. Early this month, the Google Project Zero team revealed a bug in Apple’s iMessage that bricks iPhone causing a repetitive crash and respawn operations. This bug was patched in iOS 12.3 update. To know more about these five vulnerabilities in detail, visit the Google Project Zero bug report page. Stripe’s API degradation RCA found unforeseen interaction of database bugs and a config change led to cascading failure across critical services Azure DevOps report: How a bug caused ‘sqlite3 for Python’ to go missing from Linux images Is the Npm 6.9.1 bug a symptom of the organization’s cultural problems?

Update: On 28th August, an indictment was filed in a US federal district court, which mentioned Thompson allegedly hacked and stole information from an additional 30 AWS-hosted organizations and will face computer abuse charges. Capital One Financial Corp., one of the largest banks in the United States, has been subject to a massive data breach affecting 100 million customers in the U.S and an additional 6 million in Canada. Capital One said the hacker exploited a configuration vulnerability in its firewall that allowed access to the data. In its official statement released yesterday, Capital One revealed that on July 19, it determined an "unauthorized access by an outside individual who obtained certain types of personal information relating to people who had applied for its credit card products and to Capital One credit card customers." Paige A. Thompson, 33, the alleged hacker who broke into Capital One server, was arrested yesterday and appeared in federal court in Seattle. She was an ex-employee from Amazon's Cloud service (AWS), Amazon confirms. The Capital One hacker, an ex-AWS employee, “left a trail online for investigators to follow” FBI Special Agent Joel Martini wrote in a criminal complaint filed on Monday that a “GitHub account belonging to Thompson showed that, earlier this year, someone exploited a firewall vulnerability in Capital One’s network that allowed an attacker to execute a series of commands on the bank’s servers”, according to Ars Technica. IP addresses and other evidence ultimately showed that Thompson was the person who exploited the vulnerability and posted the data to Github, Martini said. “Thompson allegedly used a VPN from IPredator and Tor in an attempt to cover her tracks. At the same time, Martini said that much of the evidence tying her to the intrusion came directly from things she posted to social media or put in direct messages”, Ars Technica reports. On  July 17, a tipster wrote to a Capital One security hotline, warning that some of the bank’s data appeared to have been “leaked,” the criminal complaint said. According to The New York Times, Thompson “left a trail online for investigators to follow as she boasted about the hacking, according to court documents in Seattle”. She is listed as the organizer of a group on Meetup, a social network, called Seattle Warez Kiddies, a gathering for “anybody with an appreciation for distributed systems, programming, hacking, cracking.” The F.B.I. noticed her activity on Meetup and used it to trace her other online activities, eventually linking her to posts boasting about the data theft on Twitter and the Slack messaging service.  “I’ve basically strapped myself with a bomb vest, dropping capital ones dox and admitting it,” Thompson posted on Slack, prosecutors say. Highly sensitive financial and social insurance data compromised The stolen data was stored in Amazon S3, "An AWS spokesman confirmed that the company’s cloud had stored the Capital One data that was stolen, and said it wasn’t accessed through a breach or vulnerability in AWS systems", Bloomberg reports. Capital One said the largest category of information accessed was information on consumers and small businesses as of the time they applied for one of its credit card products from 2005 through early 2019. The breached data included personal information Capital One routinely collects at the time it receives credit card applications, including names, addresses, zip codes/postal codes, phone numbers, email addresses, dates of birth, and self-reported income. The hacker also obtained customer status data, e.g., credit scores, credit limits, balances, payment history, contact information including fragments of transaction data from a total of 23 days during 2016, 2017 and 2018. For the Canadian credit card customers, approximately 1 million Social Insurance Numbers were compromised in this incident. About 140,000 Social Security numbers of Capital One's credit card customers and about 80,000 linked bank account numbers of our secured credit card customers were compromised. Richard D. Fairbank, Capital One’s chief executive officer, said in a statement, "I am deeply sorry for what has happened. I sincerely apologize for the understandable worry this incident must be causing those affected.” Thompson is charged with computer fraud and faces a maximum penalty of five years in prison and a $250,000 fine. U.S. Magistrate Judge Mary Alice Theiler ordered Thompson to be held. A bail hearing is set for Aug 1. Capital One said, it “will notify affected individuals through a variety of channels. We will make free credit monitoring and identity protection available to everyone affected”. Capital One's justification of "Facts" is unsatisfactory Users are very skeptical about trusting Capital One with their data going ahead. A user on Hacker News writes, “Obviously this person committed a criminal act, however, Capital One should also shoulder responsibility for not securing customer data. I have a feeling we'd be waiting a long time for accountability on C1's part.” Security experts are surprised with Capital One’s stating of “facts that say “no Social Security numbers were breached’ and say this cannot be true. https://twitter.com/zackwhittaker/status/1156027826912428032 https://twitter.com/DavidAns/status/1156014432511643649 https://twitter.com/GossiTheDog/status/1156232048975273986 Similar to Capital One, there were other data breaches in the past where the companies have agreed on a settlement to help the affected customers like the Equifax or have been levied with huge fines like the Marriott International and British Airways. The Equifax data breach that affected 143 million U.S. consumers on September 7, 2017, resulted in a global settlement including up to $425 million to help people affected by the data breach amounting to approximately $125 per affected victim, should they apply for compensation. This global settlement was done with the Federal Trade Commission, the Consumer Financial Protection Bureau, and 50 U.S. states and territories. The Marriott data breach occurred in Marriott’s Starwood guest database that compromised 383 million user data was revealed on November 19, 2018. Recently, the Information Commissioner’s Office (ICO) in the UK announced its plans to impose a fine of more than £99 million ($124 million) under GDPR. The British Airways data breach compromised personal identification information of over 500,000 customers and is believed to have begun in June 2018. Early this month, the ICO also announced it will fine British Airways with more than £183m fine. As a major data breach in one of the largest banks, Capital One could feel the pinch by regulators soon. What sets this case apart from the above breaches is that the affected customers are from the US and Canada and not from the EU. In the absence of regulatory action by the ICO or the EU commission, it is yet to be seen if regulators in the US and Canada will rise to the challenge. Also, now that the alleged hacker has been arrested, does this mean Capital One could slip by without paying any significant fine? Only time can tell if Capital One will pay a huge sum to the regulators for not being watchful of their customers' data in two different states. If the Equifax-FTC case and the Facebook-FTC proceedings are any sign of things to come, Capital One has not much to be concerned about. To know more about this news in detail, read Capital One’s official announcement. Thompson faces additional charges for hacking into the AWS accounts of about 30 organizations On 28th August, an indictment was filed in a US federal district court, where the investigators mentioned they have identified most of the companies and institutions allegedly hit by Thompson. The prosecutors said Thompson wrote software that scanned for customer accounts hosted by a “cloud computing company,” which is believed to be her former employer, AWS or Amazon Web Services. "It is claimed she specifically looked for accounts that suffered a common security hole – specifically, a particular web application firewall misconfiguration – and exploited this weakness to hack into the AWS accounts of some 30 organizations, and siphon their data to her personal server. She also used the hacked cloud-hosted systems to mine cryptocurrency for herself, it is alleged," The Register reports. “The object of the scheme was to exploit the fact that certain customers of the cloud computing company had misconfigured web application firewalls on the servers that they rented or contracted from the cloud computing company,” the indictment reads. The indictment further reads, “The object was to use that misconfiguration in order to obtain credentials for accounts of those customers that had permission to view and copy data stored by the customers on their cloud computing company servers. The object then was to use those stolen credentials in order to access and copy other data stored by the customers.” Thus, she also faces a computer abuse charge over the 30 other AWS-hosted organizations she allegedly hacked and stole information from. Facebook fails to fend off a lawsuit over a data breach of nearly 30 million users US Customs and Border Protection reveal data breach that exposed thousands of traveler photos and license plate images Over 19 years of ANU(Australian National University) students’ and staff data breached